S32K144 VLPR to RUN power mode switch failure with external crystal oscillator

[manujagrawal]

Hey NXP team, @dianabatrlova  @danielmartynek 

I have a  problem during the S32K144 controller power mode switch from VLPR to RUN mode when the microcontroller uses SPLL as clock source with external crystal oscillator

When I am using the example project given in NXP design studio it is working properly, it is done with FIRC as system clock source.

The issue is specifically with VLPR mode to RUN mode switch. RUN to HSRUN and vice versa works properly,  VLPR to VLPS and vice versa works properly. RUN mode to VLPR is not an issue. But when switching from VLPR to RUN mode with clock source as external crystal oscillator mode, it is going to DEV_ASSERT.

I am attaching my project, It's name is "power_mode_switch_s32k144_ExternalClock" which is not working from external clock source and also attaching example project from NXP with internal clock, it's name is "power_mode_switch_s32k144" which is working properly.

Please help me in finding the solution to this. 

Regards

Manuj Agrawal

[manujagrawal]

Hi @danielmartynek 

Thank you so much for your help.

• I tried your solution and it worked very well. However is there a way to do it without making changes to the driver? Since switching from VLPR to RUN using external crystal is a very standard and common thing to do, I am expecting that NXP's standard SDKs are designed to support this.
• Also for FLEXCAN, in RUN mode we have used PE clock as oscillator clock (8MHz) and module clock as SYS_CLOCK (80MHz). Since CAN can only support SIRC clock in VLPR, this may change the FLEXCAN bit rate after switching from RUN to VLPR. Could you please suggest steps to manage the FLEXCAN driver and its configuration for smoothly switching from RUN to VLPR? 

Thanks and Regards 

Manuj Agrawal 

[danielmartynek]

Hi Manuj Agrawal,

I don't think there is a way to fix it without any modification to the driver.

Let me report it to the SDK team.

Regarding the FlexCAN, can you please create a new thread?

Thank you,

BR, Daniel

[danielmartynek · Accepted solution]

Hi Manuj Agrawal,

This is because the SPLL CLKis not valid yet when the CLOCK_SYS_GetSysPLLFreq() function is called.

You can read the return value of SCG_GetSpllStatus(SCG) until the clock is valid, something like this:

Regards,

Daniel