TMS320F28065: The "Missing-Clock-Detect circuit" function is continued.

O.H.

I think that this may be on the same topic as started by TI'er Yuto here: https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1069142/tms320f28065-missing-clock-detect-circuit

I'll combine the threads if that is OK with you and we can work off a single thread.

I need to look at the spec to understand of the MCLK circuit would still fault if the clock only goes missing for 400ns of a 4us cycle.  Does the clock go missing completely or is it just not ideal?

Certainly there is a set procedure that has to be followed after a missing clock event/reset.  One option is to stay clocked off the internal oscillator and feed the external X-tal signal to a CPU timer and check if things are OK before switching over.

As I mentioned in the other post, if the customer disables the missing clock detection logic completely, does the system work as expected, meaning that whatever glitch has no functional impact on the MCU?

Best,
Matthew

Hi Matthew,

Thanks for the reply and sharing the thread. Since the other thread is already resolved, could you please continue my question here?

MatthewPate said:

I need to look at the spec to understand of the MCLK circuit would still fault if the clock only goes missing for 400ns of a 4us cycle.  Does the clock go missing completely or is it just not ideal?

The signal is not completely gone, but the clock cycle is changing and the VDDIO voltage is swinging.

MatthewPate said:

As I mentioned in the other post, if the customer disables the missing clock detection logic completely, does the system work as expected, meaning that whatever glitch has no functional impact on the MCU?

Q5:Do I need to change all clocks to use the internal oscillator? Or is it enough to simply set the MCLKOFF bit?

The MCLKOFF bit in the TRM is described as "Use this mode when the code must not be affected by the detection circuit. For example, if external clocks are turned off.".

Q6:When the oscillator fail-detect logic is disabled by the MCLKOFF bit in the PLLSTS register, what happens if there is a clock error?

Since there is no description in the TRM of what kind of operation will be performed, does this mean that the operation will be unpredictable? The customer has the watchdog function enabled, and the monitoring time is set to 100㎳.

Best regards,
O.H

O.H.,

Looking at the spec of the missing clock detect logic, there is a 7bit counter clocked from OSCCLK directly and a 13bit counter  clocked from the output of the PLL(VCOCLK).  When the 7 bit counter overflows it will reset both itself and the 13 bit VCOCLK counter.  If the OSCCLK goes missing it will no longer increment its counter, so VCOCLK will overflow and trigger the missing clock detect(either an immediate reset, or if NMIWD is enabled, a delayed event).

Even if the OSCCLK only goes missing for a brief time, it is very dependent on where the counter state is if the VCOCLK counter would overflow.  For instance if the clock went missing right before the 7 bit overflow, then the VCOCLK counter would only have to count ~7400 more clocks before it overflowed, assuming the standard 6:1 ratio of PLL Clock to OSCCLK. 

Assuming the worst case(fastest) VCOCLK when OSCCLK goes missing of 5MHz, then it would only take an additional 1.5ms for the clock fail to activate.

From your above info, your clock only goes missing for 400ns, so this shouldn't cause the overflow to occur.(although I don't know your customer's settings)  I think the question is if something from the over-voltage event is causing the OSCCLK to not behave correctly after this happens?  The PLL will also need to re-lock, so the device will be running at some variable frequency which could be undesirable.

You could use the NMIWD to detect the event occurs, then re-lock the PLL as a precaution vs resetting the device. 

Q)Can you comment if the clock signal looks normal after the event occurs?

O.H said:

Q5:Do I need to change all clocks to use the internal oscillator? Or is it enough to simply set the MCLKOFF bit?

A5)As you mention you can disable the missing clock detect by setting the MCLKOFF bit, but you will lose any gross protection of the logic that might be beneficial.  You could use the NMIWD to trigger an event that switches the clock to the internal oscillator when this happens.  Then use the CPUTIMERs to determine when the external clock is good, and switch back.  Again you will have to re-lock the PLL, etc.

You can use internal oscillator, it will likely have a wider frequency tolerance than an external X-tal, but will likely not suffer from the external event.  You could keep the MCLK detect enabled here for safety purposes.

O.H said:

Q6:When the oscillator fail-detect logic is disabled by the MCLKOFF bit in the PLLSTS register, what happens if there is a clock error?

A6)My understanding if it is disabled is that the device will run off the VCOCLK if the clock goes missing.  This can be from 1MHz-5MHz according to the TRM.  So the device will continue to run, but not at the correct frequency for your system.

Best,

Matthew

Hi Matthew,

Thanks for the reply.

MatthewPate said:

You could use the NMIWD to detect the event occurs, then re-lock the PLL as a precaution vs resetting the device. 

Q)Can you comment if the clock signal looks normal after the event occurs?

We have asked the customer to confirm the above.

MatthewPate said:

A6)My understanding if it is disabled is that the device will run off the VCOCLK if the clock goes missing.  This can be from 1MHz-5MHz according to the TRM.  So the device will continue to run, but not at the correct frequency for your system.

I asked the customer to confirm the above, but they said it is difficult to confirm because different frequencies (1~5MHz) in the system can lead to failure of the board. Therefore, if there is anything other than the above methods that we should check now, we would appreciate it if you could point it out to us.

It may be that the over-voltage even has created a latch-up event in the X-tal circuit, does the customer observe normal X-tal activity after the missing clock/spur issue occurs to the system, but the missing clock detect logic is still reporting an issue?  I believe there is a sequence to recover from MCD outlined in the TRM, I would make sure this is being followed.

Regarding the above "the over-voltage even has created a latch-up event in the X-tal circuit," can you explain the principle of latch-up?

The customer understands that over-voltage can occur due to noise from the external power supply, but it would be helpful if you could explain the principle in simple terms.

Best regards,
O.H

O.H.

In terms of latch up, if it is happening, it would be possible when the voltage exceeds a diode drop above VDDIO or below VSS.  For the X1/X2 circuit this is a core voltage level circuit, so the reference voltage is based on VDD value, or if the VREG is in use this would be ~1.9V. 

If a voltage is seen in the above excess, it has potential to activate a parasitic transistor path that normally does not exist in the silicon.  If this did happen, the customer should not observe a clock signal on the X1 pin, i.e. the circuit has stopped and is no longer driving the quartz crystal in the usual manner.  If this were true, then the missing clock logic internal to the device would detect it, but even more likely is that this condition would not go away unless a power cycle occurred.

That the X1 pin could be over-driven would be unusual, as there is no external connection to an active component, i.e. the C2000 is supplying the voltage from its own rail to oscillate the crystal.  If this was indeed due to noise coupling, I would think the power of that noise would be quite large.

Changing subject a bit, I would not think the missing clock detect logic we have discussed previously would itself latch up.  These are just counters from the different clock sources.  If this logic continues to detect a missing clock I would think that the clock is actually missing/flat on the X1 pin.

Best,

Matthew

Hi Matthew,

Sorry for the late reply. And thank you for the detailed explanation.

We had already contacted our customers with this answer, but we are currently not receiving any inquiries. (We believe that the noise on the power supply side was probably a major factor...)

If any additional questions arise, we will contact you again.

Best regards,
O.H