ESP32 Forum

I update my IDF by git pull on master branch. I find that some APIs has changed in esp_gattc_api.h.
I want to make BLE and WIFI coexistence and swap data, So the example 15 and example 03 are what I really want.

Then I modify the example 15 (gattc_demo), and add WIFI function into this demo.
However, esp32 throw an exception that:
***ERROR*** A stack overflow in task

The BLE or WIFI can work correctly if only one is enabled. But I wonder how to make BLE and WIFI coexistence ? And BLE and WIFI can work coexistence before I to the command: git pull.

I find that the sdkconfig on master branch disabled [Run FreeRTOS only on first core]. So I enable the [Run FreeRTOS only on first core] in menuconfig, the crash disappeared.

Anyone can explain this result? Thanks!

That bit of BLE is still somewhat in development for ESP-IDF 2.0; I think we internally ran into the same issue and we have an engineer debugging it.

Sounds like a resource contention problem. When you're running dual cores, you can have two active threads of execution- under the "right" conditions, you can have something yank the carpet out from underneath you when running FreeRTOS since there's little in the way of protections against both cores clobbering each other.

Not sure if SMP is a good thing unless you've got good locking in the OS for things. Now, if you pinned threads to a given core, gave the differing dependent threads mailbox slotting for communications...might work out nicely.

madscientist_42 wrote:Sounds like a resource contention problem. When you're running dual cores, you can have two active threads of execution- under the "right" conditions, you can have something yank the carpet out from underneath you when running FreeRTOS since there's little in the way of protections against both cores clobbering each other.

FYI: FreeRTOS is pre-emptive multitasking; so while you may see the problem earlier on multicore, it's just as easy to run into the same thing in single-core. Thread a reads a variable, freertos switches to thread b, thread b reads, modifies, writes the variable, freertos switches back to thread a, thread a modifies and writes the variable read earlier, and happily undoes thread b's work on the variable. No two cores needed. Unfortunately (or fortunately, depending on how you look at it), doing concurrency right is about as hard on singlecore as it is on SMP.

ESP_Sprite wrote:

madscientist_42 wrote:Sounds like a resource contention problem. When you're running dual cores, you can have two active threads of execution- under the "right" conditions, you can have something yank the carpet out from underneath you when running FreeRTOS since there's little in the way of protections against both cores clobbering each other.

FYI: FreeRTOS is pre-emptive multitasking; so while you may see the problem earlier on multicore, it's just as easy to run into the same thing in single-core. Thread a reads a variable, freertos switches to thread b, thread b reads, modifies, writes the variable, freertos switches back to thread a, thread a modifies and writes the variable read earlier, and happily undoes thread b's work on the variable. No two cores needed. Unfortunately (or fortunately, depending on how you look at it), doing concurrency right is about as hard on singlecore as it is on SMP.

Very much so. It's the cause of many "ghost in the machine" conditions in embedded code when you're doing multi-threaded stuff.