MCU can't exit VLPS mode

[allenlw]

    We came across a problem that very much like the description of ERR011063 in the Mask Set Errata for Mask 0N57U, the platform we are using are S32K144 and TJA1169.

ERR011063: SMC: An asynchronous wakeup event during VLPS mode entry may
result in possible system hang scenario.
Description: When the bus clock is same system clock and an asynchronous wakeup occurs during a mode
transition from RUN to VLPS or VLPR to VLPS, the MCU may hang in an undetermined state,
which can only be recovered by a power-on reset event or a watchdog reset.
Workaround: Before executing the transition to VLPS ensure that the PREDIV_SYS_CLK frequency /
BUS_CLK frequency configuration for RUN/VLPR mode is greater than or equal to 2.
For example: Assuming a PREDIV_SYS_CLK of 8 MHz and SCG_RCCR[DIVCORE] =
0b0001 (divider of 2) and SCG_RCCR[DIVBUS] = 0b0001 (divider of 1), (PREDIV_SYS_CLK
= 8 MHz) / (BUS_CLK = 4 MHz) , a ratio of 1:2.

    When we enter the VLPS mode, we only have two interrupts: Systick and LPTMR, since we think our LPTMR interrupt timing can never coincide with transition to VLPS, that leaves only Systick.

    So my question is are Systick one of the Asynchronous wakeup?

    Another issue, according to the workaround of the ERR011063, PREDIV_SYS_CLK / BUS_CLK need to have a value greater than or equal to 2, our current DIVCORE and DIVBUS are 2, that means PREDIV_SYS_CLK / BUS_CLK is 4.But since PREDIV_SYS_CLK only available in S32K148, dose that mean this error can still happen in S32K144?

[Faker]

Hi expert:

  I use s32k144 that (PREDIV_SYS_CLK= 48 MHz) / (BUS CLK = 48 MHz) ,a ratio of 1:1. With this clock setting,mcu can hang in an undetermined state. What does phenomena of this state? Can it result reset pin to low voltage? 

[danielmartynek]

Helloallenlw ,

Systick in VLPS has been already discussed:
SysTick，VLPS ，Debug 

https://community.nxp.com/thread/504486 

Yes, this is an S32K144 0N57U erratum.
But if you follow the workaround and PREDIV_SYS_CLK / BUS_CLK >= 2, you should not see this.

The PREDIV_SYS_CLK is available on all the S32K1xx derivatives.

Could you please elaborate on the description of the issue?

Do you switch the system clock to SIRC before the transition to VLPS?
Are all the other clock sources disabled before VLPS?

Which peripherals does the application use?
Have you tried running the application stand alone without the debugger?
Do you monitor system clock externally using CLKOUT?

Thank you,

BR, Daniel

[allenlw]

1. Could you please elaborate on the description of the issue?

    The problematic piece we found stay in the VLPS, based on multiple test applications and corresponding current values.(We modify the application to force the software stay in different state, only the VLPS current value match the problematic piece)

2. Do you switch the system clock to SIRC before the transition to VLPS?

    Yes
3. Are all the other clock sources disabled before VLPS?

    All the clock besides LPO and SIRC are disabled

4. Which peripherals does the application use?

    Before entering the VLPS only SPI、LPTMR 、Systick and EEE(not sure if EEE is peripheral)
5. Have you tried running the application stand alone without the debugger?

    We are running without debugger, load the application with a bootloader.
6. Do you monitor system clock externally using CLKOUT?'

    No

[danielmartynek]

Hello allenlw,

If i understand, the MCU is not in an undetermined state but it stays in VLPS and cannot be bring back to RUN.

Please make sure that the interrupt that is the wake-up source in your application has the highest priority.

Or you could disable all the other interrupts.

Thank you,

BR, Daniel

[allenlw]

1. First we thought MCU is in an undetermind state, but our PREDIV_SYS_CLK / BUS_CLK is 4, so we are not so sure any more.

2. In the VLPS mode, we use LPTMR to wake it up, it works most of the time. But sometimes it stays in the VLPS, so we don't know what caused it.

[danielmartynek · Accepted solution]

Hello allenlw,

It is hard to say.

Have you tried disabling all the other interrupts including Systick?

And using the highest priority for the LPTMR interrupt?

Or on the contrary, try enable a GPIO interrupt as well to see if the issue is in the timer.

The LPTMR won't be able to wake up if, for example, SIRC is disabled in VLPS or the interrupts are masked etc.

Could you please make sure everything is set correctly before the MCU enters VLPS?

Thanks,

BR, Daniel

[allenlw]

Hi Daniel，

   We already try disabling the Systick add a internal WDOG for the future software, now we are just trying to find the exact reason for this situation ( it can only happen every ten thousand or more sleep procedures based on our continual tests for days).

[danielmartynek]

Hi allenlw,

Since it happens so rarely, it difficult to find the root cause.

Please try to isolate the issue by adding another interrupt, like GPIO mentioned above, and when LPTMR fails, use the GPIO.

What is the power consumption in VLPS?

Is it possible that the MCU goes back to VLPS immediately (sleep-on-exit)?

Please measure BUS_CLK on CLKOUT to see if the MCU really stays in VLPS.

It might be a SW issue though that disables something necessary before the MCU enter VLPS.

Can you share the project? So that we can check the configuration at least.

BR, Daniel

[allenlw]

Hi, Daniel

    Thanks for all the advices.

    As you said, it is difficult to find the root cause, so we are trying everything we can to optimize the software, wishing it will never happen again.

   As for the project, I can't share the it, since it is not just a demo project.