I am currently working on a project that use both LoraWan and BLE on an esp32.
I am programming it in Arduino.
As my project is battery powered I want to spare as much energy as possible, such I would like to use light sleep. The device would sleep for 7 to 10 sec and then wake up for the same amount of time.
I am directly powering the esp32 (TTGO-LORA32-V1) through 3.3V pin with a 1S battery. Between the battery and the board I have a 3.3V power regulator (TL1963A).
I came across the following issue : at a moment or another, in a random way, my board is not waking up anymore or it crashes at wake up. Indeed, it stopped sending Lora packets and it stop advertising on BLE.
I noticed that when I just have Lora, without BLE, I don’t have this waking up issue (at least not on the past 72 hours) I am afraid it is caused by repeatedly creating a BLE server. I probably have memory issues or at some point I am creating the server before deleting completely the last one.
Do you have any ideas of why I have this issue with BLE and light sleep cohabitation, and how I could solve it ?
Attached, the code dealing with light sleep and BLE stop and go :
void loop ()
{
if(RESTART)
{
delay(5);
//setup BLE contains the init function of the arduino library for BLE
BLESyst.setupBLE(serial_ID_ble,"1234abcd");
RESTART=false;
timeLightSleepInit=millis();
Serial.println("Setting counter timer to 0");
counterTimer = 0 ;
}
//Some other stuffs in main loop from which counterTimer incrementation
/* Light sleep management */
if ((!DEVICE_IS_CONNECTED)&&(counterTimer>=70)&&(lightsleep)) //
{
counterTimer=0;
RESTART=true;
if(USE_LIGHT_SLEEP)
{
if(VERBOSE && VERBOSE_MAIN)
{
Serial.println("I am going to light sleep");
delay(250);
}
// Set motor driver to sleep
System.driverSleep(DRIVER_SLEEP);
BLEDevice::deinit();
delay(200);
// Enter sleep mode
esp_light_sleep_start();
}
}
I also tried to just stop advertising during light sleep and start advertising again at wake up with : esp_ble_gap_stop_advertising() and BLEDevice::startAdvertising().
And also esp_bt_controller_disable(); and esp_bt_controller_enable(ESP_BT_MODE_BLE);
In both case I wasn’t able to connect to BLE after wake up.
Digging up I found that I have regular Core Dump because of Advertising function of BLE. It explains why it wasn’t posting anymore with Lora. The frequency of this error causing the device not to be able to do a proper handshake.
Following, the Core dump
Guru Meditation Error: Core 1 panic'ed (StoreProhibited). Exception was unhandled.
17:21:58.200 > Core 1 register dump:
17:21:58.202 > PC : 0x4000c2e4 PS : 0x00060330 A0 : 0x80111ad1 A1 : 0x3ffc9fd0
17:21:58.210 > A2 : 0x00000000 A3 : 0x3ffffac0 A4 : 0x000001e0 A5 : 0x00000000
17:21:58.217 > A6 : 0x89abcdef A7 : 0x01234567 A8 : 0x00000000 A9 : 0x3ffc9f70
17:21:58.225 > A10 : 0x00000000 A11 : 0x00001800 A12 : 0x00000000 A13 : 0x00000003
17:21:58.233 > A14 : 0x00060320 A15 : 0x00000000 SAR : 0x00000018 EXCCAUSE: 0x0000001d
17:21:58.241 > EXCVADDR: 0x00000000 LBEG : 0x4000c2e0 LEND : 0x4000c2f6 LCOUNT : 0x0000001d
17:21:58.248 >
17:21:58.249 > Backtrace: 0x4000c2e4:0x3ffc9fd0 0x40111ace:0x3ffc9fe0 0x4010bdce:0x3ffca000 0x401092b9:0x3ffca030 0x400d6047:0x3ffca090 0x400d789a:0x3ffca0d0 0x400d2334:0x3ffca0f0 0x400d5091:0x3ffca130 0x400dcf8d:0x3ffca1c0 0x4008e94d:0x3ffca1e0
17:21:58.378 > #0 0x4000c2e4:0x3ffc9fd0 in ?? ??:0
17:21:58.378 > #1 0x40111ace:0x3ffc9fe0 in btc_gap_ble_arg_deep_copy at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/bt/bluedroid/btc/profile/std/gap/btc_gap_ble.c:1032
17:21:58.378 > #2 0x4010bdce:0x3ffca000 in btc_transfer_context at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/bt/bluedroid/btc/core/btc_task.c:155
17:21:58.378 > #3 0x401092b9:0x3ffca030 in esp_ble_gap_config_adv_data at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/bt/bluedroid/api/esp_gap_ble_api.c:517
17:21:58.378 > #4 0x400d6047:0x3ffca090 in BLEAdvertising::start() at /home/sarah/.platformio/packages/framework-arduinoespressif32/libraries/BLE/src/BLEAdvertising.cpp:485
17:21:58.378 > #5 0x400d789a:0x3ffca0d0 in BLEDevice::startAdvertising() at /home/sarah/.platformio/packages/framework-arduinoespressif32/libraries/BLE/src/BLEDevice.cpp:570
17:21:58.378 > #6 0x400d2334:0x3ffca0f0 in BLEFunctions::setupBLE(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) at src/BLEFunctions.cpp:304
17:21:58.378 > #7 0x400d5091:0x3ffca130 in loop() at src/main.cpp:157 (discriminator 2)
17:21:58.378 > #8 0x400dcf8d:0x3ffca1c0 in loopTask(void*) at /home/sarah/.platformio/packages/framework-arduinoespressif32/cores/esp32/main.cpp:19
17:21:58.378 > #9 0x4008e94d:0x3ffca1e0 in vPortTaskWrapper at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/port.c:355 (discriminator 1)```
I will focus on it and try to find a way to avoid it.
does the problem still occur when powering the board from e.g., USB or a lab-bench power supply set to 3.3V?
does the problem still appear with large decoupling capacitors on the 3.3V rail?
depending on the charge of the battery and its chemistry (LiPo/Li-Ion?), the TL1963A might not be getting its needed droputout voltage (difference between input voltage and 3.3V target) to supply the peak currents needed when the BLE radio wakes up, or when LoRa packets are being sent (refer datasheet)
brownouts / voltage changes can also be tracked down with an oscilliscope on the 3.3V rail
Comment Crash when waking up from light sleep - ESP32 Forum suggests the flash might not be able to wake up quicky enough and modification of CONFIG_ESP32_DEEP_SLEEP_WAKEUP_DELAY should be checked. If using normal Arduino-ESP32, this value is however hardcoded in the precompiled ESP-IDF base; to change it, you would have to switch your project’s compilation options to ESP-IDF + Arduino as a component to be able to modify the that sdkconfig option (see example and documentation)
Otherwise the people at Arduino-ESP32 (Issues · espressif/arduino-esp32 · GitHub) might be able to help you better as the people who build the core (which also are the ESP-IDF and Espressif people) are there – we’re just the guys who make the build system on top of it.
Thanks a lot for this quick and detailed answer. I will try/test everything you said and come back with the results. I will also post en issue on espressif, arduino esp32 github about it.