Hello. I have been checking out the FreeRTOS development releases that implement tickless mode and, after realizing that SysTick was running slower than before on some STM32F4-based boards, I saw that the portNVICSYSTICKCTRLREG initialization in vPortSetupTimerInterrupt (ARMCM4F, tickless mode disabled) was modified to update only the INT and ENABLE bits instead of updating the complete register as before. In particular:

678c686
<   portNVIC_SYSTICK_CTRL_REG = portNVIC_SYSTICK_CLK_BIT | portNVIC_SYSTICK_INT_BIT | portNVIC_SYSTICK_ENABLE_BIT;
---
>   portNVIC_SYSTICK_CTRL_REG |= ( portNVIC_SYSTICK_INT_BIT | portNVIC_SYSTICK_ENABLE_BIT );

The CM4 standard states that the reset value of STKCTRL is 0x00000004 –i.e., default CLKSOURCE is the AHB clock. However from the debugger output I can see the value on my chip after reset is 0x0000_0000 instead, effectively selecting CLKSOURCE as AHB/8 and the reason for the slower behavior. Is there any rationale behind the change to bit ORing in the case of tick-mode vPortSetupTimerInterrupt function? I understand the code may be written directly from the standard but it seems the STM32F4 is deviant, at least the ones I have. Best regards.

Try the latest head revision now. It reverts to the old line:

portNVICSYSTICKCTRLREG = portNVICSYSTICKCLKBIT | portNVICSYSTICKINTBIT | portNVICSYSTICKENABLEBIT;

but sets portNVICSYSTICKCLKBIT to 0 if configSYSTICKCLOCK_HZ is defined. It is checked in with the following comment: “Force the SysTick clock bit to be set in Cortex-M3 and Cortex-M4F bits if configSYSTICKCLOCKHZ is not defined, otherwise leave the bit as it is found as the SysTick may use a divided clock.” Please let us know if this works for you or not. Regards.

That certainly fixes it. Many thanks.