MPC5777C: execution of the online-BIST sometimes results in a non-recoverable crash

[BG]

Hello,

we use the online-BIST of the MPC5777C in one of our products. The execution is done the same way as given by the example "MPC5777C-Online-MBIST+LBIST-v1_2-GHS614.zip" from https://community.nxp.com/t5/MPC5xxx-Knowledge-Base/MPC5777C-Online-BISTs/ta-p/1124355. The only difference in the BIST execution is that we skip the MBIST 3 to avoid corruption of the standby-RAM during the self-test. Additionally the core clock prior to the BIST execution is 300 MHz which is then reconfigured using the function SysClk_Init from the example.

In most cases the BIST execution runs normally but sometimes the MCU does not reset after the BIST and remains in a state where it is not possible to access via debugger. Using GPIO outputs to monitor the software execution, it seems that the SysClk_Init function is not exited. Thus I assume a problem with the reconfiguration of the clock from the prior used 300 MHz core clock to the lower 200 MHz for the BIST execution.

The problem seems to disappear or at least occur far more rarely when I add a delay of approximately 2 ms between the switch of the system clock to the IRC and the subsequent PLL reconfiguration within the function SysClk_Init.

Are any known problems with the clock reconfiguration before executing an online-BIST? If yes, how can this problem be avoided?

Regards,
Bernd

[petervlna · Accepted solution]

Hello,

In most cases the BIST execution runs normally but sometimes the MCU does not reset after the BIST and remains in a state where it is not possible to access via debugger.

This is very unlikely as the reset after BIST is routed by HW, so it has its own separate line to reset module, based on the STCU2 module BIST execution. So once you start BIST there will always be reset. Otherwise you will have registers filled with test patterns as well as memory where ECC wont match. Therefore the reset is set after BIST to bring micro into default state.

Are any known problems with the clock reconfiguration before executing an online-BIST? If yes, how can this problem be avoided?

This is not lined to BIST itself. I expect that some of your peripherals are still running from PLL, or so.

Therefore the mode transition is not successful. Set some pin toggle on successful mode transition to verify that is was done correctly with new clock. Or simply do debugging there. Up to point where you start BIST you can use debugger.

Best regards,

Peter

[BG]

Hi Peter,

thank you for your answer!

You are right, I forgot to change the peripheral clock back to IRC when I reconfigured the PLLs. Changing this allowed me to use the debugger as the connection would not drop any more.

I could confirm that the problems lies in the reconfiguration of the PLL. I will submit a new question for that.

Regards,
Bernd