Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


Cortex M3 Tickless Idle

Posted by Phil B on August 14, 2013
I'm trying to understand the CM3 / GCC port implementation of vPortSuppressTicksAndSleep. I think I understand everything except for the behaviour when entry to low power mode is aborted due to eTaskConfirmSleepModeStatus() returning eAbortSleep.

/* If a context switch is pending or a task is waiting for the scheduler
to be unsuspended then abandon the low power entry. */
if( eTaskConfirmSleepModeStatus() == eAbortSleep )
/* Restart SysTick. */

/* Re-enable interrupts - see comments above the cpsid instruction()
above. */
__asm volatile( "cpsie i" );

My understanding from the CM3 core documentation is that writing NVIC_SYSTICK_ENABLE_BIT will reload the value from the SYSTICK_LOAD_REG and start counting down. Thus if the entry into sleep mode is aborted, the SYS_TICK interval is restarted, loosing any of the tick period that has elapsed so far.

Given the amount of effort expended in trying to correct for lost clocks to the SYS_TICK timer when it is disabled and then re-enabled when the tick-less period is generated by extending the SYS_TICK period, this seems like a bit of an oversight. I therefore expect I've missed a subtlety in the implementation.

Can someone (Richard?) explain what I've missed and why restarting the SYS_TICK timer without making a prior adjustment to the reload register is OK?


RE: Cortex M3 Tickless Idle

Posted by Richard on August 15, 2013
You are correct, this is an anomaly. It is very hard to get the code to go through that path, but for completeness it should be fixed.

I think copying the current count value into the reload register, starting the timer, then resetting the reload register back to its "normal" value for a tick period should be ok.

Do you agree?


RE: Cortex M3 Tickless Idle

Posted by Phil B on August 15, 2013
Thanks Richard, that's exactly how I would resolve the issue.

There's obviously going to be a small drift due to the time taken to execute eTaskConfirmSleepModeStatus which I guess could be estimated in the same way you've already done for the other path, but given the likely infrequent execution of this path compared with the normal path, it's probably not that important. I think it's reasonable to expect some drift when using tick-less idle.



[ Back to the top ]    [ About FreeRTOS ]    [ Privacy ]    [ Sitemap ]    [ ]

Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

Version 10.1.1 of the FreeRTOS kernel is available for immediate download. MIT licensed.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


FreeRTOS and other embedded software careers at AWS.

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers


STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner