Update on S32K388 BIST issue: Soft reset causing peripheral init failure in App

[HazemIhab]

Hi NXP Support Team,

Following up on the previous BIST hard reset issue: we applied your proposed change, and the BIST now successfully performs a soft reset instead.

To adapt to this soft reset and avoid double MCU clock initialization, we initially kept the MCU clock initialization in the Application. However, after the BIST soft reset and jumping to the App, the clock re-initialization was taking an unusually long time. We suspect this delay and lock-up occurred because the clocks were already initialized by the Boot Manager, causing conflicts during the second attempt.

To resolve that extreme delay, we removed the MCU clock initialization from the Application entirely, leaving it exclusively in the Boot Manager. Unfortunately, this has introduced a new issue: after jumping to the Application, the system now hangs during peripheral initialization (specifically FlexCAN), which points back to a clock availability issue.

Could you advise on the correct clock configuration strategy here? Specifically, does the BIST soft reset disrupt the clocks initialized by the BM in a way that requires re-initialization in the App, and how can we properly hand off the clocks between the BM and App without causing lockups or extreme delays?

[danielmartynek]

Hi @HazemIhab,

I haven't found your previous BIST hard reset issue in any support ticket or community thread.

I understand you see ST_DONE functional reset.

After the reset the clock configuration is reset, so it needs to be initialized.

If you use the RTD drivers, the Clock_Ip_InitClock() function resets all the clocks to a safe state first — which is probably the delay you see if you initialize the clocks in both the Boot Manager and the application.

It can be configured in the Boot Manager only, but you need to make sure the driver enables all the clocks the application needs — in this case the FlexCAN clock.

Also, all the system clocks must match one of the clock options listed in the RM, e.g. Table 156. Option A - High Performance mode (CM7_CORE_CLK @ 160 MHz) (For S32K388/S32K389).

BR, Daniel

[HazemIhab]

Hello @danielmartynek 

Thanks for the explanation.

To clarify our setup: our Boot Manager (BM) and Application (App) already use the exact same clock configuration, including the FlexCAN clock settings.

To avoid the delay from the safe-state reset, we let the BM initialize all clocks and removed Clock_Ip_InitClock() from the App. However, when the App tries to initialize FlexCAN after the jump, the system still hangs with a clock-related error.

[danielmartynek]

Hi @HazemIhab,

I understand there is a fault exception, can you confirm?

If so, you need to find more information about the exception to confirm it is really clock related.

https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K312-HARDFAULT-Handling-Interrupt-DS3-5-...

https://community.nxp.com/t5/S32K-Knowledge-Base/How-To-Debug-A-Fault-Exception-On-ARM-Cortex-M-V7M-...

https://community.nxp.com/t5/S32K-Knowledge-Base/Fault-handling-on-S32K14x/ta-p/1114447

If there is no exception, but the execution is stuck in a loop, where exactly?

Also, as I mentioned, all the system clocks must match one of the clock options listed in the RM, e.g. Table 156. Option A - High Performance mode (CM7_CORE_CLK @ 160 MHz) (For S32K388/S32K389) can you confirm?

Thank you,

BR, Daniel