• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 2 answers
  • Subscribers 32 subscribers
  • Views 359 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: Inquiry regarding MSPM0G351x MCLK Dead Clock Monitor

Mohamed Abdelfatah
Prodigy 60 points

Part Number: MSPM0G3518
Other Parts Discussed in Thread: LP-MSPM0G3519

Hello,

I am currently implementing ISO-26262 hardware safety mechanisms on the MSPM0G351x using an AUTOSAR architecture. 
I have successfully configured and enabled the MCLK Monitor (Dead Clock Check) but am struggling to perform a software-induced fault injection to validate the hardware's reaction.

Configuration:
MCLK Source: SYSOSC (32 MHz).
LFCLK Source: LFOSC (32 kHz).
Monitor Enable: I have verified via the debugger that the MCLKDEADCHK bit in the SYSCTL->SOCLOCK.MCLKCFG register is successfully set to 1 during initialization.

I need to intentionally halt the MCLK (force it to 0 Hz) during runtime to verify that the hardware detects the dead clock (within 1 to 12 LFCLK cycles) and triggers the safety reaction.

Tests Attempted (Fault Injection):
I have attempted to starve the MCLK using the following methods, but neither triggered the hardware monitor:
1- Switching MCLK to a disabled source: I attempted to set USEHSCLK = 1 in the MCLKCFG register while the SYSPLL was disabled.

Result: The hardware monitor did not fire. Instead, the CPU kept running (likely at a fallback frequency or the glitch-free mux prevented the switch), and my software-based Frequency Clock Counter (FCC) caught the frequency drift.

2- Disabling the active oscillator: I attempted to forcefully disable SYSOSC by writing to SYSCTL->SOCLOCK.SYSOSCCFG.

Result: No reaction from the hardware. The CPU continued running normally, likely because the hardware protects the active clock source from being disabled.

Questions:

1- Fault Injection Method: What is the recommended software method to intentionally starve the MCLK or bypass the glitch-free mux on the MSPM0G351x to successfully trigger the MCLK Dead Clock Monitor for safety validation?

2- Hardware Reaction: The Technical Reference Manual states, "An MCLK fault is always considered fatal to the system and generates a BOOTRST". Is there any configuration available (perhaps via SYSCFG or NONMASKINT) to route this fault to an NMI or standard interrupt instead of a hard BOOTRST, or is the BOOTRST reaction strictly hardwired?

 

Thank you for your guidance.

  • 0
    TI__Mastermind 41900 points

    Will do some test later and feedback to you

  • 0 in reply to Gary Gao
    TI__Mastermind 41900 points
    Mohamed Abdelfatah said:

    1- Switching MCLK to a disabled source: I attempted to set USEHSCLK = 1 in the MCLKCFG register while the SYSPLL was disabled.

    Result: The hardware monitor did not fire. Instead, the CPU kept running (likely at a fallback frequency or the glitch-free mux prevented the switch), and my software-based Frequency Clock Counter (FCC) caught the frequency drift.

    I try this test and it seems the CPU will stuck after change the clock source. And not keep running. You can refer to my test code

    gpio_toggle_output_LP_MSPM0G3519_nortos_ticlang.zip

    I use LP-MSPM0G3519

  • 0 in reply to Gary Gao
    Prodigy 60 points

    Hi Gary,

    Thank you for testing this on the LP-MSPM0G3519 and providing the NoRTOS example!

    I am running a full AUTOSAR architecture (with an OS and BSW layer), so it is possible that either a BSW module is keeping the HSCLK tree partially active in the background, or my runtime register write is being shielded, which is why my CPU kept running and my FCC software caught the drift. I will review my MCAL configuration to ensure HSCLK is truly 0 Hz.

    However, regarding your NoRTOS test where the CPU gets "stuck": If the MCLKDEADCHK bit is successfully enabled, shouldn't the hardware trigger a BOOTRST within 1 to 12 LFCLK cycles when the CPU gets stuck? In your test, does the microcontroller actually reboot, or does the CPU just remain frozen indefinitely?

    My ultimate goal is to prove that the Dead Clock Monitor successfully issues that BOOTRST safety reaction.

    Thank you again for your support!

  • 0 in reply to Mohamed Abdelfatah
    TI__Mastermind 29932 points

    Hello Mohamed,

    To answer to your second question, an MCLK clock monitoring fault is hardwired to BOOTRST. The reason for not allowing an NMI or other interrupt to be taken is that MCLK is at fault, so the NMI may never be taken because there is no clock anymore. The only way to try to recover the system is to apply a BOOTRST that restarts the various oscillators.

    Best regards,
    François.

  • 0 in reply to Francois Charlot
    Prodigy 60 points

    Hello Francois,

    Thank you for the explanation! That makes perfect logical sense regarding why an NMI wouldn't be possible without an active clock.

    Could you or the team please advise what is the recommended software sequence to intentionally starve the MCLK (force it to 0 Hz) to successfully trigger this BOOTRST for our safety validation testing?

    Thanks again for your support!
    Mohamed.

  • 0 in reply to Mohamed Abdelfatah
    TI__Mastermind 41900 points

    Hi Mohamed,

    After check with design please refer to the comments below

    For the test way below can not work, 

    Mohamed Abdelfatah said:
    1- Switching MCLK to a disabled source: I attempted to set USEHSCLK = 1 in the MCLKCFG register while the SYSPLL was disabled.

    due to when you use the function below try to switch the clock, the MCU will check if the HSCLK that feed from SYSPLL/HFCLK first, and due to the SYSPLL is not enabled, so the CPU will stuck at the HSCLK check loop.

    DL_SYSCTL_setMCLKSource(SYSOSC, HSCLK, DL_SYSCTL_HSCLK_SOURCE_SYSPLL);  

    Mohamed Abdelfatah said:
    2- Disabling the active oscillator: I attempted to forcefully disable SYSOSC by writing to SYSCTL->SOCLOCK.SYSOSCCFG.

    This also not work, because the MCU will change to LFCLK automatically if the SYSOSC is disabled

    Here we have test is that when using a external digital clock as input at the HFCLK_IN and when you top the external clock it can generate the reset.

  • 0 in reply to Gary Gao
    TI__Mastermind 29932 points

    Hello Gary,

    Thank you. Should we understand that when using an on-chip MCLK clock source, there is no way to inject a fault that would trigger a BOOTRST from the MCLK dead clock oscillator?


    Best regards,
    François.

  • 0 in reply to Francois Charlot
    TI__Mastermind 41900 points

    If the MCLK soured from internal clock it can't the inject fault t trigger the bootrst.

  • 0 in reply to Gary Gao
    TI__Mastermind 29932 points

    Thank you, Gary.

     : I think that this topic is now closed. Unless you have other questions?