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

Kernel
1

Namaste Forum Member,

My development environment comprises of ESP32 DevKitC and Amazon FreeRTOS.

The Thread creation statement is as below.

xReturned = xTaskCreate( pvThread_A,
                         "Thread_A",
                         TASK_STACK_SIZE,
                         NULL,
                         TASK_PRIORITY_ONE,
                         &pxHandleThread_A );

and, pvThread_A() is defined as below.

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

    while(1)
    {
        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,
Dipen

2

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

3

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.

4

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 idf.py 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,
Dipen

5

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,
                                         NULL,
                                         IOT_THREAD_DEFAULT_PRIORITY,
                                         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,
Dipen

6

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.

7

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,
Dipen