S32K11x VLPS to RUN

[Francesco_Solito]

Hello

I'm finding some trouble when I switch my application from RUN to VLPS and then again to RUN.

Normally everything works correctly but sometimes it seems to fail and my application resets for watchdog event.

I'm using the SDK 4.01, so please let me know if invoking "POWER_SYS_SetMode(VLPS, POWER_MANAGER_POLICY_AGREEMENT);" is enough or if I have to make something else.

Is the switch from VLPS to RUN automatic when an interrupt happens? (LIN or LPTMR for instance). At the moment I'm invoking POWER_SYS_SetMode also for RUN mode.

Please note that:

if I use the STOP1 or STOP2 mdoe instead of VLPS, I don't have trouble (no resets);

if I use VLPR instead of VLPS, I always have trouble (continously resets).

If I use VLPS (that is my aim) I sometimes have troubles (often resets)

Please let me know as soon as you can.

Thank you and kind regards,

Francesco

[danielmartynek]

Hi @Francesco_Solito,

You need to disable all the peripherals that are not used in VLPS.

Then, call POWER_SYS_SetMode(VLPS), which disables all the clocks (except SIRC if used in VLPS).

After the wakeup, call POWER_SYS_SetMode(RUN) to reenable all the clocks, and enable all the peripherals the application needs.

Regarding the WDOG, I would recommend that you measure the execution time of each API.

Since the SOSC clock must be disabled in VLPx, the SOSC startup in RUN takes some time.

Regards,

Daniel

[Francesco_Solito]

Thank you for your answer.

What is a good point where I can put the call to the POWER_SYS_SetMode(RUN)? In the main loop or in each possible wake interrupt?

Consider that my system can be awaken by LIN, by a timer (LPTMR0) and by external interrupts.

I don't use the SOSC clock in my application.

Is there a way to check into software that all the clocks and peripherals have switched to the selected power mode? Or checking the return value of POWER_SYS_SetMode is enough to be sure that everything has completed?

Please let me know as soon as you can.

Thank you and kind regards,

Francesco

[danielmartynek]

Hi Francesco,

In general, the ISRs should be as short as possible, the system clock switching takes some time.

You can use the CLOCK_SYS_GetFreq() of the clock driver to verify the clock.

[Francesco_Solito]

Hello

Thank you very much, but It's not clear to me where to put the call to POWER_SYS_SetMode(RUN). In each ISR that can wake-up my system? Or in the main loop?

Is the CLOCK_SYS_GetFreq() already called into POWER_SYS_SetMode()? Or do I have to call it explicitly?

What could be the explanation that if I use STOP1/STOP2 I don't have troubles, instead if I use VLPS I have troubles?

I noticed that in my project the OSIF is instantiated. Could there be something related to this?

Please try to answer point by point so it is simpler to me to bettere understand.

Thank you very much and kind regards,

Francesco

[danielmartynek]

Hi Francesco,

As I said, in general, ISRs should not be that long, POWER_SYS_SetMode() should be called from main().

Calling CLOCK_SYS_GetFreq() is up to you, if you want to confirm a clock configuration. The POWER_SYS_SetMode() sets the clocks.

Not sure about the OSIF. Can you disable the WDOG and see where it is stuck?

Is the core waiting in a loop for a flag to be set, like a clock valid flag etc.

Thank you,

Daniel

[Francesco_Solito]

Hello. Thanks for suggestions.

I tried to disable the WDOG, but when the system fails I'm not able to see where it is stuck, because the debugger looses the communication.

I also tried putting a debug pin toggling in some critical part of the sofware, but I still didn't discover the problem. What I noticed with my debug pin is that I set to 1 the pin before calling POWER_SYS_SetMode(VLPS, POWER_MANAGER_POLICY_AGREEMENT) and I clear it to 0 after POWER_SYS_SetMode(VLPS, POWER_MANAGER_POLICY_AGREEMENT); what I see in the oscilloscope is that when the issue happens the debug pin remains high, as if the application was stuck into POWER_SYS_SetMode or as if interrupt were disabled. So I also checked global interrupts, but they are correctly enabled also when the issue happens.

I also tried increasing heap and stack in the linker file, but the issue happens anyway.

Only with STOP1/STOP2 the issue doesn't happen. Does this suggest something to you?

Thank you very much.

Kind regards,

Francesco

[danielmartynek]

Hello Francesco,

If the debugger loses the connection, the MCU is in the VLPS mode. But I would recommed that you measure the power consumption of the MCU. After the wakeup event, you should see an increase in the power consumption again.

You could use CLKOUT to output any system clock, e.g. the BUS_CLK. This example uses CLKOUT:

https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K144-RTC-VLPS/ta-p/1119655

So, you should see when the MCU enters VLPS, when it leaves VLPS, and when the power driver changes the clock configuration.

The GPIO should be cleared as the first thing in the wakeup interrupt not after POWER_SYS_SetMode(VLPS).

Also, make sure you don't call POWER_SYS_SetMode(VLPS) from an interrupt routine.

Regards,

Daniel