Quality RTOS & Embedded Software

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


xTickCount start value

Posted by m-wagner on October 24, 2016

Hi @all,

I'm doing some time calculations that use the OS tick as base. This requires me to analyze my apps behaviour on tick wrap over. As I don't want to wait until this happens, I now have to change FreeRTOS code to change xTickCount.

Is there a reason why the tick start value is not set to some value a few seconds/minutes before wrap over, like in Linux kernel (https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/include/linux/jiffies.h?id=a2b42342b2cb55d9b41ce36396334525f99ba17d INITIAL_JIFFIES )?

I know that this will not magically detect all wrap over errors, but it might help detect some :-)

Thanks, Martin

xTickCount start value

Posted by rtel on October 24, 2016

Sorry I don't know anything about the implementation of the Linux kernel. You can set the initial tick value to whatever you want - the FreeRTOS code as delivered tries not to have any variables initialised to anything other than 0 so as not to have variables outside the .bss section.

If you have configUSETICKLESSIDLE set to 1 you could also conceivable use vTaskStepTick() to push the tick count forward too, but probably the only safe way of doing that would be to create a single task, have that task call vTaskStepTick() to step the tick count forward by however many ticks you want, then create your other application tasks.

xTickCount start value

Posted by m-wagner on October 25, 2016

Thank you for your answer. Using vTaskStepTick() works for me.

Starting the tick at some special value is not Linux specific. I just used Linux as an example. ~~~ /* * Have the 32 bit jiffies value wrap 5 minutes after boot * so jiffies wrap bugs show up earlier. */

define INITIAL_JIFFIES ((unsigned long)(unsigned int) (-300*HZ))

~~~ This is done so that at 1 kHz the tick overflows for the first time after 5 minutes instead of ~50 days. The risk of having a hard-to-find error related to tick wrap over is thereby reduced a bit.

xTickCount start value

Posted by rtel on October 25, 2016

If it is useful to people I will add something similar to the FreeRTOS code.

xTickCount start value

Posted by davedoors on October 25, 2016

Set configUSE16BIT_TICKS to 0, then the tick will overflow every few seconds.

xTickCount start value

Posted by cmcqueen1975 on November 15, 2016

I would find it useful. Bugs related to wrapping may lurk in time delta calculations, so it's good if such wrapping occurs regularly during testing (after a device has been running for a few minutes) rather than once something is running "in the wild" for ~50 days.

#ifndef configTICK_COUNT_INIT
#define configTICK_COUNT_INIT    0u

Then in vTaskStartScheduler():

xTickCount = ( TickType_t ) configTICK_COUNT_INIT;

I've just been looking through the FreeRTOS 9.0.0 code to see if it looks safe in regard to wrapping. I came across this line in tasks.c which doesn't look right:

configASSERT( xNextTaskUnblockTime >= xTickCount );

Is that right, or will it fail when xTickCount gets close to wrapping? Should it instead be:

configASSERT( ( xNextTaskUnblockTime - xTickCount ) < ( portMAX_DELAY / 2u ) );

I also see:

if( xConstTickCount >= xNextTaskUnblockTime )

Should that be:

if( ( xConstTickCount - xNextTaskUnblockTime ) < ( portMAX_DELAY / 2u ) )

I also see the code fragment if( xTickCount >= xNextTaskUnblockTime ) mentioned in comments a couple of times. The comment probably needs updating to match the code.

xTickCount start value

Posted by edwards3 on November 15, 2016

Looks right to me. The tick count must never be ahead of the time a task needs unblocking, and xNextTaskUnblockTime is set to ~-1 (max TickType_t value) to wait for the tick count to catch up before wrapping.

[ 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.

Meet Richard Barry and learn about running FreeRTOS on RISC-V at FOSDEM 2019

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