• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 31 subscribers
  • Views 182 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSPM0G3518-Q1: how to detect an external crystal or clock fault

sh
Prodigy 10 points

Part Number: MSPM0G3518-Q1

Hi

We use an external crystal (40MHz) at HFXT to source the PLL, which provides the 80MHz for the core and so on. This works fine and as intended. As we utilize one of the timers (PMW) to drive a boost converter, we need to make sure, that this gets not destroyed when the clock stops unintended. 

Is there any way to detect that the crystal is not working anymore (or probably the PLL)?

We tried the MCLK monitor as well as the Fault-condition of the timer, but they do not recognise the crystal failure. Somehow the PLL does something with a lower Frequency, which may lead to this. 

The start-up monitors also do not satisfy our needs, as the crystal may "break" during operation.

We would prefer a "rapid" stop of the Timer with defined output state as soon as the clock fails to prevent HW destruction (as described in the Fault Handler chapter). Therefore "waiting" for the watchdog or measuring the frequency every now and then does not do the job.

Clocking the Timer from LFCK, which supports this functionality, is not possible, as we need a frequency higher than 32kHz.

Thanks and regards

  • 0
    TI__Expert 7590 points

    Hi sh,

    I have reached out to a member of our design team, for more insight into the issue. I will update you as soon as I hear from them.

    Best Regards,
    Brian

  • 0
    TI__Expert 7590 points

    Hi sh,

    I have heard back from design and the best solution we have is to do periodic checks of MCLK against LFCLK with the FCC. If you use LFOSC as your reference, you will only be able to determine your frequency down to +/-5%. But this might be okay. If the HFXT really fails, the SYSPLL will most likely be more off than just 5%.

    Best Regards,
    Brian

  • 0 in reply to Brian Lee
    Prodigy 10 points

    Hi Brian,

    Thanks for the answer.
    As stated in the question, measuring the frequency (using the FCC) is not sufficient for us.

    Anyway, which conditions need to be met, that the System Clock Fault a) is detected and b) triggers the Fault Handler of the timer?
    I only found these informations in the manual.

    Thanks and regards

  • 0 in reply to sh
    TI__Expert 7590 points

    Hi sh,

    I have reached out to our design team again to answer your questions. I hope hear back from them early next week. 

    Best Regards,
    Brian

  • 0 in reply to Brian Lee
    TI__Expert 7590 points

    Hi sh,

    In your case, the system clock fault is based on the MCLK monitor and only registers when there is no MCLK at all. When HFXT stops working, it is likely the SysPll still generates a clock, but at a different frequency. This means the MCLK monitor will not detect the HFXT failure. 

    Best Regards,
    Brian