Changing power modes on the MK22

[roger5]

I'm trying to implement low power operation (Very Low Power Run) into an existing project which already works fine, using HS Run.

I've copied code from the frdmk22f_power_manager SDK example into my project, but the application crashes in APP_SetClockVlpr() calling

CLOCK_SetInternalRefClkConfig(kMCG_IrclkEnable, kMCG_IrcFast, 0U);

My hardware uses a 12.288Mhz clock rather than the 8Mhz clock used on the development board, which the SDK example was written for, but I can't see any configurations in CLOCK_SetInternalRefClkConfig() which would be dependent upon the clock speed.

I suspect that perhaps the problem may be something to do with the NVIC setup and perhaps I'm missing an interrupt handler associated with changing modes, but I've looked though the example code, and I can't see anything ISR's I'd need to define for use of the Very Low power Run mode, as this mode does not involve stopping the processor and waking via an interrupt

But I must have missed something.

Does anyone know where I may be going wrong?

Thanks.

[roger5 · Accepted solution]

I'm going to close this as accepted, because I am able to change power modes, albeit under some conditions it seems to cause the code to reboot.

I think a lot of my problems are being caused by using FreeRTOS and I may try to rewrite the application not using an RTOS

[diego_charles]

Hi @roger5 

Many thanks for the update!

If you think that we may help with other regards, you can create a new post.

I'm going to close this as accepted, because I am able to change power modes, albeit under some conditions it seems to cause the code to reboot.

If it helps, as an additional comment for reboot:

You can track the cause of reset by reading the status of RCM_SRSx registers. I think that the power mode example does something similar   to let you know the reason of the MCU wake up.

For example, there are peripherals with restraints like the flash.  I remember a situation where the flash was being gated of by code before entering to VLLS mode .And that produced a reset every time the MCU was entering to VLLS mode.

Tracking down the issue we found out that RCM_SRS1[SACKERR] bit was on. In that very particular case, the solution was not to gate of flash to avoid the reset error. Anyway, on that chip,  the flash was going to be gated of when entering the desired VLLS mode.

All the best,

Diego.

[roger5]

Thankyou.

We eventually tracked down the problem to being a local variable in the function to change run modes, that was effectively being used outside local scope.

Specifically the Notifier code has a struct of data which is in global scope but referenced some data in local scope, which would have been on the stack

The problem only occurred when the function was called from a different depth in the stack, because prior to that, calling the function was working, because the data on the stack had not been overwritten.

I do have some other questions about whether its possible to change clock freq and keep USB peripherals running, as so far I've not managed that, and also how to just change the clock frequency and not the Run Mode, but those are separate problems and I may open another question.

Thanks again for your reply...

[roger5]

I amusing a MK22FN512LL

I have now isolated the problem to only occurring if I attempt to change run mode when using FreeRTOS

I integrated code from the "frdmk22f_power_manager" SDK example, and I can change run mode from main()

But if I try call my function to change run mode from inside a FreeRTOS task, I get a immediate hard fault in  prvPortStartFirstTask()

I put the code to change mode in the beginning of the first task that I create.

I changed the FreeRTOS configuation to use Tickless Idle

#define configUSE_TICKLESS_IDLE 1

But, I must need to change something else, to make FreeRTOS compatible with the change to run mode, but I could not find any information about this.

Thankyou

[ErichStyger]

Hi @roger5 ,

just to verify the obvious: if you get a hardfault from that task: make sure you have enough stack space allocated for it so we can rule out the problem of a stack overflow in your task.

Tickless Idle is something not related imho as it suppresses some not needed tick interrupts and does not deal with the low power mode itself (see Low Power with FreeRTOS: Tickless Idle Mode | MCU on Eclipse), except you are doing something wrong in the check hooks for it: but have tickles idle turned off until you have found the problem for the hard fault.

I hope this helps,

Erich

[roger5]

Thanks.

I just managed to figure out the problem

It wasn't the stack, it was because I'd setup the Notifier configurations array in

main()

before the RTOS started, and I called a function from inside the "Primary" RTOS task, that used that data.

When I single stepped in the debugger into

NOTIFIER_SwitchConfig()

And looked I could see that the callback pointer was null (0x00)

Strangely, the other data seemed OK, so I don't know why only the callback pointer was null

Anyway, I need to do some more testing, things are looking good so far.

[roger5]

Actually, I spoke to soon.

It seems to be unreliable.

[ErichStyger]

What FreeRTOS port are you using?

Note that some FreeRTOS ports do reset the MSP (where interrupt happen and where the local variables in main() are).

See ARM Cortex-M Interrupts and FreeRTOS: Part 3 | MCU on Eclipse

So if you have still variables on the stack, either move them as a global variable or disable resetting the MSP. I control this with the following setting:

#ifndef configRESET_MSP
  #define configRESET_MSP                         (1)
   /*!< 1: reset MSP at scheduler start (Cortex M3/M4/M7 only); 0: do not reset MSP */
#endif

[roger5]

I'm using FreeRTOS Kernel V10.0.1  which was the latest version when the code development started (last year)

It looks like the developer who wrote the original code for the project, may have made a mistake with the core clock frequency, as the board is fed by an external clock frequency of 12.288Mhz instead of 8Mhz, and I can't see anything different in the clock configuration  to compensate for this.

Because of this custom frequency is required for synchronization with specialist data decode IC's, I thought the decision was made to slightly overclock the core frequency to 122.88Mhz, but when I call

CLOCK_GetFreq(kCLOCK_CoreSysClk)

its showing 184.32Mhz

So either that function is not returning the correct value, because the definitions being  incorrect, or it is correct and the processor is being accidentally overclocked.

I'm trying to contact the previous developer, but he's not replied yet.

So I think I'm going to have to check all the PLL and divider settings.

I'm now trying to find a example calculation for how to set the MCG PLL to 10 or possibly 8 instead of 15

[roger5]

Following on..

I now mostly have this working, except when trying to change from HSRun to Run, in different parts of the system, I get the hard fault problem.

I'm currently trying to track down, whether this problem is being caused by entering HSRun in a sub function, but switching back to run, in a different function, possibly with different stack depths.

If I put both the change to HSRun Run in the same function it seems to be OK.

I also need to find out how to change clock speeds but stay in Run mode. As the power manager SDK example does not have an example of how to do this

[diego_charles]

Hi @roger5 

I hope you are doing excellent during this times.

Could you help me with the following :

1. Are you doing a transition from HSRUN to VLPR directly? or does the application presents similar issues when transitioning from RUN to VLPR mode?
2. Could you let us know your MK22 full part number?

Thank you in advance,

Diego