DZ60 intermittent clock issue?

[paullaiming]

I have several designs for high current motor controller using DZ60.

I am finding certain controllers designs have no issues but others will work up until a certain current and

then appears to get some kind if glitch. I suspect it is a crystal/clock circuit issue but cannot determine a method to

isolate and debug this.

A few data points:

- 12Mhz crystal (ECS-120-20-30B-DU) with 20pf/1Mohm oscillator circuit, PLL enabled, 18Mhz bus clock

- For the designs that have this issue - the glitch does not happen on every controller/motor combination.

- For the motor controller that do show the issue - they work at low currents but as the motor pwm duty is increased and current load goes up, the glitch occurs. This would be when the PCB noise is getting worse.
-The MCU is outputing a PWM signal using one of the TPMs. This signal goes to a motor control IC which takes

care of the motor control commutaion and timing. When the "glitch" occurs, the PWM output can get stuck high, low, or

at the last frequency.

- With codewarrior debugger attached, the MCU appears to jump to different instruction locations when glitch occurs(not same place every time).

The instructions are usually in areas of code that should not be being executed.

- I swap to activate internal clock and scale it to achieve nearly identical bus clock. The controller works without any glitches every time.

- I tried to play with the C and R values in the crystal circuit but it did not have any noiticable improvement.

We have a strong suspicion that the crystal circuit is being upset by the electrical noise but

cannot determine a way to prove it. Switching to internal clock is not considered an ideal solution

because of the requirement for CAN bus.

Can anyone suggest some better methods to determine if the clock circuit is the

issue or if it is something else?  Feel free to ask any questions needed.

[bigmac]

Hello Paul,

It is possible that external noise could disrupt the crystal operation, especially if the connection of the two capacitors back to Vss (ground) is not by a very short route, i.e. there is inductance present.  Shorten the track and/or broaden the track to minimize the inductance.  Ideally use a ground plane layer.  Also make sure that "high gain" oscillator mode is selected.  Additionally, you might test whether you have similar problems when using a "canned" crystal oscillator, rather than a crystal.

For the diagnostics, you would firstly need to ascertain whether the noise is causing a reset.  The SRS register will indicate the cause of the last reset.  This can be read within the MCU initialisation function.

Another possibility is that the noise is causing loss of lock of the PLL.  You might code the loss of lock interrupt, to determine if this is occurring during operation.

Regards,

Mac

[paullaiming]

We made a little progress this week. Our assumption was that the motor noise was disrupting our crystal clock circuit so we change the crystal to an external oscillator. Suprisingly this did not help. The MCU still latched up as the motor noise increased. Switching to internal clock still worked fine at all speeds and currents. Then I realized that using the internal clock does not allow PLL and requires switch to FLL. I tried switching the external oscillator to use the FLL and the latching issue was gone. This points to the PLL being the primary issue. I would have thought the PLL loss of lock interupt would have indicated this but perhaps is the clock is disrupted so severely the logic I implemented to indicate this may never have worked.

I am not that familiar with FLL vs PLL so now its time for some more research...

[bigmac]

Hello Paul,

I believe that the locking mechanism for the FLL should be more robust than for the PLL.  However, the FLL output will suffer from a greater amount of jitter than the PLL output.  I don't think that this will be a problem for your motor control, but I am not sure about the CAN bus operation.

Regards,

Mac

[paullaiming]

Mac,

Due to the FLL jitter and accuracy concerns, we are testing running in PLL bypass mode and taking

the hit running the core clk slower.  In the meantime we will try to see if we can determine how to

fix the PLL. I believe its due to noise on MCU 5V supply or ground. Due you see any other concerns

running in PLL bypass?

-paul

[paullaiming]

I tried both enabling the loss of lock interrupt and coding a snippet to set a variable if it occurred.

When the controller hung up sometimes the debugger stops communicating and the only

thing that will get it communicating again is to power cycle, so it was a bit tricky. It does not appear

that the loss of lock is occurring. Second, we checked the SRS register and no bits were

set during the event either - unless we manually hit the reset on the debugger.

We also performed a more thorough review of the layout and there are some aspects that

are less than ideal.

At present we are trying to determine if using the ICG will be acceptable for running

CAN 2.0 at 125kbps.  I am concerned about this with temperature variations (-40C to 125C)

will results in loss of communication due to change in clock frequency.

[paullaiming]

Thanks Mac,

After we noticed this issue on one of our earlier designs (and had to switch to internal clock for production), we spent significant effort on the layout. We made sure that the crystal, capacitors, and resistor were right next to the MCU and verified no noisy routes in layers below (basically tried our best to guard that area of the PCB). Ill see if I can post some layout pictures for your review.

Thank you for the 2 ideas. We will get together today and test using your suggestions. My intuition is that a reset is not occuring, because if it was, the code would be restarting initialization and the motor would restart. What I have observed the code just seems to jump into never-never land.  The debugger usually remains working and shows the code stuck in some strange location or interrupt - sometimes the debugger seems to have issues communication. Also, many of the register values in the debugger will display completely incorrect values.

-paul

[paullaiming]