[BUG] xTaskGetTickCount strange behavior causes xTaskDelayUntil to always fail

[ntd]

I think that my loop starts with a last wake up time (last) greater than the current time (tick, from xTaskGetTickCount) and #1339 does the rest, so xTaskDelayUntil becomes a no-op and fails always.

• Development board: ESP32-S3, dual core
• Instruction Set Architecture: XTENSA32 LX7?
• IDE and version: esp-idf 5.5.1
• Toolchain and version: xtensa-esp-elf esp-14.2.0_20241119
• Host OS: Archlinux

To Reproduce

#include "freertos/FreeRTOS.h"
#include <stdio.h>

static void loop(void *data)
{
        TickType_t last = xTaskGetTickCount();
        for (int i = 0; ; ++i) {
                if (xTaskDelayUntil(&last, 5) == pdFALSE) {
                        printf("Iteration %d too slow (last=%lu, tick=%lu)\n", i, last, xTaskGetTickCount());
                }
        }
}

void app_main(void)
{
        TaskHandle_t handle;
        xTaskCreate(loop, "TEST", 2048, NULL, 1, &handle);
        /* The following two lines trigger the issue */
        vTaskSuspend(handle);
        vTaskResume(handle);
}

With the above code, I get a busy loop that starts with:

Iteration 1 too slow (last=11, tick=2)
Iteration 2 too slow (last=16, tick=3)
Iteration 3 too slow (last=21, tick=3)
Iteration 4 too slow (last=26, tick=4)

Without vTaskSuspend/vTaskResume everything works as expected.

No idea how last can be greater than tick or if this is an issue specific to the dual core nature of the ESP32-S3 (i.e. the above code works on other architectures).

[kstribrnAmzn]

In your app_main function, where are you starting the scheduler by calling vTaskStartScheduler? You'll need to call this function before you can use xTaskDelayUntil OR xTaskGetTickCount.

[kstribrnAmzn]

You'll want to update your code to the following:

void app_main(void)
{
        TaskHandle_t handle;
        xTaskCreate(loop, "TEST", 2048, NULL, 1, &handle);
        vTaskStartScheduler();
        /* You shouldn't get here as vTaskStartScheduler does not return if the scheduler starts */
        return; 
}

[ntd]

app_main is a part of the ESP-IDF startup. It is called inside a task (called main_task) so the scheduler should be already running. To be on the safe side, I checked the scheduler state in app_main with xTaskGetSchedulerState and it was 2 (taskSCHEDULER_RUNNING).

This is more or less similar to the following (untested) code:

#include "freertos/FreeRTOS.h"
#include <stdio.h>

static void loop(void *data)
{
        TickType_t last = xTaskGetTickCount();
        for (int i = 0; ; ++i) {
                if (xTaskDelayUntil(&last, 5) == pdFALSE) {
                        printf("Iteration %d too slow (last=%lu, tick=%lu)\n", i, last, xTaskGetTickCount());
                }
        }
}

static void app_main(void)
{
        TaskHandle_t handle;
        xTaskCreate(loop, "TEST", 2048, NULL, 1, &handle);
        printf("Scheduler state=%d\n", xTaskGetSchedulerState());
        vTaskSuspend(handle);
        vTaskResume(handle);
}

static void main_task(void *data)
{
        /* Task initialization... */
        app_main();
        vTaskDelete(NULL);
}

void main(void)
{
        /* Hardware initialization... */
        TaskHandle_t handle;
        xTaskCreate(main_task, "main", 2048, NULL, 1, &handle);
        vTaskStartScheduler();
}

I'm using ESP-IDF, so I'm not entirely sure this is a vanilla FreeRTOS issue (ESP-IDF is shipped with a slightly modified version of FreeRTOS). Running the above code on another platform would help to check that.

[kstribrnAmzn]

I haven't tried to verify this hunch on a board (hoping to do so today) but I think I know what is going on. One assumption I'm making is that you have configUSE_TIME_SLICING enabled (seems like a safe bet per this post).

So what is happening is the execution of the two tasks is interleaved between ticks. I'll use the same naming strategy above. The flow looks like the following:

Tick 0: main_task executes. It creates the loop task and possibly prints out the scheduler state. It does not get to task suspend/resume just yet (this is very important - if suspend+resume is executed within tick 1 then this hunch falls apart).
Tick 1: Time slicing happens and it round robins to the next ready task of the same priority (aka loop). loop executes. It enters the first xTaskDelayUntil call with last == 1 (the tick count) and 5 for the period. It executes all the way through the function until the yield call. At this point loop becomes block and main_task is swapped in to execute. Main task calls suspend + resume which moves loop from blocked->suspended->ready. Then it deletes itself.
Tick 2: loop goes back to executing as it is the only task in the ready list. It completes and returns True as that was the calculated value when executing through xTaskDelayUntil last. Note: This is why you aren't seeing Iteration 0 too slow (last=6, tick=2) - it's returning True not False. Now it does the next iteration of the loop. When xTaskDelayUntil is called this conditional evaluates to false and it's essentially drop through the function, incrementing the pxPreviousWakeTime value by 5.
Tick 3 and onwards: Proceed much the same way - the condition evaluates to false and you have a runaway situation.

[kstribrnAmzn]

This diagram is taken from the Task States documentation. I've annotated it with red numbers to indicate the state ordering your going through.

I'm removing the bug label on this issue. This is not a bug. As the diagram shows, you can only go from the suspended state to the ready state. The timing of your suspend + resume calls are directly manipulating the task state. I will add the feature request label.

I'll leave this open for a few days to give you a chance to comment back.

[kstribrnAmzn]

Enhancement: Persist previous Blocked state information to allow for a task to transition from Suspended back to Blocked when calling vTaskResume

[ntd]

I haven't tried to verify this hunch on a board (hoping to do so today) but I think I know what is going on. One assumption I'm making is that you have configUSE_TIME_SLICING enabled (seems like a safe bet per this post).

I can confirm ESP-IDF has configUSE_TIME_SLICING enabled.

So what is happening is the execution of the two tasks is interleaved between ticks.
[...]

That surely explains everything! Basically the suspend/resume pair forced my blocked task into the READY state, xTaskDelayUntil returned successfully without waiting and its surprising behavior (well, at least for me) made the rest.

[aggarg]

No idea how last can be greater than tick or if this is an issue specific to the dual core nature of the ESP32-S3 (i.e. the above code works on other architectures).

This seems really strange. Would you please increase stack size to rule out stack corruption?

[ntd]

No idea how last can be greater than tick or if this is an issue specific to the dual core nature of the ESP32-S3 (i.e. the above code works on other architectures).

This seems really strange. Would you please increase stack size to rule out stack corruption?

No corruption occurring here: this comment explains what it is really happening. The suspend/resume calls force xTaskDelayUntil to quit without waiting (the task state is forced to READY), so last has been incremented while tick hasn't.

[kstribrnAmzn]

One thing you could do to disprove my theory would be to increase the actual tick period. If your current tick period is 1ms then increasing it to something like 10ms could actually make the problem go away. This is because the main task could complete all of it's work within the tick which should mean that the loop task is only executed after the suspend+resume calls. If the loop task is executed after the suspend+resume calls then suspend+resume would have no effect on the loop task and it should work as expected.