systick slow start on CortexM0+ port with STM32L051C8, bug?

lobaro wrote on Friday, January 13, 2017:


we use the STM32l051c8 CortexM0+ MCU with the gcc port ("…portable/GCC/ARM_CM0") on FreeRTOS V9.0.0.

The mcu is clocked by the MSI sysclock (~4.2MHz) and had a problem with the prvSetupTimerInterrupt function.
On this MCU the reset value of the systick count ( @ Adr 0xe000e018 ) is 0xFFFFFF. The M0 port does not init the current value register. Moreover the systick current value is above the initialized reload value. This leads to the problem that (at least with this MCU) the systick has to count down to zero for full 24bits. With our setup this brings a ~4seconds delay before the first systick irq is executed…

Our solution was add a reset of the current value register in prvSetupTimerInterrupt to zero:

#define portNVIC_SYSTICK_CURRENT_VALUE		( ( volatile uint32_t *) 0xe000e018 )

void prvSetupTimerInterrupt( void )
	/* Configure SysTick to interrupt at the requested rate. */
	*(portNVIC_SYSTICK_LOAD) = ( configCPU_CLOCK_HZ / configTICK_RATE_HZ ) - 1UL;


rtel wrote on Friday, January 13, 2017:

Hi Tobias - thank you for taking the time to report this. I think this
issue has already been noted and fixed.

pkinzer wrote on Friday, February 10, 2017:


This bug still exists in FreeRTOS v9.0.0, for the ARM CM0 port, using IAR. I happen to be using it on an STM32F091 part. The source clearly does not initialize the SYST_CVR register. This particular part has a power-up value of 0xFFFFFF, which results in a 350ms delay before the first tick occurs, at 48MHz. My solution was to use the CMSIS call, which properly initializes the SysTick peripheral, so the first tick occurs in 1mS, in my case:

static void prvSetupTimerInterrupt( void )

It now works as expected, in 1mS, the first SysTick interrupt occurs. This one took me a while to track down, but it was an interesting challenge. :slight_smile: See section 4.4 of the official ARM Cortex-M0 Generic User Guide for details on the SYST_CVR register:



rtel wrote on Friday, February 10, 2017:

See line 252 (at the time of writing) in the following file:

…it has been fixed. If you think the fix is wrong please let us know.