BLE arduino example Crash

[Atzingen]

Using the arduino BLE_write.ino example from the library, the program chashes

log error on the terminal:

-----------------------------------------------
E (1132) esp_pthread: pthread_getspecific: not supported!
E (1132) esp_pthread: pthread_setspecific: not supported!
abort() was called at PC 0x400ecc4f on core 0

Backtrace: 0x400894f8:0x3ffe2360 0x400895f7:0x3ffe2380 0x400ecc4f:0x3ffe23a0 0x400ecc96:0x3ffe23c0 0x400ed3ae:0x3ffe23e0 0x400ed437:0x3ffe2400 0x400dc2df:0x3ffe2420 0x400ddeb2:0x3ffe2440 0x400de03e:0x3ffe2460 0x400de389:0x3ffe24a0 0x400de3c9:0x3ffe24d0 0x400de3d9:0x3ffe24f0 0x400d8fd2:0x3ffe2510 0x400d5e1d:0x3ffe2530 0x400d505d:0x3ffe2570 0x400fa589:0x3ffe2590 0x400f6a32:0x3ffe25d0

Rebooting...
ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0010,len:4
load:0x3fff0014,len:812
load:0x40078000,len:0
load:0x40078000,len:10164
entry 0x400789f8

I'm getting the same problem on other BLE examples as well

[nkolban]

Howdy,
We are seeing a similar problem in #121. Can I ask you to read through that story. In their puzzle, that user is running a Sparkfun ESP32. Can I ask, what kind of module/board are you running?

A circumvention for problem #121 was to enable logging/debugging. That seems to alleviate the puzzle though we don't know why.

Another test just discovered/requested is to change the compilation style of the generated code from CONFIG_OPTIMIZATION_LEVEL_DEBUG to CONFIG_OPTIMIZATION_LEVEL_RELEASE. While we don't know if that will make a difference in this puzzle, it did make a difference in another.

We are struggling with this puzzle, #121 and #109 which feel related in that things don't work, they do when we switch on debugging and digging deeper seems to show that memory layout and memory references are making a different which is a much lower level puzzle than we are used to dealing with. There doesn't appear to be anything obvious in the BLE C++ classes code ... but rather the issues seem/feel to be related to the code that is generated by the compilers (guesses so far). If you could studt #121 and try the couple of tests recorded there and report back, it would really help us all.

[Atzingen]

Ok, so i got some results tha might help:

1-) I got the problem on windows 10 and ubuntu 16.04 (did a fresh virtualbox install just to test it) and got same problems on both of them. Tomorrow I'll get a mac from a friend to test.

2-) I tested on a chinese board that is a knock off the esp32 devkit from sparkfun(*). I have 3 off these boards and they all gave the same error. I have another one from china that presented the same problem (**)

• https://pt.aliexpress.com/item/MH-ET-LIVE-ESP32-Development-Board-WiFi-Bluetooth-Ultra-Low-Power-Consumption-Dual-Core-ESP-32/32813188966.html?spm=a2g0s.9042311.0.0.UrEJqS
  ** https://pt.aliexpress.com/item/ESP-32-ESP-32S-Development-Board-WiFi-Bluetooth-Ultra-Low-Power-Consumption-Dual-Cores-ESP32-Board/32801296418.html?spm=a2g0s.9042311.0.0.04859y

3-) The part tha breaks the code is in BLEServer *pServer = BLEDevice::createServer();
I did the newby "debug" with print statments and the code does not pass from there.

4-) I did the make erase_flash using the esp-idf but nothing changed.

5-) Not shure if it is relevant, but I have a working BLE code on arduino using just the stardard esp bluedroid stuff but your library is much cleanner that I would very much like to swich over.

I'm going to try the EspExceptionDecoder and set the CONFIG_LOG_DEFAULT_LEVEL to 5 now ...

[nkolban]

Thank you for doing the tests. There was thought in #109 that it might have been constrained to just the Sparkfun boards but that's not what you are running so that is indeed a new data point. I'm hunting down #109 because that is something I am able to recreate and I found that either:

1. Switching on debug solved the problem
2. Switching off the debug build solved the problem

In #109 we thought it was going to be a race condition but no ... it turns out to be a mystery memory access. I'm thinking that these two problems may not be so related after all. The unfortunate thing with your puzzle is that when we switch debugging on, the problem stops and the way to find a failure is by switching on trace/debugging to see where we are. My ideal would be to be able to recreate here.

[Atzingen]

I changed the CONFIG_LOG_DEFAULT_LEVEL to 5 and now the example code from the library (BLE_write) works ! I see alot of debug in the terminal but no reboot. Tested on windows 10, soon will try on linux and mac os to see the results.

[nkolban]

We made a big break through. Please read #121 which is the primary of this puzzle (it was first, other puzzles that are the same I consider duplicates).

[Atzingen]

Great ! I'm closing this one to folow along on #121