vPortSetupTimerInterrupt changes break STM32F4

pbleyer wrote on Sunday, December 15, 2013:

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 portNVIC_SYSTICK_CTRL_REG initialization in vPortSetupTimerInterrupt (ARM_CM4F, 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 STK_CTRL is 0x0000_0004 --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.

rtel wrote on Sunday, December 15, 2013:

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


portNVIC_SYSTICK_CTRL_REG = portNVIC_SYSTICK_CLK_BIT | portNVIC_SYSTICK_INT_BIT | portNVIC_SYSTICK_ENABLE_BIT;

but sets portNVIC_SYSTICK_CLK_BIT to 0 if configSYSTICK_CLOCK_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 configSYSTICK_CLOCK_HZ 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.

pbleyer wrote on Monday, December 16, 2013:

That certainly fixes it. Many thanks.