vTaskDelay() and vTaskDelayuntill()

I’m using FreeRTOS Kernel V10.3.1 where I have created two tasks in my development with unequal priority. To Block my first Task for 1 second I have passed vTaskDealy(1000) but it is not working as expected and blocking my first task for 100 seconds. Same I have tried with vTaskDelayUntil but the result remains the same.
Please suggest if I’m missing something.

this is my FreeRTOSConfig.h settings.


#include "hw_platform.h"
#include "riscv_plic.h"

/* See https://www.freertos.org/Using-FreeRTOS-on-RISC-V.html */
#define configMTIME_BASE_ADDRESS 	( ( PRCI_BASE ) + 0xBFF8UL )
#define configMTIMECMP_BASE_ADDRESS ( ( PRCI_BASE ) + 0x4000UL )

 * Application specific definitions.
 * These definitions should be adjusted for your particular hardware and
 * application requirements.
 * See http://www.freertos.org/a00110.html.

#define configUSE_PREEMPTION			1
#define configUSE_IDLE_HOOK				1
#define configUSE_TICK_HOOK				1
#define configCPU_CLOCK_HZ				( ( uint32_t ) ( 48000000) )
#define configTICK_RATE_HZ				( ( TickType_t ) 1000 )
#define configMAX_PRIORITIES			( 5 )
#define configMINIMAL_STACK_SIZE		( ( uint32_t ) 170 ) /* Can be as low as 60 but some of the demo tasks that use this constant require it to be higher. */
#define configTOTAL_HEAP_SIZE			( ( size_t ) ( 10 * 1024 ) )
#define configMAX_TASK_NAME_LEN			( 16 )
#define configUSE_TRACE_FACILITY		0
#define configUSE_16_BIT_TICKS			0
#define configIDLE_SHOULD_YIELD			0
#define configUSE_MUTEXES				1
#define configQUEUE_REGISTRY_SIZE		8
#define configUSE_RECURSIVE_MUTEXES		1
#define configUSE_MALLOC_FAILED_HOOK	1

/* Co-routine definitions. */
#define configUSE_CO_ROUTINES 			0
#define configMAX_CO_ROUTINE_PRIORITIES ( 2 )

/* Software timer definitions. */
#define configUSE_TIMERS				1
#define configTIMER_TASK_PRIORITY		( configMAX_PRIORITIES - 1 )
#define configTIMER_QUEUE_LENGTH		4

/* Task priorities.  Allow these to be overridden. */
	#define uartPRIMARY_PRIORITY		( configMAX_PRIORITIES - 3 )

/* Set the following definitions to 1 to include the API function, or zero
to exclude the API function. */
#define INCLUDE_vTaskPrioritySet			1
#define INCLUDE_uxTaskPriorityGet			1
#define INCLUDE_vTaskDelete					1
#define INCLUDE_vTaskCleanUpResources		1
#define INCLUDE_vTaskSuspend				1
#define INCLUDE_vTaskDelayUntil				1
#define INCLUDE_vTaskDelay					1
#define INCLUDE_eTaskGetState				1
#define INCLUDE_xTimerPendFunctionCall		1
#define INCLUDE_xTaskAbortDelay				1
#define INCLUDE_xTaskGetHandle				1
#define INCLUDE_xSemaphoreGetMutexHolder	1

/* Normal assert() semantics without relying on the provision of an assert.h
header file. */
#define configASSERT( x ) if( ( x ) == 0 ) { taskDISABLE_INTERRUPTS(); __asm volatile( "ebreak" ); for( ;; ); }

/* Defined in main.c and used in main_blinky.c and main_full.c. */
void vSendString( const char * const pcString );

#endif /* FREERTOS_CONFIG_H */

hope to hear a positive response from you soon.
Please clarify if I’m interpreting something wrong.

Thank you in advance.

You should use vTaskDelay(pdMS_TO_TICKS(1000)). However, with your configTICK_RATE_HZ of 1000, it won’t make a difference.

Can you check the tick count before and after the call to vTaskDelay? If the difference is ~100, then we need to check if your tick interrupt firing at the right frequency.


Dear Gaurav,

This vTaskDelay(pdMS_TO_TICKS(1000)) is also not working for me the condition remains same as I discussed eariler.
As per documentation if configTICK_RATE_HZ is 1000 then the OS kernel task switching will happen in 1 millisecond. am I right?
when I pass vTaskDelay(pdMS_TO_TICKS(1)) then my first task block for 1 sec.
please help.

Hello Avadhesh,

does your IDE provide a real time watch option? If so, you can pull the xTickCount system variable into the real time watch window (you may need to temporarily remove the static keyword). Choose decimal display. At 1ms clock configuration, you should see an increment of 1000 every second. If that does not happen, your clock/PLL and/or freertosconfig.h is misconfigured.

What is your target MCU and what is the clock/PLL configuration code? Frequently some misconfiguration causes the MCU to clock via HSI instead of HSE or vice versa in which case the configured configCPU_CLOCK_HZ does not match the true CPU frequency.

I’m using RISC-V 32-bit processor with 60MHz Oscillator clock.

So what about the test I suggested?

I’m using Eclipse based SoftConsole IDE where I’m not getting the real time watch point.
But I have emulated my development using RENODE emulator. it is working fine as expected
but in hardware it is not working.

To me, that sounds like one more indication that the processor initialzation does not setup your clock/PLL right. If your MCU has a clock out pin, can you check the signal with an oscilloscope? Can you look at the clock registers of your MCU to check what the actual configuration is?

In my previous reply i would like to emphasize that in my code I have define vTaskDelay(pdMS_TO_TICKS(1000)) to block my task for 1 second and it working with emulator but in hardware this delay is coming 100 seconds. what may cause for it?.
I have check my CPU clock it same what I have given in input.

I hope I have perfectly well understood what the symptoms of your problem are. I believe that there are two possible causes:

  1. Your MCU clock is misconfigured; thus, it is clocked not at the configured speed.
  2. Your MCU runs at the correct speed but your freertos config computes a wrong relationship between the core clock and the sys tick interrupt.

I was trying to give you a hint to narrow down your problem to one of the two causes.

I may be wrong in my assessment (I have in the past) in which case I ask for apologies.

The assessment from @RAc seems pretty reasonable. Can you check after how many ticks the tasks wake up? You can do so by examining the value of xTickCount global variable before and after calling vTaskDelay.

   1. Set a breakpoint on the following line.
   2. Note down the value of xTickCount.
   3. Set a breakpoint on the next line and let the program continue.
   4. Note down the value of xTickCount when the breakpoint set in step 3 is hit. 

This will tell us if the task is waking up after right number of ticks.

You can check if the MCU is running slowly by doing the following test:

  • Write a loop which runs a huge number of times.
  • Set breakpoints before and after the loop.
  • See if the loop takes similar amount of time both in emulator and hardware.