Support for FreeRTOS xTaskAbortDelay() (IDF-158)

[ammaree]

In order to facilitate graceful shutdown and restart of our application we require the ability to take (primarily network) tasks out of a blocked state and force them through their cleanup and termination process.

I have scanned the current FreeRTOS source and noticed that this function is only referred to through its INCLUDE_ macro but nothing implemented. Are there any plans to backport this function and if so, in what timescale.

Thanks

AMM

[ammaree]

Any chance of some feedback on this request.

We are trying to implement a clean/organised shutdown process but without htis function being available have no control over blocked tasks..

Thanks

[igrr]

Adding this function is currently planned together with migration to FreeRTOS 10, which might take a few months. We will update this ticket once more concrete plan is available.

[ammaree]

Very good news, other than the timeframe

[ammaree]

Hi @igrr

Any progress on porting xTaskAbortDelay()?

Thanks,
Andre

[chanibal]

Instead of waiting for xTaskAbortDelay, I'm using a combination of xTaskNotifyWait with a timeout for delay and xTaskNotify with a to abort the delay. It doesn't use any additional resources.

Using a flag with them allows you to know if the wait was aborted (or even allow for conditional cancelation).

[ammaree]

Hi @chanibal @igrr

The whole problem revolves around FOTA and esp_restart() not working consistently, a critical functionality to make FOTA work reliably. The FOTA happens 99% reliably, new firmware is downloaded and written, problem comes with the restart.

We have already been forced (against our will) to revert to UNICORE mode to improve restart reliability and currently have about ~75-80% successful restarts across 40 test devices running the exact same UNICORE firmware. Based on a recent scan of the issues here it seems we are not the only ones with the problem.

To further improve esp_restart() reliability it seems we have to do organised shutdown and cleanup of as many user tasks as possible (all?), prior to calling esp_restart(), and that is where we are working now.

The challenge lies in telnet, http and mqtt tasks where we do blocking calls in read(), select() and accept() and would like to abort these tasks and do proper cleanup in case of events such as restarts for firmware upgrades.

Rewriting the complete task flow to be non blocking to work around the absence of xTaskAbortDelay() is not a clean solution. Right now we are forced to change the calls to be non blocking with short timeouts (basically polling) then handle EAGAIN and EWOULDBLOCK, and restart the waiting process.

We also have to add a check for a status flag to determine if a signal has been given for the task to abort, and then start the cleanup process.

If I am missing some alternative to manage blocking socket calls, please let me know.

Andre

[chanibal]

@ammaree unfortunatelly, my hint is only applicable with simple delay calls, not moving the tasks back from the blocked state.

I have looked around the sources of the new FreeRTOS's tasks.c for a bit, and it looks like you could try to backport xTaskAbortDelay yourself. The TCB structures look like they're almost the same as in the IDF's version.

I have no idea if aborting a wait for a network call might have any additional side effects or will this be the same as a timeout.

[ammaree]

@igrr any progress on this item?

[ammaree]

@igrr @projectgus any update on this request?

Please ??

[projectgus]

Hi @ammaree ,

Sorry for the extended silence. We've decided to stop backporting FreeRTOS features to our ESP-IDF fork of FreeRTOS V9, and instead we're focusing on updating to add SMP support to FreeRTOS V10.

So far we don't have an ETA for this update, I'm sorry. We will update this GitHub issue as soon as that work is done, though.

[monkeytronics]

How close are you wonderful people to esp-IDF with amazon freertos. Is SMP working yet? Any hope of getting it into platformio? Keen to port existing projects using esp8266 across. I want to use Amazon's ota; jitp; and easy integration with awsiot. And bin all my messy Mqtt, password manager & not really secure enough garbage code.

[ammaree]

@igrr @projectgus
Gents, we are almost 2years 8 months after the original issue was logged. Since then the proposed solution was moved towards a FreeRTOS 10 based solution.

In various other posts we have been encouraged to test the feature branch but very quickly came up against some obstacles there, see #5763

Any chance we can have some clarity on
a) the exact status of support for FreeRTOS 10?
b) the target date for full transparent FR10 support in ESP-IDF?

Thanks

[projectgus]

Hi @ammaree,

Thanks for being patient with us as we worked through this. Maintaining an SMP-enabled FreeRTOS port is relatively complex, as I'm sure you can image, and we've been careful to try and avoid regressions when updating the FreeRTOS kernel.

FreeRTOS 10 is now in the ESP-IDF master branch and can be used now. It will be available in the ESP-IDF v4.3 stable release which is planned for late Q1 next year.

I'm afraid the configuration flag to enable xTaskAbortDelay() is still disabled in ESP-IDF, so this particular feature remains unsupported. It is a one line change to add a macro in FreeRTOSConfig.h to enable it, and in my basic tests this works fine.

However, testing it works correctly under all possible permutations of an SMP system is a relatively complex task that we haven't had time to do yet. There are also a lot of places inside ESP-IDF code that assume a delay won't be aborted - so we need to check all of these are handled cleanly. This includes the network calls that you've mentioned as your use case, LWIP isn't designed on the assumption that any blocking mutex/queue call can time out early so we need to check the implications of that carefully.

Therefore, I'm afraid we still don't have an ETA for full support of this feature.

[AxelLin]

Hi @projectgus

FreeRTOS 10 is now in the ESP-IDF master branch and can be used now.

Just FYI, there is a compile error in current master tree.

/home/axel/esp/esp-idf/components/freertos/tasks.c: In function 'vTaskGetInfo':
/home/axel/esp/esp-idf/components/freertos/tasks.c:4137:15: error: 'pxTaskStatus' is a pointer; did you mean to use '->'?
   pxTaskStatus.xCoreID = pxTCB->xCoreID;
               ^
               ->
ninja: build stopped: subcommand failed.
ninja failed with exit code 1

[projectgus]

Thanks @AxelLin, will fix.

Everyone, to report any other issues related to FreeRTOS 10 but not related to xTaskAbortDelay() please open a new issue with the details.

[ammaree]

Have not tested yet since we reworked all our tasks.
Assume fixed/working since no warning notes found in FreeRTOS 10 source