Time slicing frequency mismatch in STM 32 (nucleo H743ZI)

vigneshtamilani wrote on Thursday, July 25, 2019:

I have a NUCLEO-H743ZI ARM STM32 Nucleo-144 development board with STM32H743ZI MCU and am just trying to understand freertos and scheduling. I programmed 2 simple tastsk to glow the LED in the board. Task 1 swiches off all other LED and glows one , task 2 swiches off all and glows one LED respectively. When I set the time slice in the freeRTOSConfig.h file in the range of 5hz to 1000hz and check the led blinking in osciloscope, I get the right frequency and time slice in ms but, if i set it lower that 5hz (1-4hz) I am not getting the same Hz in the oscilloscope. The values I get for
4hz in cofiguration = 25hz in oscilloscope
3hz in cofiguration = 8hz in oscilloscope
2hz in cofiguration = 12.5hz in oscilloscope
1hz in cofiguration = 6.25hz in oscilloscope
I am not able to understand this behaviour. Is there a range to the time sliceling?

rtel wrote on Thursday, July 25, 2019:

Can you please post the C code so I can see how you are calculating the
times - it might be an integer rounding/truncating problem with one of
the macros such as pdMS_TO_TICKS().

vigneshtamilani wrote on Monday, July 29, 2019:

Sure I’ll share the C code but I’m not doing anything to calculate the time in it. I’ve just set the time slicing value as 1-100 Hz in the FreeRTOSConfig.h and most of the configuration was already auto generated for me from the STMcubemx software when I created the project.
Thanks

richard_damon wrote on Monday, July 29, 2019:

If you are sayiing you are setting the tick rate very slow, it may be that you are asking for a tick divider bigger than the software can physically divide the processor clock to generate.

If your processor is running at say 80 MHz, and the tick counter is a 24 bit counter, then its maximum divisor is 16,777,216 which gives you a tick rate of 4.768 Hz, When it computes the divider for 4 Hz, it gets 20,000,000 which is too big for the hardware, and due to roll over gets the value of 3,222,784 (20,000,000 - 16,777,216) which gives you about 25 Hz.

I don’t know if that counter has a prescaler to allow it to get bigger dividers (at less precision) but the code is assuming that you don’t need it as generally you use a tick rate higher than that.

richard_damon wrote on Monday, July 29, 2019:

If you are sayiing you are setting the tick rate very slow, it may be that you are asking for a tick divider bigger than the software can physically divide the processor clock to generate.

If your processor is running at say 80 MHz, and the tick counter is a 24 bit counter, then its maximum divisor is 16,777,216 which gives you a tick rate of 4.768 Hz, When it computes the divider for 4 Hz, it gets 20,000,000 which is too big for the hardware, and due to roll over gets the value of 3,222,784 (20,000,000 - 16,777,216) which gives you about 25 Hz.

I don’t know if that counter has a prescaler to allow it to get bigger dividers (at less precision) but the code is assuming that you don’t need it as generally you use a tick rate higher than that.