Bootloop with Wifi + BLE

Hi, not sure if this issue is allready contained in #82 or others.
The simplified test code (below) results in a bootloop if line
BLEDevice::init("");
is active:

#include <WiFi.h>
#include "BLEDevice.h"

#include "c:/credentials.h"
//const char* ssid     = "yourssid";
//const char* password = "yourpasswd";

void setup()
{
  Serial.begin(115200);
  delay(10);

  // We start by connecting to a WiFi network

  Serial.println();
  Serial.println();
  Serial.print("Connecting to ");
  Serial.println(ssid);

  WiFi.begin(ssid, password);

  while (WiFi.status() != WL_CONNECTED) {
    delay(500);
    Serial.print(".");
  }

  Serial.println("");
  Serial.println("WiFi connected");
  Serial.println("IP address: ");
  Serial.println(WiFi.localIP());

  BLEDevice::init(""); //<-effecting line
}

void loop(){}

Debug Output:
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:716
load:0x40078000,len:0
load:0x40078000,len:11572
entry 0x40078a14
assertion "res == pdTRUE" failed: file "/Users/ficeto/Espressif/ESP32/esp-idf/components/esp32/./cpu_start.c", line 337, function: start_cpu0_default
abort() was called at PC 0x4015eb1f on core 0

Backtrace: 0x400898e4:0x3ffe3b90 0x400899e3:0x3ffe3bb0 0x4015eb1f:0x3ffe3bd0 0x40083a79:0x3ffe3c00 0x40083c1c:0x3ffe3c30 0x4007886a:0x3ffe3c50 0x400788d1:0x3ffe3c80 0x40078a0e:0x3ffe3cb0 0x40078b33:0x3ffe3e70 0x40007c31:0x3ffe3eb0 0x4000073d:0x3ffe3f20

Rebooting...

Decoding 15 results
0x4015eb1f: __assert_func at /Users/ivan/e/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdlib/../../../.././newlib/libc/stdlib/assert.c line 63 (discriminator 8)
0x400898e4: invoke_abort at /Users/ficeto/Espressif/ESP32/esp-idf/components/esp32/./panic.c line 553
0x400899e3: abort at /Users/ficeto/Espressif/ESP32/esp-idf/components/esp32/./panic.c line 553
0x4015eb1f: __assert_func at /Users/ivan/e/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdlib/../../../.././newlib/libc/stdlib/assert.c line 63 (discriminator 8)
0x40083a79: start_cpu0_default at /Users/ficeto/Espressif/ESP32/esp-idf/components/esp32/./cpu_start.c line 337 (discriminator 1)
0x40083c1c: call_start_cpu0 at /Users/ficeto/Espressif/ESP32/esp-idf/components/esp32/./cpu_start.c line 207

[nkolban]

That's a great post/report. Lots of great details and well described. Unfortunately I'm still considering we are in Arduino limbo for just now. The latest Arduino-ESP32 libraries use the 1.22.0-73-ge28a011 compiler which has a known breakage for C++ classes that use standard library. See:

espressif/esp-idf#1032

Until that is formally resolved by what ever change is necessary and the Arduino-ESP32 libraries are modified/re-released to pick up the change, there isn't a current environment available to us to sensibly perform Arduino work and testing.

Flagging as blocked until we get the above issue resolved.

[vijfhoek]

Is there any known workaround for this issue? Sadly I depend on another bugfix in the Arduino repository fixing some HTTPS issues, which means I can't easily use an older version.

[nkolban]

Progress is being made. We have a "chain" of fixes needed ... the ESP-IDF is the foundation and the latest Git master seems to contain what we need. The next level up is for the Arduino-ESP32 package to refresh itself with the latest ESP-IDF from Git master and a request has been opened for this just a day ago ... see:

espressif/arduino-esp32#709

When that request/issue gets satisfied ... the final part will be testing the BLE libraries on Arduino and pushing a new Arduino BLE C++ library which should only take about a day.

[nkolban]

The great news is that the Arduino ESP32 project has been updated. Please re-build your base Arduino ESP32 environment. The even better news is that the owner of that project has decided to include the BLE C++ classes as part of the distribution. So it is now baked in. Please re-test and let us now see where we stand.

[vijfhoek]

Great! I'll test it later today

[vijfhoek]

Sadly, the changes don't seem to have fixed the issue. I'm still getting the same problem as @pit001 had

[nkolban]

I have managed to recreate the issue on my machine using the latest Arduino-ESP32 environment. This is great ... because a problem re-created is a problem half solved. Running the decoder against the stack trace, I find:

0x40089ae4: invoke_abort at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/esp32/./panic.c line 553
0x40089be3: abort at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/esp32/./panic.c line 553
0x40083b43: start_cpu0_default at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/esp32/./cpu_start.c line 350
0x40083ce0: call_start_cpu0 at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/esp32/./cpu_start.c line 207

Unfortunately, this appears to happen at the start of the program before any other activity is performed which had me stymied. So I walked through the source code of the ESP-IDF found here:

https://github.com/espressif/esp-idf/blob/master/components/esp32/cpu_start.c

Working backwares ... Line 207 calls start_cpu0(). Which takes us to the code start_cpu0_default (its an alias) starting at line 254. We find the exception occurring at line 350 which has an extremely useful comment which says /* Only get to here if not enough free heap to start scheduler */. Aha ... as scooby says "A clue ... a clue!!!".

However we have a new problem ... the stack size is governed by the configuration variable called CONFIG_MAIN_TASK_STACK_SIZE which is used when the cpu_start.c is compiled. But cpu_start.c is supplied pre-compiled for us by the Arduino-ESP32 environment which means that we (as users) of the Arduino-ESP32 can't tweak anything to change the size. I'm going to raise an issue against Arduino-ESP32 to see if we can't get it raised.