Simple application crashing with FreeRTOS tasks

[realll]

I'm in the process on learning how to use FreeRTOS so I'm starting out by doing simple programs to test functionality. This program creates two tasks and both tasks are printing some characters to a shared buffer. Naturally, to make it work without concurrency problems I'm using a mutex. The app compiles fine but when I flash it to the ESP32 it gives me

Guru Meditation Error: Core 0 panic'ed (InstrFetchProhibited). Exception was unhandled

I don't understand what I'm doing wrong because when I copy this code and compile/flash it from Arduino IDE (making the proper adjustments to the usual Arduino format) it runs fine without crashing.
I'm using PlatformIO in Visual Studio Code and the IDF version is 4.0. The code is the following:

Code: [Select all] [Expand/Collapse]

1. #include <stdio.h>
2. #include "freertos/FreeRTOS.h"
3. #include "freertos/task.h"
4. #include "freertos/semphr.h"
5. #include "esp_system.h"
6. #include "sdkconfig.h"
7.  
8. SemaphoreHandle_t mux;
9. char sharedBuf[20];
10.  
11. void task1(void *pv)
12. {
13.     char task1Msg[] = "01234";
14.       for(;;) {
15.         if(xSemaphoreTake(mux, portMAX_DELAY) == pdTRUE) {
16.           for (int i = 0; i < 5; i++) {
17.             sharedBuf[i] = task1Msg[i];
18.             vTaskDelay(100 / portTICK_PERIOD_MS);
19.           }
20.           printf("Task1 msg: %s\n", sharedBuf);
21.           xSemaphoreGive(mux);
22.         }
23.         vTaskDelay(100);
24.       }
25.     vTaskDelete( NULL );
26. }
27.  
28. void task2(void *pv)
29. {
30.     char task2Msg[] = "56789";
31.       for(;;) {
32.         if(xSemaphoreTake(mux, portMAX_DELAY) == pdTRUE) {
33.           for (int i = 0; i < 5; i++) {
34.             sharedBuf[i] = task2Msg[i];
35.             vTaskDelay(100);
36.           }
37.           printf("Task2 msg: %s\n", sharedBuf);
38.           xSemaphoreGive(mux);
39.         }
40.         vTaskDelay(100);
41.       }
42.     vTaskDelete( NULL );
43. }
44.  
45. void app_main()
46. {
47.     xTaskCreate(task1, "Task1", 4000, NULL, tskIDLE_PRIORITY, NULL);
48.     xTaskCreate(task2, "Task2", 4000, NULL, tskIDLE_PRIORITY, NULL);
49.  
50.     mux = xSemaphoreCreateMutex();
51.    
52.     vTaskStartScheduler();
53.  
54.     while (1) {
55.  
56.     }
57. }

GeSHi © Codebox Plus Extension

[ESP_igrr]

Can you please try removing the call to vTaskStartScheduler (app_main is running from a task when the scheduler is already running, so this call is not needed), and increasing the task priorities to idle + 1?

[realll]

I've done both of those and unfortunately the problem still persists. However, now the error message is different, as follows:

Code: [Select all] [Expand/Collapse]

1. C:\Users\Real\.platformio\packages\framework-espidf\components\freertos\queue.c:1448 (xQueueGenericReceive)- assert failed!
2. abort() was called at PC 0x40085805 on core 1

GeSHi © Codebox Plus Extension

I've also tested the same code in another computer with Platformio and made sure it was updated AND tested a second ESP32. Same results for all cases.

[ESP_Dazz]

A few points to consider

• Check that you have created the mux before it is being used (i.e. xSemaphoreCreateMutex() occurs before any call to xSemaphoreTake()). That assert you're seeing is likely due to the mux handle being NULL.

What's likely happening here is that you are calling xTaskCreate() instead of xTaskCreatePinnedToCore() meaning the created tasks can run on either core. Once you create task1 and task2, one of them is able run immediately even though they have a lower priority because it is running on the opposite core (thus the log indicating abort() being called on core1). Because task1 or task2 is able to run immediately after creation, xSemaphoreTake() is called before app_main() is able to call xSemaphoreCreateMutex() .

• Call xSemaphoreCreateMutex() first before creating the tasks that use the mutex.

• Avoid using tskIDLE_PRIORITY as that is the lowest possible priority and is generally reserved for the IDLE tasks. app_main() runs in the "main" task on core 0 and has a priority of 1. In most circumstances, you should create tasks of priority 1 or higher.

• In the future, please provide the entire error log (e.g., register dump, back trace, and any printf() or ESP_LOG() local to the concurrence of the error. It's quite difficult to determine the cause of the issue win single line of error log.

[realll]

Since I'm still learning RTOS I don't quite the mindset of parallelism just yet. Those things fixed the issue and actually make sense, thanks a lot for your time and for your excellent explanation and sorry for not posting the entire log, first time posting here. Thread can be closed now.