Thread with vTaskDelay() runs periodically, but vTaskDelayUntil() seems to block the Thread indefinitely

Namaste Forum Member,

My development environment comprises of ESP32 DevKitC and Amazon FreeRTOS.

The Thread creation statement is as below.

xReturned = xTaskCreate( pvThread_A,
                         &pxHandleThread_A );

and, pvThread_A() is defined as below.

void pvThread_A( void * pvParameters )
    TickType_t xLastWakeTime;
    xLastWakeTime = xTaskGetTickCount();

        ESP_LOGI(TAG, "INFO : Running Thread_A");

        // Do nothing

        ESP_LOGI(TAG, "INFO : Calling vTaskDelay()");

        variable xLastWakeTime is updated internally
        vTaskDelay( pdMS_TO_TICKS(3000) );

//        variable xLastWakeTime is updated internally
//        vTaskDelayUntil( &xLastWakeTime, pdMS_TO_TICKS(3000) );

With vTaskDelay(), the console log is as below. The program executes as desired.

I (240) thread: INFO : Running Thread_A
I (240) thread: INFO : Calling vTaskDelay()
I (3250) thread: INFO : Running Thread_A
I (3250) thread: INFO : Calling vTaskDelay()
I (6250) thread: INFO : Running Thread_A
I (6250) thread: INFO : Calling vTaskDelay()

However when using vTaskDelayUntil() instead of vTaskDelay(), the console log just displays the below 2 prints and nothing after that.

I (240) thread: INFO : Running Thread_A
I (240) thread: INFO : Calling vTaskDelay() within Thead_A

I’m unable to understand, this behaviour? Am I missing something?

Thanks | Regards,

Can you break in with debugger and see what is happening when the system appears to hang?

Just to add to Jefftenney - put a break point on the call to vTaskDelayUntil() and step into that function to see what is going in, as there is nothing obviously wrong in the code you posted.

Namaste @rtel and @jefftenney,

On the breakpoint and debug recommendation, I’d like to mention that I’m using the Eclipse IDE for code browsing and, compiling the code over command line.

I was facing issues when configuring the Eclipse IDE for using the IDE’s Debug and Build options. I left it half way back then. But that’s a separate issue so won’t get into that.

I’ll have to explore the ESP-IDF’s tool to use the break-point and debug options over the command line. I’m not sure how soon I shall be able to revert with my observations.

Thank you again!

Thanks | Regards,

Namaste @rtel and @jefftenney,

Now here’s an interesting observation :thinking:

Just got a thought to verify the behaviour of vTaskDelayUntil() within a thread created using Iot_CreateDetachedThread() instead of xTaskCreate().

Thread creation statement is as below.

status = (int) Iot_CreateDetachedThread( pvThread_A,
                                         IOT_THREAD_DEFAULT_STACK_SIZE );

Interestingly, the Thread_A executes as desired, with the debug print statements being viewed on the console periodically. I further verified the observation by providing different time-periods to the vTaskDelayUntil() and, the observations match the expected result.

Thanks | Regards,

If IOT_THREAD_DEFAULT_STACK_SIZE is larger than TASK_STACK_SIZE, you may have stack overflow in your original code. A common stack-overflow handler is to simply hang.

Namaste @jefftenney,

Bingo! When using the xTaskCreate() API, the Stack size with #define TASK_STACK_SIZE 512 indeed seemed to be inadequate.

Within the Thread_A thread creation, replaced TASK_STACK_SIZE with IOT_THREAD_DEFAULT_STACK_SIZE and, the periodic debug prints are displayed on the console even with the vTaskDelayUntil() API.

Lesson learnt! Issue resolved. Happy. Thank you :smiley:

Thanks | Regards,