vTaskDelay and vTaskDelayUntil Strange Behavior

Hello all,

I am periodically enabling and disabling a PWM signal to send 7 pulses at a specified frequency and then delaying before sending another 7 pulses. I have been doing this by toggling on the output of this PWM signal, doing some calculations based on received data, and then using vTaskDelay to pause for 7ms before sending the next 7 pulses. For some reason, when I call vTaskDelay for 7ms I am only getting a delay of 6.3ms. This difference between the expected delay and the actual delay is consistent when increasing the delay (8ms becomes 7.3ms etc.) and it remains the same when I use vTaskDelayUntil(). Is this much of a difference between the expected and actual delay to be expected or is there likely something else going on that would cause it?

vTaskDelay(Until) is FreeRTOS SysTick based and the resolution is limited to portTICK_PERIOD_MS (see portmacro.h) resp. configTICK_RATE_HZ as documented here.
The same applies to the optional FreeRTOS timer feature.
For more precise timing you’ll need to use a HW timer.

1 Like

Thanks for the response. configTICK_RATE_HZ in my config file is set to 1000 and portTICK_PERIOD_MS is set to (1000 / configTICK_RATE_HZ). I am passing (7 / portTICK_PERIOD_MS ) into vTaskDelay. Since I am looking to get a delay of 7ms and the resolution is 1ms shouldn’t I expect to either 7ms?

With a tick period of 1ms you have a time granularity of 1ms using integer maths (no floating point). So a request for a 7ms delay will be close to 6.0001ms if the call to vTaskDelay() is immediately before the next tick interrupt (because the next tick counts as 1ms having passed as there is a resolution of 1ms), or close to 6.9999ms if the call to vTaskDelay() is immediately after the last tick interrupt. Most will be somewhere in between.


Oh that makes sense. Thanks for the help.

For future users, this page will help you.