S32K312 Wakeup Behavior

[harsh_95]

HI, 

We are developing a sleep wakeup functionality on NXP S32K312 for Autosar based Requirement.

Currently, we are able to configure the ICU channel to detect Wakeup event. And no issue observed while Sleep wakeup behavior. We have configured Standby mode.

Problem Statement: After wakeup, we are not able to see where the control is going. From our understanding, as per NXP it says the Standby exit sequence will trigger the functional reset. But we don't see any Reset happening.

Due to the above problem we are observing some delay in Wakeup and it is not fitting as per our requirement.

Need clarification on where the control will start from if there is no functional reset is observed after standby exit sequence.

Thanks

[danielmartynek]

Hi @harsh_95,

After waking up, execution begins either at the reset vector or at the fast wakeup boot address if fast wakeup is enabled.
Have you enabled fast wakeup? Even when fast wakeup is used, the application should eventually jump to the reset vector.
For reference, check the examples provided here:
https://community.nxp.com/t5/S32K-Knowledge-Base/S32K3-Low-Power-Management-AN-and-demos/ta-p/152772...

You can also trap the execution at the reset vector after wakeup and attach the debugger.

Loop:
mov r0, #1
cmp  r0, 0 /* Change r0 to 0 in register view */
bne Loop   /* Capture after power-on reset */

Can you elaborate on this?

"Due to the above problem we are observing some delay in Wakeup and it is not fitting as per our requirement."

S32K3xx DS rev13, Table 6. Power mode transition operating behavior.

Regards,

Daniel

[harsh_95]

HI @danielmartynek ,

We have a requirement of CAN response during wakeup within 50ms. But , in our case currently we are observing is approximate 1 seconds. 

We wanted to debug the 1st point after wakeup to see which module is taking more time during wakeup.

We have tried to configure fastwakeup also, but in that case as well control is not jumping to user defined handler.

[danielmartynek]

Hi @harsh_95,

This issue may be caused by a waiting loop in your custom code, for example, waiting for the PLL to lock.
To monitor progress, you can enable and toggle a GPIO at various checkpoints in the code.
The MCU should wake up within the time period specified in the datasheet.
For any unpredictable behavior, the most common root cause is an incorrect system clock configuration. Ensure that all clocks are configured precisely according to one of the options listed in the reference manual (e.g., Table 158: Option B – Reduced Speed Mode with CORE_CLK @ 120 MHz).

Regards,

Daniel