BLE and WIFI can't coexist when ESP32 as BLE master?

xzwang
Posts: 22
Joined: Wed Dec 14, 2016 4:54 am

BLE and WIFI can't coexist when ESP32 as BLE master?

Postby xzwang » Tue Jan 10, 2017 6:14 am

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.

xzwang
Posts: 22
Joined: Wed Dec 14, 2016 4:54 am

Re: BLE and WIFI can't coexist when ESP32 as BLE master?

Postby xzwang » Tue Jan 10, 2017 6:43 am

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!

ESP_Sprite
Posts: 9833
Joined: Thu Nov 26, 2015 4:08 am

Re: BLE and WIFI can't coexist when ESP32 as BLE master?

Postby ESP_Sprite » Wed Jan 11, 2017 1:35 am

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.

madscientist_42
Posts: 95
Joined: Tue Feb 21, 2017 10:17 pm

Re: BLE and WIFI can't coexist when ESP32 as BLE master?

Postby madscientist_42 » Thu Feb 23, 2017 3:47 pm

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.

ESP_Sprite
Posts: 9833
Joined: Thu Nov 26, 2015 4:08 am

Re: BLE and WIFI can't coexist when ESP32 as BLE master?

Postby ESP_Sprite » Sun Feb 26, 2017 6:38 am

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.

madscientist_42
Posts: 95
Joined: Tue Feb 21, 2017 10:17 pm

Re: BLE and WIFI can't coexist when ESP32 as BLE master?

Postby madscientist_42 » Mon Feb 27, 2017 2:44 pm

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.

Who is online

Users browsing this forum: No registered users and 96 guests