i.MXRT1064 - Issues with the Low Power docs and demos

[billchadwick]

Hi,

There seems to be lots of confusion about Low Power modes, WFI and Free RTOS tickless on i.MXRT.

There is very little talk anywhere about the power savings to be had from executiong WFI in the Run Modes (Overdrive, Full Speed, Low Speed, Low Power).

Experiments in this area are time consuming and error prone. There is a huge amount of detail that needs to be properly understood before something that works reliably can be achieved.

Some of my confusion stems from statements in https://www.nxp.com/doc/AN12085 and some from the code in the demo code in evkimxrt1064_power_mode_switch_rtos

The PDF has section 5.3.4 about tickless low power in FreeRTOS. It talks about how it is best to switch the SysTick clock to 100KHz, which is not done in the SDK demo, but finishes off by saying that you can't use SysTick for FreeRTOS tickless anyway as its interrupt is not imported in GPC. That might be true for Low Power Modes (System Idle, Low Power Idle, Suspend and SNVS). For the Run Modes, I believe the superior implementation of vPortSuppressTicksAndSleep in FreeRTOS port.c, which uses SysTick only, can be used for configUSE_TICKLESS_IDLE == 1 as long as bit 5 of CCM->CLPCR is cleared (1064 Ref Man para 14.7.16). It would be good if that was explained somewhere. Q1 - What are the consequences on power consumption of executing WFI with bit 5 of CCM->CLPCR cleared? See imxrt1052 systick under wfi & external source - NXP Community

I have experimented with a single, simple task that repeatedly sleeps for 500ms, then wakes briefly, I have  used

• configUSE_TICKLESS_IDLE == 2 with fsl_tickless_gpt
• configPRE_SLEEP_PROCESSING to switch to a low power run mode
• configPOST_SLEEP_PROCESSING to switch back to full speed run

I find though that the post sleep call is made much sooner than expected. In fact the system looks to oscillate many times between low and full power during the task's 500ms sleep. The debugger indicates that vPortSuppressTicksAndSleep  is coming out of WFI for a reason other than GPT timeout. Q2 - Why might that be, how can I find out what is causing the unexpected exit from WFI?

I expect that most folk exploring FreeRTOS and low power just want the MCU to enter a low power mode when Free RTOS is idle. I think a much simpler Power Saving LED blink demo would help for that.

A single task that periodically, uses a bit of CPU, toggles a LED and sleeps would suffice. Couple that with some implementations of either:

• Free RTOS Tickless 1 (using SysTick) for Run modes by implementing configPRE_SLEEP_PROCESSING and configPOST_SLEEP_PROCESSING hooks to switch power saving on / off.
• Free RTOS Tickless 2 (using GPT) for Low Power modes by implementing configPRE_SLEEP_PROCESSING and configPOST_SLEEP_PROCESSING hooks to switch power saving on / off.
• Free RTOS Tickless 0 (off), implementing an idle Hook to enter low power mode and WFI. After the WFI, switch to full power so ISRs run fast..

Q3 about the demo's Low Power Run mode. Is it safe to keep the 24MHz XTAL OSC on and the RC OSC off in this 24MHz run mode? We want to do this to keep an accurate PIT/GPT timer running form OSC_CLOCK during low power modes (we have PERCLK_CLK_SEL set for OSC_CLOCK).

Thanks in advance for any help that might be offered.

[Omar_Anguiano]

Hello

Hope you are well, I will gladly help you with your questions;
A1. If a clock remains enabled during a low power mode it is likely that the power consumption is a little higher than expected since the clock continues running.

A2. configPRE_SLEEP_PROCESSING() can set its parameter to 0 to indicate that its implementation contains its own wait for interrupt or wait for event instruction, and so wfi should not be executed again as you are suggesting.

A3. There is a risk when modules that are fed from that sources are working. PIT/GPT should be as stable as the external crystal since both sources come from that clock:

If you have more questions do not hesitate to ask me.
Best regards,
Omar

[billchadwick]

A couple more questions...

For a simple, rapid switch to and from a lower power mode, could we just flip the PeriphClock MUX to and fro between 24MHz OSC and 528MHz PLL? Must we wait for the PERIPH_CLK_SEL_BUSY to go not busy before running ISR code (after a WFI) ?

[billchadwick]

There look to be some errata in the description of the CCM CBCDR register in the 07-2021 i.MX RT 1064 Reference Manual.

The bit about PERIPH_CLK_SEL reads

Selector for peripheral main clock.
NOTE: Alternative clock source should be used when PLL is relocked. For PLL relock procedure pls refer
to the PLL chapter.
NOTE: Any change of this sync mux select will involve handshake with the MMDC. Refer to the CCDR
and CDHIPR registers for the handshake bypass and busy bits.
0 derive clock from pre_periph_clk_sel
1 derive clock from periph_clk2_clk_divided

There is no CCDR register in CCM and no use of the term MMDC elsewhere in the document.