S32K3 functional reset causes increased start-up time

[wuxianlong]

Hi, NXP

If I configure the clock source for MUX_6 to be FXOSC(NXP default configuration), then perform a “ Functional Reset”. The start-up time of the S32K3 will be much longer than that of a POR or a ” Destructive Reset.“

I found out that the reason was that in the Clock_Ip_ResetCgmXCscCssCsGrip() function, the Clock Mux6 clock shutdown request could not be completed and could only wait for a timeout to occur.

Also in the Clock_Ip_SetCgmXDeDivStatWithoutPhase() function, the MUX_DIV_UPD_STAT status of Clock Mux6 cannot be updated and can only wait for a timeout.

If I remove the timeout condition, the system will fall into an endless loop.

Are there any special requirements for using MUX_6's clock source as FXOSC? Similar situations will not occur with other clock sources.

Best Regards，
xianlon

[danielmartynek · Accepted solution]

Hi @wuxianlong,

Is the clock source active?

RTD 5.0.0 uses FCG there too:

Regarding the CM7_0 clock, the driver cannot disable the clock.

Before the clock of a core can be disabled, the core must be stopped at WFI.

This is not possible with the main core.

Regards,

Daniel

[wuxianlong]

Hi,@danielmartynek 

Thank you for your reply.

I tested adding CFG configuration and solved the problem.

As far as I understand it,CM7_0 Under MCU Contral  should be configured to FALSE

[wuxianlong]

Hi，NXP

There is also a problem that causes the clock initialization time to be extended.

In the Power module (NXP default configuration), the CM7_0 Under MCU Control option is TRUE and the CM7_0 Core Clock Enable is FALSE.

In the Power_Ip_MC_ME_ConfigureCore() function, the program will execute a waiting for WFI due to the default configuration. However, there are no instructions to control the core to enter WFI. In other words, WFI cannot be set, and the user can only wait for a timeout in this logic. Should I optimize the configuration (CM7_0 Under MCU Control ) in this situation?

BRs,
xianlong