Low Power with FreeRTOS: Tickless Idle Mode

Posted on July 6, 2013 by Erich Styger

It took me a while to find the time to upgrade to FreeRTOS V7.4.2, but finally it is done :-). What caused me to move from V7.2 to V7.4 is a low power application on the FRDM-KL25Z board. V7.4 comes with two major new features: Queue Sets and Tickles Idle Mode (see this article). The last one if of interest here.

FreeRTOS runs an IDLE task. This one runs when there is no other active task. That task calls an optional Idle task hook which is a perfect place to put the microcontroller into low power mode:

Task T1 Running

In above logic analyzer screenshot I have a task T1 running for about 10 ms, then it will be suspended for 1000 ms. So during this 1000 ms the microcontroller could be put to sleep :-).

FreeRTOS IDLE Task Hook

That IDLE task calls the vApplicationIdleHook():

FreeRTOS vApplicationIdleHook

In that hook function I can put my microprocessor into sleep mode, e.g. for the KL25Z this could be done like this:

/*
** ===================================================================
**     Event       :  FRTOS1_vApplicationIdleHook (module Events)
**
**     Component   :  FRTOS1 [FreeRTOS]
**     Description :
**         If enabled, this hook will be called when the RTOS is idle.
**         This might be a good place to go into low power mode.
**     Parameters  : None
**     Returns     : Nothing
** ===================================================================
*/
void FRTOS1_vApplicationIdleHook(void)
{
  /* Called whenever the RTOS is idle (from the IDLE task).
     Here would be a good place to put the CPU into low power mode. */
  Cpu_SetOperationMode(DOM_SLEEP, NULL, NULL); /* next interrupt will wake us up */
}

There are many different modes, but the easiest ones are the ones which use an interrupt as wake up source. So for the above source using DOM_SLEEP, the next interrupt will wake me up.

SysTick Interrupt

If any interrupt is a wake-up source, than this could be a timer interrupt or the the tick interrupt which is used as tick timer for the RTOS. On ARM cores the SysTick timer is typically used as the RTOS tick timer, but on other architectures any periodic interrupt timer can be used. And this is causing a problem: the SysTick interrupt will leave the low power mode. So this means that during that 1000 ms I get out of low power mode and back 100 times if I’m using a 10 ms SysTick period.

To illustrate this, I’m using this task code:

static portTASK_FUNCTION(Task1, pvParameters) {
  for(;;) {
    B8_SetVal(); /* Set I/O to 1 */
    /* do some work for 10 ms */
    B8_ClrVal(); /* Set I/O to 0 */
    FRTOS1_vTaskDelay(1000/portTICK_RATE_MS);
  }
}

Using the B8 pin I can see with a logic analyzer how long the task is active.

To see when a SysTick interrupt fires, I’m toggling an I/O pin in the vApplicationTickHook():

/*
** ===================================================================
**     Event       :  FRTOS1_vApplicationTickHook (module Events)
**
**     Component   :  FRTOS1 [FreeRTOS]
**     Description :
**         If enabled, this hook will be called by the RTOS for every
**         tick increment.
**     Parameters  : None
**     Returns     : Nothing
** ===================================================================
*/
void FRTOS1_vApplicationTickHook(void)
{
  /* Called for every RTOS tick. */
  B9_NegVal(); /* toggle I/O pin to see when interrupt fires */
}

With this, I get this on the logic analyzer:

Task with Tick Interrupts

The task T1 suspends for 1000 ms, and this would be an opportunity to be in low power mode for 1 second. But the SysTick constantly wakes the microcontroller up :-(.

The tick interrupt is needed for the RTOS so it can keep track of the time. However, the RTOS already should know how long the IDLE task will run, so a better solution could be used?

Tickless Idle Mode

The solution to this is the ‘Tickless Idle Mode’, added in FreeRTOS V7.4.0. It calculates the idle time and re-configures the SysTick:

Calculates the new timer value. So such as in my above example, instead of firing the timer every 10 ms until it reaches 1000 ms, it will try to set it up that it only fires once after 1000 ms.
Updates the task/system time.

Below is a picture how this looks in this Tickless Idle Mode: The tick interrupt only fires as needed :-). To illustrate the power mode, I’m using the B10 pin (HIGH if in low power mode, LOW if in run mode):

FreeRTOS Tickless Idle Mode

Implementation Details

There are a few limitations and points to consider:

Depending on the tick timer input clock and prescaler, the largest time span is limited. Typically, on ARM cores the SysTick is using the core/bus clock and has a 24bit counter register. This means that with a 20 MHz clock speed the largest ‘tickless time’ can be only up to 800 ms. The higher the clock, the less ‘tickless’ time is available. A solution would be to use a different tick timer source which might not always be possible. Or to lower the clock frequency.
20 MHz with 800 ms max Tick Duration
The tickless implementation in FreeRTOS needs to stop the tick timer momentarily in the routine vPortSuppressTicksAndSleep(). This means there is a tiny drift of the time maintained by the kernel. To compensate that drift, a compensation value can be provided. More about this below.
vPortSuppressTicksAndSleep() needs to find out if the tick interrupt or any other interrupt was leaving the low power mode. This is either done by reading the timer register, or checking a counter which is modified by the tick interrupt. Below is the same application as above, with a 64 ms timer interrupt:
Timer Interrupt with Low Power Tickless Mode

Processor Expert Implementation

FreeRTOS V7.4.x comes with tickless example ports for ARM Cortex M3/M4 (see this version). I have changed it so it works for Processor Expert and additional cores (e.g. S08, S12, ColdFire, Kinetis). While the Kinetis port only supports the SysTick, any other timer sources can be used otherwise. The Processor Expert implementation is available on GitHub.

The FreeRTOS component has new properties for tickless mode support:

FreeRTOS V7.4.2 Component with Tickless Idle Mode Support

“Tickless Idle Mode” is disabled by default and can be enabled with the new component. To compensate the timer drift (“Stopped Timer Compensation“, see above), a timer value to compensate can be provided (default 42). By default, the tickless mode is used if the expected idle time is larger than 2 ticks: with “Expected Idle Time” that value can be increased.

Inside port.c, the function vPortSuppressTicksAndSleep() implements the tickless idle mode. It is using macros for different timer implemenation (up/down counting modes).

The original RTOS API is using the macro configPRE_SLEEP_PROCESSING() to enter low power mode and the macro configPOST_SLEEP_PROCESSING() which is used on exit of the low power mode. I have found that this was not very user-friendly, so I defined Processor Expert events instead which are availble if Tickless Idle Mode is enabled:

Tickless Idle Mode Events

vOnPreSleepProcessing(): called to enter low power mode. An argument tells the duration of the tickless time. Here the application needs to enter low power mode and to wait for an interrupt. Additionally the application can disable peripherals or store values in non-volatile areas.
vOnPostSleepProcessing(): this event gets called after wake-up, so the application can restore the RAM or re-enable peripherals.

Below is an example implementation of the user application events:

/*
** ===================================================================
**     Event       :  vOnPreSleepProcessing (module Events)
**
**     Component   :  FRTOS1 [FreeRTOS]
**     Description :
**         Used in tickless idle mode only, but required in this mode.
**         Hook for the application to enter low power mode.
**     Parameters  :
**         NAME            - DESCRIPTION
**         expectedIdleTicks - expected idle
**                           time, in ticks
**     Returns     : Nothing
** ===================================================================
*/
void vOnPreSleepProcessing(portTickType expectedIdleTicks)
{
#if 1 /* example for Kinetis (enable SetOperationMode() in CPU component: */
  B10_SetVal(); /* set I/O pin to indicate low power mode */
  Cpu_SetOperationMode(DOM_SLEEP, NULL, NULL);
#endif
#if 0 /* example for S08 (enable SetWaitMode() in CPU: */
  Cpu_SetWaitMode();
#endif
#if 0 /* example for ColdFire V2: */
  __asm("stop #0x2000"); */
#endif
  /* Write your code here ... */
}

/*
** ===================================================================
**     Event       :  vOnPostSleepProcessing (module Events)
**
**     Component   :  FRTOS1 [FreeRTOS]
**     Description :
**         Event called after the CPU woke up after low power mode.
**         This event is optional.
**     Parameters  :
**         NAME            - DESCRIPTION
**         expectedIdleTicks - expected idle
**                           time, in ticks
**     Returns     : Nothing
** ===================================================================
*/
void vOnPostSleepProcessing(portTickType expectedIdleTicks)
{
  B10_ClrVal(); /* cear I/O pin to indicat end of low power mode */
}

❗ Do *not* use the IDLE hook FRTOS1_vApplicationIdleHook() to enter low power if using tickless idle mode, as otherwise the timing will be screwed up.

Summary

Microcontroller vendors offer many advanced low power modes. Unfortunately they are so complicated and hard to use in most cases. That way I see many applications which doe not use them at all. Sure: if my application is very tiny and does not need an RTOS, then usage of the ‘deep sleep’ modes is can be done, as there are few interconnection points. But as soon as many timers are used or an RTOS is running, things get complicated again. FreeRTOS offers an easy way to tap into low power modes with the IDLE task hooks and with the tickless Idle mode. That way it is really easy to reduce the energy consumption even with using an RTOS.

Problematic is the SysTick implementation by ARM as usually it is tight to the CPU clock: This means that running the CPU in the MHz area greatly limits the available time span offered by the SysTick timer.

I have implemented the tickless Idle mode in the Processor Expert FreeRTOS component available on GitHub. For Kinetis/ARM the SysTick is supported, while for the other architectures (S08, S12, ColdFire) any timer can be used which makes things even more low power. With tickless idle mode, the low power mode is extended and less interrupted. With this, lower current end energy levels are reached while using an RTOS.

Happy Ticklessing 🙂

35 thoughts on “Low Power with FreeRTOS: Tickless Idle Mode”

Pingback: Optimized FreeRTOS: Stack Check and SysTick for ARM Cortex Cores | MCU on Eclipse
Pingback: Tutorial: Using the FRDM-KL25Z as Low Power Board | MCU on Eclipse
Pingback: FreeRTOS for the Freescale DSC 56F8400 Core | MCU on Eclipse
Ga Il Lee on December 31, 2013 at 02:36 said:

Hello Erich,
How do you determine the value of “Stopped Timer Compensation”?
For example, if you set that value to ’42’, then would RTOS add 42 tick counts to Systick Counter
every time it wakes up?

Thank you,
GI

LikeLike

Reply ↓
- Erich Styger on December 31, 2013 at 20:10 said:
  
  Hi Gl,
  Have a look at the generated port.c and see the usage of ulStoppedTimerCompensation. The number of ticks is because temporarily the tick timer gets stopped to assign a new value for the next interrupt. So the number of 42 ticks get subtracted from the new value to compensate for the short time where the tick timer is *not* running. I have not fine tuned that value. If you want to do this, then measure the time (e.g. with toggling a pin and measuring it with a logic analyzer between
  DISABLE_TICK_COUNTER();
  and after
  SET_TICK_DURATION(ulReloadValue); /* Set the new reload value. */
  RESET_TICK_COUNTER_VAL(); /* Reset the counter. */
  ENABLE_TICK_COUNTER(); /* Restart tick timer. */
  
  Happy New Year!
  
  LikeLike
  
  Reply ↓
Pingback: IoT: FreeRTOS Down to the Micro Amps | MCU on Eclipse
Juan A Luna on July 14, 2014 at 13:38 said:

Hello Erich,

I have tried to test this new feature, but the project does not build. Using the Git refresh from today, I have a compiler error in port.c

void vPortInitTickTimer(void)

ulStoppedTimerCompensation = configSTOPPED_TIMER_COMPENSATION/(configCPU_CLOCK_HZ/configSYSTICK_CLOCK_HZ);

undefined identifier ‘CPU_CORE_CLK_HZ’

MCU is CFV1 (CN128)

Best regards,
Juan A Luna

LikeLike

Reply ↓
- Erich Styger on July 14, 2014 at 13:55 said:
  
  Oh well, I have used it only with Kinetis, so I might have something missed for ColdFire 😦 I need to check this tonight if possible.
  
  LikeLike
  
  Reply ↓
- Erich Styger on July 16, 2014 at 13:42 said:
  
  Hi Juan,
  I’m working on a fix for this. An easy patch for you could be that you patch the FreeRTOSConfig.h with this line:
  #define configCPU_CLOCK_HZ CPU_INSTR_CLK_HZ /* CPU core clock defined in Cpu.h */
  
  LikeLike
  
  Reply ↓
  - Erich Styger on July 17, 2014 at 08:20 said:
    
    Hi Juan,
    I have pushed a fix on GitHub:
    https://github.com/ErichStyger/mcuoneclipse/commit/019b94b200c167c45c7f8c69fb4d4da2f9390381
    I have tested it with S08 and ColdFire (CN128):
    https://github.com/ErichStyger/mcuoneclipse/commit/2d22c731a22fc4e218b3d053580d775e8100a4b9
    
    There is an important thing to use tickless idle mode with non-ARM and Processor Expert (and maybe I need to find a better way): you probably have a tick counter with say 6 MHz or so, and from this the modulo register sets it for an interrupt say every 10 ms (for the tick). You need to scale down that 6 MHz input clock to a slower one, say a few hundred kHz, otherwise the tickless idle mode does not work correctly. So if you have your RTOS tick timer configured for 10 ms, click on that value to enter the configuration/timing dialog for it. In that timing dialog, on the top you can configure the prescaler for the timer. By default, it is using ‘automatic’. Set that prescaler to the maximum value (e.g. divided by 128) so you get a slower base clock.
    I hope this is clear enough?
    
    LikeLike
    
    Reply ↓
Juan A Luna on July 21, 2014 at 09:24 said:

Hello Erich!

thanks for your help, with these changes it builds fine. I will test this afternoon the new consumptions.

For other side, now, I have the RTOS tick timer running at 36 KHz, with a prescaler of 1. I can use 1, 2 or 4, not more for achieve 10 ms of tick.

https://www.dropbox.com/s/oveqlojv9q120g3/Prescaler_1.bmp
https://www.dropbox.com/s/bov6tfuklnz240c/Prescaler_4.bmp

Best regards,
Juan A Luna

LikeLike

Reply ↓
- Erich Styger on July 21, 2014 at 10:06 said:
  
  Yes, that prescaler of 4 is what I would use too.
  
  LikeLike
  
  Reply ↓
acutetech on September 2, 2014 at 09:36 said:

I don’t know how common the tickless idle approach is, but I just saw this article on tickless idle in Segger’s embOS, should anyone be interested: http edn-europe.com/en/turning-off-the-tick-in-the-rtos-cuts-mcu-power-consumption.html

LikeLike

Reply ↓
- Erich Styger on September 2, 2014 at 14:04 said:
  
  It seems that many of the other RTOS did not care much about low power. But now it seems that they realized that tickless idle mode is a pretty straight forward and clean way to reduce power consumption, especially for ARM cores using the SysTick.
  
  LikeLike
  
  Reply ↓
alessandro on December 5, 2014 at 17:46 said:

Hi Erich,

thank you for your work: it’s higly appreciated!

I’m currently working on a Kinetis K11 CPU. I’m using the LPTMR as systick, and I’d like to use
the tickless mode feature. From what I’m reading, Kinetis port only supports the SysTick.

Do you think it could be possible to make it compatible with the LPTMR? The logic implemented in the current porting can’t be adapted for the LPTMR due to the fact that after a call to DISABLE_TICK_COUNTER (), the timer counter and compare flag register are reset.

Am I missing something?

Again, thank for your work!

Alessandro

LikeLike

Reply ↓
- Erich Styger on December 5, 2014 at 18:49 said:
  
  Hi Alessandro,
  my port of FreeRTOS already supports and uses the LPTMR (and tickless idle mode) at least with KL25Z. Not sure how much the K11 would be different, but you might give it a try.
  See https://mcuoneclipse.com/2014/02/09/iot-freertos-down-to-the-micro-amps/
  
  I hope this helps,
  Erich
  
  LikeLiked by 1 person
  
  Reply ↓
  - acutetech on December 5, 2014 at 19:33 said:
    
    Can I ask a supplementary question (and pass on a tip)?
    
    I’m using tickless idle on a KL05. A couple of different interrupt signals wake the processor as necessary (more accurately: two external signals drive LLWU pins and go high to wake the processor from Stop mode, and I have programmed the pins as level-sensitive active high interrupts so the processor sees the interrupt as soon as it wakes. I found that if I program the pins as edge-sensitive the processor misses the interrupts if the rising edge occurs while it is in Stop mode. It looks like I could call the interrupt event code from Cpu_OnLLSWakeUpINT(), but it seemed simpler to stick to level-sensitive interrupts). This seems to work as intended, though I have not done much testing.
    
    My question is this: is there any maximum time that can elapse with the processor in Stop mode? In my application, many days might elapse between the external interrupt events. I have no need for any task to run while waiting for these external events. I see your comment “the largest time span is limited”. I suppose I could get a task to sleep for (say) 800ms in a loop – but I really don’t need to wake, and this seems a waste (of battery). Is there any problem if I sleep for days? (I have the 32kHz crystal running to keep time and date, if that is relevant or useful).
    
    LikeLike
    
    Reply ↓
    - Erich Styger on December 6, 2014 at 16:11 said:
      
      Thanks for the tip!
      The processor can remain in STOP mode as long as possible. The issue is how much into the future the RTOS can delay the tick interrupt. The longer the tick period and the more bits in the tick counter register, the longer. For the LPTMR the tick period is fix at 1 kHz (1ms), and it is a 16 bit register. That way the LPTRM can be hold off for 1 minute max. The other approach is to suspend the RTOS and start it again after you have received your interrupt. For the RTOS the real time (RTC) does not matter: all what the RTOS deals with are the timer ticks.
      
      LikeLike
    - acutetech on December 11, 2014 at 17:38 said:
      
      Hi Erich
      Regarding your post that starts “The processor can remain in STOP mode as long as possible. ” – I am setting a pin in Cpu_OnLLSWakeUpINT() and clearing it in FRTOS1_vOnPreSleepProcessing(), so the pin is high more or less while the processor is running. I see expected activity as my external interrupts wake the processor etc. Then I noticed that, with no other activity, the pin pulses about every 66s (for about 28us). So I guess this is the 1kHz LPTMR driving the 16-bit register which overflows every 66s, wakes the RTOS which sleeps again. Actually, it pulses 10s after my last interrupt-driven activity, then every 66s after that. This is OK with me. But is it (a) expected behaviour and (b) safe? And why is there a pulse 10s after my last interrupt?
      
      Regards – Charles
      
      LikeLike
    - Erich Styger on December 11, 2014 at 19:48 said:
      
      Hi Charles,
      yes, that 66 seconds is very likely the overflow interrupt of the LPTMR. I suggest that you completely turn off that timer interrupt, and only enable it again after you have received your external interrupt?
      
      Erich
      
      LikeLike
  - alessandro on December 9, 2014 at 09:57 said:
    
    Hi Erych,
    
    thank you for the quickly answer!
    
    Well, actually you’re right. I was working with wrong beans/freertos versions, and the port.c file was different.
    I’ve updated to the last release and now it “seems” to work properly (I’ll do some more tests to be sure).
    
    Thank you again for your work.
    
    Alessandro
    
    LikeLike
    
    Reply ↓
    - Erich Styger on December 9, 2014 at 09:59 said:
      
      Hi Alessandro,
      good that this seems to be resolved 🙂 Let us know how it goes with your testing.
      Erich
      
      LikeLike
alessandro on December 10, 2014 at 15:41 said:

Hi Erych,

I’ve done some more tests and I’m still getting strange behaviors.

Actually, I’m working with the following setup:

– Kinetis K11DN512 as MCU (the LPTMR hardware peripheral logic is the same of the KL25Z);
– IAR compiler;
– PE components released on 2014-12-08 with FreeRTOS V8.0.1 (port.c version is the one linked here https://github.com/ErichStyger/McuOnEclipse_PEx/commit/c7a01b200915bf612b1277817186a788b36f7f97);

IAR COMPILER PROBLEM
The IAR port uses the vPortTickHandler defined in portasm.s. Compared with the GCC implementation (within port.c), the IAR version doesn’t have the piece of code regarding the tickless mode (#if (configUSE_TICKLESS_IDLE == 1) && configSYSTICK_USE_LOW_POWER_TIMER). The acknowledge of the TICK ISR is missing too (but I had already added that in my code).

Anyway, in my tests I’ve tried both versions of the vPortTickHandler (the IAR original one within portasm.s with the acknowledge of the TICK ISR added by myself, and the one based on the GCC implementation).

TICKLESS MODE PROBLEM
I’m getting strange behaviors using the tickless mode. As long as a low number of interrupt is involved, the tickless seems to work properly. Otherwise, the timing of tickless mode begins to be wrong.

In order to identify better the problem, I’ve done the following test (it should be replicable with little effort with different boards and compilers):

– LPTMR configured to use the internal LPO clock (1kHz) (configSYSTICK_LOW_POWER_TIMER_CLOCK_HZ -> 1000);
– FreeRTOS tick rate set to 1000 Hz (configTICK_RATE_HZ -> 1000);
– UART set to 115200bps as baudrate (in order to involve TX interrupt and wakeup the MCU from the WFI instruction in tickless mode);
– single task toggling a gpio and sending out via UART 40 bytes each 10ms;

Task code:

void task (void* parameters)
{
uint8_t buffer[] = { …40 bytes of data… };

while (1)
{
vTaskDelay ((TickType_t) (10 / portTICK_PERIOD_MS));

BIT_DEBUG_PE_NegVal (NULL);

UART_PE_SendBlock (UART_PE_DeviceData, buffer, sizeof (buffer));
}
}

Using the oscilloscope, BIT_DEBUG is toggling at ~250Hz (~4ms period, completely wrong).

I’ve tried also with the following configuration:

– UART and task unchanged;
– LPTMR configured to use the external 32kHz clock (configSYSTICK_LOW_POWER_TIMER_CLOCK_HZ -> 32768). In order to configure it correctly I changed, within port.c, LPTMR_PDD_SelectPrescalerSource(LPTMR0_BASE_PTR, LPTMR_PDD_SOURCE_LPO1KHZ); to LPTMR_PDD_SelectPrescalerSource(LPTMR0_BASE_PTR, LPTMR_PDD_SOURCE_EXT32KHZ);
– FreeRTOS tick rate set to 32kHz (configTICK_RATE_HZ -> 32768);
– changed #define portTICK_PERIOD_MS to (1000.0f/configTICK_RATE_HZ) (in order to avoid division by zero);

Using the oscilloscope, BIT_DEBUG is toggling at ~91.6Hz (~10.91ms period). The error is minor, but I’ve noticed that it increments along with the interrupts number:

– sending 1 byte each 10ms, BIT_DEBUG is toggling correctly at ~99.6Hz (~10.04ms period);
– sending 20 byte each 10ms, BIT_DEBUG is toggling ~95.6Hz (~10.46ms period);
– sending 40byte, as reported before, BIT_DEBUG is toggling at ~91.6Hz (~10.91ms period);

From what I’ve tested (but I’ve could missed something) tickless port is not implemented correctly OR IAR porting is missing something crucial.

If you’d like to take a look at my code, I could send to you a zip archive with the processor expert and iar projects.

Thank you again for your support!

Alessandro

LikeLike

Reply ↓
- Erich Styger on December 10, 2014 at 21:07 said:
  
  I need to replicate your setup, but I remember that I had worked with someone in the community to improve the timing in tickless idle mode. One issue for sure is that the timing of the LPTMR tick is not accurate: it is possible to miss one tick (1 ms) for each other interrupt. This might be the problem you are facing? Using a higher resolution timer like the SysTick would not show that behaviour.
  
  LikeLike
  
  Reply ↓
  - alessandro on December 11, 2014 at 08:54 said:
    
    Hi Erych,
    
    unfortunately I’m obliged to use the LPTMR as timer because it’s the only one available in LLS (Low Leakage Stop) power mode. Can you link me to the topic in the community where you talk about the tickless mode?
    
    It could be that one tick is missed for each other interrupt (which is why I tried to use the 32khz clock as reference in order to minimize the error to ~30us for tick), but I’m not 100% sure; it’s not easy to investigate the problem since the LPTMR operates normally also in debug mode, continuing to count.
    
    I’ll try to investigate deeper: my guess is that in order to minimize the error, the LPTMR should not be stopped and restarted when WFI exits due to an interrupt.
    
    LikeLike
    
    Reply ↓
acutetech on March 24, 2015 at 19:30 said:

A few insights that might be of use to people who are trying to use the RTC alarm interrupt in a KLxx processor with FreeRTOS:

I wanted an interrupt event to happen some seconds in the future. The RTC PE component mainly operates on times using a structure containing year, month, day, hour, minute, second, so it is easier to do time arithmetic by reading and writing the underlying RTC registers. So to set the alarm 10s in the future:
alarmTime = RTC_PDD_ReadTimeSecondsReg(RTC_BASE_PTR) + 10;
RTC_PDD_WriteTimeAlarmReg(RTC_BASE_PTR, alarmTime);

The RTC1_Alarm() event fired as I expected, until I put FreeRTOS into tickless idle mode. Then the interrupt came in, but after 66 seconds, regardless of the delay I used! The explanation is that for me, in tickless idle mode, with no other interrupts happening, FreeRTOS wakes every 66 seconds (overflow interrupt of the LPTMR). At that point the RTC interrupt is seen and runs.

The next thing to do is to enable the RTC interrupt as a LLWU source in the processor PE component. For the KL05 this is Internal Module 5 in the LLWU settings.

Finally, you have to clear the RTC interrupt in Cpu_onLLSWakeupINT():

wakeupReason = Cpu_GetLLSWakeUpFlags();
if (wakeupReason & LLWU_INT_MODULE5) { /* RTC */
RTC_PDD_WriteTimeAlarmReg(RTC_BASE_PTR, 0);
}

Why don’t I just use the FreeRTOS timers? They use too much RAM on the tiny KL05.

LikeLike

Reply ↓
Pingback: Regaining Debug Access of NXP i.MX RT1064-EVK executing WFI | MCU on Eclipse
Pingback: FreeRTOS: how to End and Restart the Scheduler | MCU on Eclipse
Nick on April 10, 2019 at 21:30 said:

Hi Erich,

Is your note to “not use the idle hook to enter low power mode if using tickless idle” still relevant? Processor Expert 3.0.0 now generates a function with this header:

/*
** ===================================================================
** Callback : free_rtos_vApplicationIdleHook
** Description : This callback occurs if the RTOS is idle. This
** might be a good place to go into low power mode.
** Parameters : None
** Returns : Nothing
** ===================================================================
*/
void free_rtos_vApplicationIdleHook(void)

which suggests that a call to POWER_SYS_SetMode() would be appropriate there, for instance.

Otherwise, would tickless idle implement similar behavior as going to STOP mode on a KL device?

LikeLike

Reply ↓
- Erich Styger on April 11, 2019 at 09:21 said:
  
  Yes, it is still relevant: there should be only one place where you enter low power mode and wait for an interrupt.
  With tickless idle mode, I do this in vOnPreSleepProcessing() only. Entering low power mode from the idle hook would screw up the timing.
  And yes, on a KL device you can go into STOP mode in vOnPreSleepProcessing(). If not using tickless idle, you can do this in the idle hook.
  
  LikeLike
  
  Reply ↓
  - Nick on April 11, 2019 at 15:24 said:
    
    Thanks Erich. In KSDK 1.3.0, I see mention in comments of your vOnPreSleepProcessing() function in `port/gcc/port.c` but no implementation or reference to it. I tried to add the entry as per your Github to my .pe file manually, but am getting an error upon refreshing the project. Do you have a separate guide for adding that functionality to Processor Expert?
    
    LikeLike
    
    Reply ↓
    - Nick on April 11, 2019 at 15:36 said:
      
      Aha, I realized I never imported your custom PE component. That seems to be what I’m missing.
      
      LikeLike
    - Erich Styger on April 11, 2019 at 18:48 said:
      
      yes, that tickless support is not present in standard FreeRTOS ports.
      
      LikeLike
Chandan Bhatia on September 19, 2020 at 10:01 said:

Nice blog, I did same experiment. First I set application hook vApplicationTickHook(), Inside same function I started toggling gpio X . I observed gpio X is toggling every 1 ms which was fine as per my systick configuration. Next I set configUSETICKLESS_IDLE to 1 so I can see gpio X is not toggling every 1 ms and system is working as expected.

Next I started looking for function vPortSuppressTicksAndSleep. Its default implemented week code, here we are calling WFI to go for sleep mode. Here I observed configPRE_SLEEP_PROCESSING and configPOST_SLEEP_PROCESSING micro. I used them to set GPIO Y low at configPRE_SLEEP_PROCESSING and GPIO Y HIgh at configPOST_SLEEP_PROCESSING . Here I observed something odd, GPIO Y was toggling like every 1mS which it shouldn’t and still GPIO X is working fine ( Its toggling like every 100-200ms). It seems odd, I am unable to understand this. Any suggestions. I am using FreeRTOS Kernel V10.0.1

LikeLike

Reply ↓
- Erich Styger on September 19, 2020 at 10:05 said:
  
  I believe you have something wrong in your port: have a look at my implementation which is on GitHub: https://github.com/ErichStyger/McuOnEclipseLibrary/tree/master/lib/FreeRTOS
  
  LikeLike
  
  Reply ↓