WIFI/BT(BLE) Simultaneously? (IDFGH-7146)

[bini2007]

I'm working on a project that uses both Wifi (specifically the http_client component) as well as BLE.

They both seem to work great separately.

However, once Wifi establishes a connection and starts working (a small http request every second or so), the BLE feels starved. It takes a very long time to get connected, reads take in the order of seconds, and I often get disconnected.

Any idea what could cause this behavior?

Either I must be doing something wrong, or there's an issue with the stack.
Is there an example that does WIFI and BLE at the same time? Is it expected to work fine?

I guess,

the problem is that they share a radio; in other words, while the ESP32 is sending/receiving a BT packet, it cannot listen or send a WiFi packet.

Thanks,

[xiongweichao]

Hi @bini2007

Please refer to this coexistence document. If this issue still exists, please provide the idf commit id and the demo (include sdkconfig) that reproduces the issue.

Thanks

[bini2007]

• IDF version (run git describe --tags to find it): v4.2.2-396-gccef7c1712

• sdkconfig: our custom sdkconfig.

• demo: our custom app using wifi (https or websocket) and ble based on bludroid stack.

• Problem:
  Our esp32 target met the following panic, right after connection via ble after scan VarramTag-1, (ble) device:

I (94194) GATTC_DEMO:
Name : VarramTag-1
Rssi : -45
Addr : e580b26365e
I (94194) GATTC_DEMO: ======================================================================

I (94204) GATTC_DEMO: Searched device VarramTag-1

I (94214) GATTC_DEMO: ======================================================================

I (94224) GATTC_DEMO: stop scan successfully
I (94224) GATTC_DEMO: Connect to the remote device.
Guru Meditation Error: Core 1 panic'ed (StoreProhibited). Exception was unhandled.

Core 1 register dump:
PC : 0x4009203d PS : 0x00060c33 A0 : 0x8009574e A1 : 0x3ffebb10
A2 : 0x0000ff08 A3 : 0x0000000f A4 : 0x3ffe336c A5 : 0x401081a4
A6 : 0x00000000 A7 : 0x3ffe2930 A8 : 0x0000abab A9 : 0x0000abab
A10 : 0x0000cdcd A11 : 0xb33fffff A12 : 0x00060c20 A13 : 0x00060c23
A14 : 0x00000001 A15 : 0x3ffec7b8 SAR : 0x00000019 EXCCAUSE: 0x0000001d
EXCVADDR: 0x0000ff08 LBEG : 0x4000c2e0 LEND : 0x4000c2f6 LCOUNT : 0xffffffff

Backtrace:0x4009203a:0x3ffebb10 0x4009574b:0x3ffebb30 0x40095e17:0x3ffebb50 0x400816e1:0x3ffebb70 0x40081715:0x3ffebb90 0x40098200:0x3ffebbb0 0x40098224:0x3ffebbd0 0x401081b3:0x3ffebbf0 0x40103a5b:0x3ffebc10 0x40103ae6:0x3ffebc40 0x40112caf:0x3ffebc60 0x40112cc2:0x3ffebc90 0x400fd0be:0x3ffebcb0 0x401128c8:0x3ffebcd0 0x400fda5d:0x3ffebcf0 0x40091ee5:0x3ffebd10

ELF file SHA256: 1a27e721f88ffcdecca430aa23212d44951cbbbb714faeba3f04daaa7ebabbaa

Rebooting...
ets Jul 29 2019 12:21:46

In addition, our custom sdkconfig is as following link:
https://gist.github.com/bini2007/4050bf86d17b5f2c563a3fcaa87a1eee

please check our sdkconfig and advice us how to fix the problem.

[xiongweichao]

Hi @bini2007

Please provide the .elf file for us to debug.

Thanks

[bini2007]

@xiongweichao

We added another elf file:

welle.zip

And we tried to debug using JTAG and we got the following captured screen:

As you know, the PC of the problem address is 0x4009230d.
However, we don't know how to fix it.
Please let us know how to solve this problem.

[ESP-Marius]

Sorry for the delayed follow-up on this one.

If we look at the backtrace we can see that the crash seems when we try to take a heap lock to do a malloc. The lock seems to point to random value 0x0000ff08, instead of a writeable memory area. So we get a store-prohibited.

Typically this is due to memory corruption, something overwrite this heap allocated lock. For some general suggestion on how to debug these errors you can see heap-corruption-detection.

Closing this issue for now as it is quite old, but feel free to reopen it again if you are still experiencing problems.