ESP32 Forum

Is app_main guaranteed to always be run on pro cpu?

The docs seem to suggest this (https://docs.espressif.com/projects/esp ... notes.html) but doesn't explicitly state this.

I was going to look at the functions start_cpu0 and start_cpu1, but they are not actually in components/esp32/cpu_start.c (as stated by the docs). That file actually doesn't exist either (at least at that location). In fact there are two cpu_start.c files, neither in components/esp32/. The first in components/esp_system/port/ which contains call_start_cpu0 and call_start_cpu1 but not start_cpu0 or start_cpu1. The second is found in examples/build_system/cmake/idf_as_lib/stubs/esp32/ and is equally unhelpful.

The reason this is important is that (according to my understanding) gpio_install_isr_service() (and similar functions) 'pin' the interrupt handling to the core that is used for initialization. So I then would need to be certain which core app_main is pinned to when I called these functions.

This leads to the second tangentially related problem. If app_main returns, the main task is deleted, and everything works as expected. But the documentation for xTaskCreatePinnedToCore() states: "Tasks must be implemented to never return (i.e. continuous loop).". So how is it the main task will happily delete itself upon return, but user spawned tasks cannot? And if user spawned tasks cannot return, what is the point of vTaskDelete()?

Hi kaisha,

Kaisha wrote: I was going to look at the functions start_cpu0 and start_cpu1, but they are not actually in components/esp32/cpu_start.c (as stated by the docs). That file actually doesn't exist either (at

Thanks for the note, will fix the docs!

app_main function is called from a task pinned to CPU 0. The relevant code is here:
https://github.com/espressif/esp-idf/bl ... .c#L82-L84
It is unlikely this would ever changes, for compatibility reasons. At most, we could at some point add a Kconfig option to choose the core where app_main will run.

Kaisha wrote: This leads to the second tangentially related problem. If app_main returns, the main task is deleted, and everything works as expected. But the documentation for xTaskCreatePinnedToCore() states: "Tasks must be implemented to never return (i.e. continuous loop).". So how is it the main task will happily delete itself upon return, but user spawned tasks cannot? And if user spawned tasks cannot return, what is the point of vTaskDelete()?

app_main by itself is not a task function passed to xTaskCreate. Instead, there is a wrapper function "main_task" (see the same source file) which does some initialization and eventually calls app_main. When (if) app_main returns, main_task calls vTaskDelete(NULL), terminating itself.

Same can be done in user tasks — just call vTaskDelete instead of returning from the task function. Will fix up the docs here as well — they come from the upstream FreeRTOS project and looks like we have inherited this wording.

Thank-you for the link That clears everything up.

Perhaps in a future release having a task delete itself upon function return would make sense. It doesn't break any existing functionality, and would make things more intuitive IMO. But either way its a minor issue, and I can just use vTaskDelete(NULL) easily enough.

Kaisha wrote: Perhaps in a future release having a task delete itself upon function return would make sense. It doesn't break any existing functionality, and would make things more intuitive IMO. But either way its a minor issue, and I can just use vTaskDelete(NULL) easily enough.

We had considered that, but decided that this might result in library authors relying on this IDF-specific behavior; then these libraries will not work in other environments, such as Amazon FreeRTOS. Instead, we have added an option (enabled by default) to abort with a clear error message on task function exit, making such issues easier to understand: https://github.com/espressif/esp-idf/bl ... #L164-L174.