freeRTOS / Default Events/Tasks Clarification please....

[KeithInAsia]

I'm starting to string together a number of sample codebases which exercise the default event loop, GPIO ISR, and now Wifi... but I'm getting CPU crashes because I'm not aware of how the RTOS is being set up by default. Those activities are hidden behind the scenes?

Can someone give me a point in the right direction on the documentation that explains how and where the initial default tasks are being started -- and the where the scheduler is being started in a default sample project?

I found the boot loader docs on the espressif web site -- but I'm not seeing the docs that explain the lowest entry-level area where RTOS is kicking in.

Thanks in advance for any help you can offer...

[sojeha]

Hi there,

I may be wrong, but from my understanding, the task executions are all programmed in C, with freeRTOS as the foundation of the programming standard.

Take the hello_world example, your tasks are located in [main] folder, called hello_world_main.c and you may have complementary C file that link to the [..._main.c] file, for better readability. Inside your [..._main.c] file, you will find an app_main() function, which is where execution of your tasks takes place. You create tasks with xTaskCreate() function (this is freeRTOS function, so it follows freeRTOS' naming convention, 'x' prefix for variable of size_t, see: https://www.freertos.org/FreeRTOS-Codin ... onventions). Think of xTaskCreate() as void loop() in Arduino, they run infinite for loop with your tasks to be executed, and you may run more than one xTaskCreate() but be sure to specify the appropriate stack depth argument. You may need larger stack depth if your app is crashing.

The 'concept' section here may be a good place to grasp an overview of how ESP32 works: https://docs.espressif.com/projects/esp ... ystem.html

I'd very much welcome critique from others to correct my interpretation. Thanks.

[ESP_Dazz]

Can someone give me a point in the right direction on the documentation that explains how and where the initial default tasks are being started -- and the where the scheduler is being started in a default sample project?

An application's entry point is the app_main() function which is run from a main task that is created and self-deleted behind the scenes. Most of the startup process is in the cpu_start.c file which should create a bunch of tasks and start the scheduler. The starting function is call_start_cpu0()

Off the top of my head, the tasks that are implicitly created are

• Idle 0 and Idle 1

• IPC 0 and IPC 1

• Timer task

• Main task

[KeithInAsia]

At "app_main" one of the CPUs is running. Who started the task prior to this point? I assume this is CPU0 (PRO) side. When and where is the code that releases CPU1 from reset?

When did the scheduler start? Where is that call?

I have worked my way through a working example of the Event handler -- but don't see any RTOS directed calls in there. Did I miss something?


I think a lot of implicit things are happening below the covers -- and somehow we need to join up with it and begin starting task explicitly... but I don't see documents that give details on this transition from implicit to explicit function calls.

K.

[KeithInAsia]

I previously missed what you posted about the cpu_start.c file. I'm going to look through that....

[WiFive]

https://docs.espressif.com/projects/esp ... notes.html

[KeithInAsia]

I have read this area of the documentation - -but it lacks detail related to RTOS and task assignment etc....

As an example --- we know that CPU0 is running the task in Main.... that is the Protocol CPU... now, start up my event loop -- and GPIO event handling...

And then I go to startup the Wifi -- do I put that on the other processor with a task? Shouldn't the Wifi be on the "Protocol" CPU? Why name them Protocol/App if it isn't for a good reason... right?

When I try to run Wifi initialization in the current task -- my CPUs lock up and unit resets. It's a task/CPU problem.

K.

[ESP_igrr]

Shouldn't the Wifi be on the "Protocol" CPU? Why name them Protocol/App if it isn't for a good reason... right?

No, actually these names do not necessarily represent how these CPUs should be used. They are a leftover from the earlier design concept where two CPUs had more or less fixed purpose. In the final ESP32 chip, only a few functional differences between the PRO and APP CPUs remain.

With regards to Wi-Fi and other protocol stacks, there are a few Kconfig options which allow you to pin them to a specific CPU:

Wi-Fi: CONFIG_ESP32_WIFI_TASK_CORE_ID
Lwip: CONFIG_LWIP_TCPIP_TASK_AFFINITY
Bluetooth controller: CONFIG_BTDM_CTRL_PINNED_TO_CORE_CHOICE
Bluetooth host: CONFIG_BT_BLUEDROID_PINNED_TO_CORE_CHOICE

[KeithInAsia]

Then I think they should drop the APP and PRO designations because you expect names to mean something.

Another quick question -- why all the Kconfig options for assigning tasks to a CPU when your RTOS calls just assign those task directly?

Are you suggesting that in the circumstance that when you are on CPU0 and you envoke wireless services -- that the compiled code will reroute those to another task for CPU1 if the flags are set for it?

K.

[WiFive]

When you init WiFi and tcpip or bluetooth there are background tasks that will be created to do the low level work. High level things implemented by the user like reading data from sockets will be done in the user's task.