(Waiting for Toolchain fix): BLE stack don't compile after the last me-no.dev commit #81

jestebanes · 2017-09-23T11:41:09Z

Hello Neil, after the last commit of arduino-esp32 there are some troubles with your library

Best wishes and thanks for your great work

Editor: Moved to Pastebin: https://pastebin.com/GT41096V

nkolban · 2017-09-23T15:57:49Z

Ouch!!! This is not good. Tracking as #82 for the implications across both Arduino and ESP-IDF.

jestebanes · 2017-09-26T22:09:23Z

Hello again!

I'm not sure about what is happening in my software, I think I'm mixing apples with oranges and this doesn't work

After the #82, I try to compile with arduino-esp32 without BLE support to check other parts of my system and it works fine
When I back to use BLE I found a strange error
Any ideas?

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

rst:0xc (SW_CPU_RESET),boot:0x1b (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 0x4016dc97 on core 0

Decoding 11 results
0x40089dcc: invoke_abort at /Users/ficeto/Espressif/ESP32/esp-idf/components/esp32/./panic.c line 553
0x40089ecb: abort at /Users/ficeto/Espressif/ESP32/esp-idf/components/esp32/./panic.c line 553
0x4016dc97: __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)
0x40083e41: start_cpu0_default at /Users/ficeto/Espressif/ESP32/esp-idf/components/esp32/./cpu_start.c line 337 (discriminator 1)
0x40083fe4: call_start_cpu0 at /Users/ficeto/Espressif/ESP32/esp-idf/components/esp32/./cpu_start.c line 2070x40078b33:0x3ffe3e70 0x40007c31:0x3ffe3eb0 0x4000073d:0x3ffe3f20

nkolban · 2017-09-26T22:25:18Z

Howdy, unfortunately we are just plain "broke" on Arduino at the moment. The story in detail can be found in #82 but in summary ...

ESP-IDF Git master changed BLE Client APIs
ESP-IDF Git master changed toolchain (compilers, linkers etc)
BLE C++ libraries against ESP-IDF stopped working
Arduino-ESP32 re-based itself against ESP-IDF Git master
BLE C++ libraries against Arduin-ESP32 stopped working
BLE C++ libraries re-worked to accommodate ESP-IDF BLE Client API changes
Toolchain stopped working when building C++ code that includes some standard libraries (see Can registerForNotify() fail? #1032)
ESP-IDF works with BLE C++ when we drop back to older tool chain
Arduino-ESP32 still does not work with BLE C++ as we have no obvious recipe short of surgery to tell Arduino-ESP32 to use an alternative tool chain.

jestebanes · 2017-09-26T22:42:13Z

Ok, Neil thanks for the support

nkolban · 2017-10-14T03:25:32Z

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.

jestebanes · 2017-10-15T16:07:09Z

Hello Neil, I try with my software and doesn't work again, the error is similar to the previous failure

 rst:0xc (SW_CPU_RESET),boot:0x1b (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:956
load:0x40078000,len:0
load:0x40078000,len:11856
entry 0x40078a34
assertion "res == pdTRUE" failed: file "/Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/esp32/./dport_access.c", line 187, function: esp_dport_access_int_init
abort() was called at PC 0x4014ea37 on core 0

Decoding 12 results
0x40089f20: invoke_abort at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/esp32/./panic.c line 553
0x4008a01f: abort at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/esp32/./panic.c line 553
0x4014ea37: __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)
0x40164d8a: esp_dport_access_int_init at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/esp32/./dport_access.c line 187 (discriminator 1)
0x40083ed4: start_cpu0_default at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/esp32/./cpu_start.c line 334
0x400840ac: call_start_cpu0 at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/esp32/./cpu_start.c line 207

nkolban · 2017-10-15T16:14:46Z

The symptom you are seeing seems close to #110 ... in your script/sketch ... do you have WiFi enabled as well? Do the samples that come with the BLE C++ classes work?

jestebanes · 2017-10-15T16:46:43Z

Next, I try your examples
BLE_uart works fine sending and receiving!
BLE_client needs a "return true" in line 65
BLE_server works fine
BLE_notify works fine
BLE_scan scan
BLE_write works fine, writing and receiving in serial 0 port

That wasn't a deep test but they compile and using rRF connect software I can see the esp32 device and interact with it.

jestebanes · 2017-10-15T16:59:32Z

Hello Neil, yes my software uses wifi and BLE simultaneously, I'm going to disconect wifi while BLE is working

Thanks for the help

jestebanes · 2017-10-15T17:31:43Z

Ok wifi disconnected, but another issue raises. I think your last comment in #110 is the key, and stack size is creating troubles when the code is a bit more complicated than a simple test.

rst:0xc (SW_CPU_RESET),boot:0x1b (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:956
load:0x40078000,len:0
load:0x40078000,len:11856
entry 0x40078a34
E (30481) esp_pthread: pthread_getspecific: not supported!
E (30482) esp_pthread: pthread_setspecific: not supported!
abort() was called at PC 0x400f5963 on core 0

Decoding 17 results
0x4008953c: invoke_abort at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/esp32/./panic.c line 553
0x4008963b: abort at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/esp32/./panic.c line 553
0x400f5963: __cxxabiv1::__terminate(void (*)()) at /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc line 112
0x400f59aa: std::terminate() at /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc line 112
0x400f60d6: __cxa_get_globals at /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/eh_globals.cc line 133
0x400f6163: __cxa_throw at /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/eh_throw.cc line 65
0x400e4fcb: std::__throw_length_error(char const*) at /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/src/c++11/functexcept.cc line 122
0x400e6b9e: std::__cxx11::basic_string  , std::allocator  >::_M_create(unsigned int&, unsigned int) at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/build/build-cc-gcc-final/xtensa-esp32-elf/libstdc++-v3/include/bits/basic_string.h line 2200
0x400e6d2a: std::__cxx11::basic_string  , std::allocator  >::_M_mutate(unsigned int, unsigned int, char const*, unsigned int) at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/build/build-cc-gcc-final/xtensa-esp32-elf/libstdc++-v3/include/bits/basic_string.h line 2200
0x400e708d: std::__cxx11::basic_string  , std::allocator  >::_M_replace(unsigned int, unsigned int, char const*, unsigned int) at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/build/build-cc-gcc-final/xtensa-esp32-elf/libstdc++-v3/include/bits/basic_string.h line 2200
0x400e70cd: std::__cxx11::basic_string  , std::allocator  >::assign(char const*) at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/build/build-cc-gcc-final/xtensa-esp32-elf/libstdc++-v3/include/bits/basic_string.h line 2200
0x400e70dd: std::__cxx11::basic_string  , std::allocator  >::operator=(char const*) at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/build/build-cc-gcc-final/xtensa-esp32-elf/libstdc++-v3/include/bits/basic_string.h line 2200
0x400e0a92: FreeRTOS::Semaphore::give() at C:\Users\javier\Documents\Arduino\hardware\espressif\esp32\libraries\BLE\src/FreeRTOS.cpp line 126
0x400dda31: BLEServer::handleGATTServerEvent(esp_gatts_cb_event_t, unsigned char, esp_ble_gatts_cb_param_t*) at C:\Users\javier\Documents\Arduino\hardware\espressif\esp32\libraries\BLE\src/BLEServer.cpp line 60
0x400dcca5: BLEDevice::gattServerEventHandler(esp_gatts_cb_event_t, unsigned char, esp_ble_gatts_cb_param_t*) at C:\Users\javier\Documents\Arduino\hardware\espressif\esp32\libraries\BLE\src/BLEDevice.cpp line 47
0x4010339d: btc_gatts_cb_to_app at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/bt/bluedroid/btc/profile/std/gatt/btc_gatts.c line 54
:  (inlined by) btc_gatts_cb_handler at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/bt/bluedroid/btc/profile/std/gatt/btc_gatts.c line 731
0x400ff83a: btc_task at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/bt/bluedroid/btc/core/btc_task.c line 85

nkolban · 2017-10-15T19:01:21Z

Aha ... that's actually good news. But let's be sure that we now realize that we have two stories here. One is the problem running BLE and WiFi together which appears to be stack size that is hard-coded in Arduino BLE.

The second issue, the one that I am going to address here, is the last problem you posted. The good news is that we've been working this one as #121 and just this morning made a major breakthrough ... to the point where good users like yourself can use it.

What I'd like to suggest is that we don't talk about this current problem in this issue any more but instead let me encourage you to piggyback on #121 which was the first to report that issue. Looking forward to hearing what you think after reading #121.

jestebanes · 2017-10-16T19:21:27Z

Hello Neil, after following your comments in #121 I've got my BLE working fine 👍
Few moments ago @me-no-dev has made a commit to increase the stack size
#define CONFIG_MAIN_TASK_STACK_SIZE 8192
Apparently, this wasn't the final solution when I'm using BLE and WIFI...

Best regards

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

rst:0xc (SW_CPU_RESET),boot:0x1b (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:956
load:0x40078000,len:0
load:0x40078000,len:11856
entry 0x40078a34
assertion "res == pdTRUE" failed: file "/Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/esp32/./ipc.c", line 85, function: esp_ipc_init
abort() was called at PC 0x401502b3 on core 0

Decoding 12 results
0x4008a3a8: invoke_abort at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/esp32/./panic.c line 553
0x4008a4a7: abort at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/esp32/./panic.c line 553
0x401502b3: __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)
0x40166989: esp_ipc_init at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/esp32/./ipc.c line 85 (discriminator 1)
0x400841de: start_cpu0_default at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/esp32/./cpu_start.c line 332
0x400843bc: call_start_cpu0 at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/esp32/./cpu_start.c line 207

nkolban · 2017-10-16T19:41:27Z

I'm at work just now ... but first opportunity I get I'll be re-testing here with the increased stack size. What I have been trying to avoid doing is learning how to build the Arduino-ESP32 libraries from source. Ideally, I just wanted to be a "user" of those libraries and the BLE code becomes just a layer on top of them. However I'm re-thinking that notion. Last I looked, I had convinced myself that the error we had was as described in #110 which is the primary tracker for WiFi/BLE memory issues. What I believe is that the amount of stack space associated with the main task is hard-coded by the Arduino-ESP32 libraries before distribution of the Arduino-ESP32 environment. I can't remember off the top of my head what the previous value was but even 8192 may be too low.

Since I am ignorant on how to build the Arduino-ESP32 libraries for testing, I hadn't attempt to try any tests to see what values would work. What I believe I must do now is take the hit and learn (and document) how to build the Arduino-ESP32 libraries here/locally ... so that I can make changes to the build myself so that I can then be specific about what values may be needed. This may take some time.

jestebanes · 2017-10-16T21:37:56Z

Hello Neil, the previous size was 4096
Why don't just report that 8192 isn't enough and try with the next magic number 12k
In my experience stack isn't an exact science, it depends on how you declare the variables, how you make the calls, etc.
Maybe the real trouble isn't the main stack, but the CONFIG_IPC_TASK_STACK_SIZE that is currently 1024

Thanks for your great work here.

nkolban · 2017-10-16T21:50:38Z

What we have is a game of parts. Espressif makes the physical ESP32 chip. Espressif also has a software team that owns the ESP-IDF. Within that team there are individuals for toolchain, individuals for FreeRTOS, individuals for BLE ... and the list goes on. It is also my understand that the Arduino-ESP32 is also built by Espressif but by a distinct individual/team there. What that means to you and me is that when we want to write "BLE and WiFi" apps, these are layered upon layers upon layers ... for example BLE and WiFi live on top of Arduino-ESP32 which lives on top of ESP-IDF which lives (loosely) on top of FreeRTOS ... and at the bottom there is the hardware. What that implies is that a "problem" could be introduced (or need resolution) somewhere other than the layer in which we are working. This means that we need to collaborate between the layers. I'm pretty sure that the Arduino-ESP32 layer team would be happy to change the stack size ... but they are asking "To What?". And that becomes a question for thee and me. The correct answer is for us to tell them what stack size we need. However, we don't have a science for saying "we need 8K/12K/16K/20K etc etc" ... or do we ...?

Within an ESP-IDF/Arduino/FreeRTOS application we can ask the runtime "tell me about the high water mark of stack used". What this means is that if we set the stack to be ... oh ... lets say 50K ... we could run up WiFi and BLE together ... let them cook for a while ... and then ASK the runtime, how much stack are you using or maximally used? This would give us some evidence for what we need.

And in there is the puzzle ... in order to get that information, we need to set the stack to be ... say 50K. In order to achieve that ... we need to have the skills to be able to "tweak" the lower level layer (in this case Arduino-ESP32) to change the stack size. This requires that we re-built the Arduino-ESP32 libraries with the new stack. And that is something Ive never done before. It may be very easy or it may be rocket science ... I haven't had time to go look yet. And that's the next piece of territory that needs explored. Once I have the size and shape of what it looks like to build the Arduino-ESP32 libraries from source and make tweaked changes ... I'll be able to run experiments to determine if stack size is what is needed ... and if not ... what else may be at fault.

me-no-dev · 2017-10-17T00:08:08Z

@nkolban just add a new project, import Arduino as component and call the WiFi and BLE API. Tweak the "magic" number and tell me the result (you can even use the sdkconfig bundled in arduino/tools/sdk in order to have the same config as what is used by Arduino). There is nothing else fancy :) Arduino is just a component in IDF and does not require any extra care ;)

nkolban · 2017-10-17T01:12:06Z

Following mr @me-no-dev instructions, I created a new ESP-IDF project called arduino. I then created a sub-folder in there called components and in components cloned the Arduino-ESP32 project using:

$ git clone https://github.com/espressif/arduino-esp32.git

I then entered the Arduino-esp32 project and performed a:

$ git submodule update --init

This created an environment I could use. I then copied the "sdkconfig" from the Arduino project to my own sdkconfig so we would be the same. I upped the stack size to 20K and built and ran.

Unfortunately, it continued to crash. I enabled gdb debugging and got the following back trace:

#0  0x4008a060 in invoke_abort () at /home/kolban/esp32/esptest/esp-idf/components/esp32/./panic.c:139
#1  0x4008a12e in abort () at /home/kolban/esp32/esptest/esp-idf/components/esp32/./panic.c:148
#2  0x4010145e in __assert_func (file=0x3f4018a0 "/home/kolban/esp32/esptest/esp-idf/components/esp32/./cpu_start.c", line=347, 
    func=<optimized out>, failedexpr=0x3f4018ec "res == pdTRUE") at ../../../.././newlib/libc/stdlib/assert.c:63
#3  0x40080ee8 in start_cpu0_default () at /home/kolban/esp32/esptest/esp-idf/components/esp32/./cpu_start.c:347
#4  0x4008108b in call_start_cpu0 () at /home/kolban/esp32/esptest/esp-idf/components/esp32/./cpu_start.c:207

At first I thought this is the same error we had been seeing ... but now that I look much closer ... even though we are still failing in cpu_start.c we aren't failing at the line I expected ... instead we are failing here:

    portBASE_TYPE res = xTaskCreatePinnedToCore(&main_task, "main",
                                                ESP_TASK_MAIN_STACK, NULL,
                                                ESP_TASK_MAIN_PRIO, NULL, 0);
    assert(res == pdTRUE);   /// <---- This is line 347
    ESP_LOGI(TAG, "Starting scheduler on PRO CPU.");
    vTaskStartScheduler();
    abort(); /* Only get to here if not enough free heap to start scheduler */

Now I'm going to hit the books to see if we can get more diagnostics from this error.

chegewara · 2017-10-17T02:28:12Z

Its the thing, ive got same or simmilar error on esp-idf stack (no arduino).
At first i didnt got it, then i did some changes in menuconfig and then it started to crash like here described.

nkolban · 2017-10-17T04:01:18Z

Here is what I'm starting to find ... 3 permutations:

No BLE, Yes WiFi
Yes WiFi, No BLE
Yes WiFi, Yes BLE

My digging seems to be showing that we are running out of memory when trying to create tasks. So I switched on verbose boot logging. This has shown me the following information:

No BLE, Yes WiFi

I (660) heap_init: Initializing. RAM available for dynamic allocation:
I (672) heap_init: At 3FFAFF10 len 000000F0 (0 KiB): DRAM
I (683) heap_init: At 3FFC8B38 len 000174C8 (93 KiB): DRAM
I (689) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM
I (696) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (707) heap_init: At 4008F29C len 00010D64 (67 KiB): IRAM

Yes BLE, No WiFi

I (753) heap_init: Initializing. RAM available for dynamic allocation:
I (765) heap_init: At 3FFAFF10 len 000000F0 (0 KiB): DRAM
I (777) heap_init: At 3FFCF600 len 00010A00 (66 KiB): DRAM
I (783) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM
I (789) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (801) heap_init: At 4009154C len 0000EAB4 (58 KiB): IRAM

Yes BLE, Yes Wifi ... failure

I (824) heap_init: At 3FFAFF10 len 000000F0 (0 KiB): DRAM
I (835) heap_init: At 3FFD4E90 len 0000B170 (44 KiB): DRAM
I (842) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM
I (848) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (860) heap_init: At 40092348 len 0000DCB8 (55 KiB): IRAM

Summarizing the interesting lines:

No BLE, Yes WiFi - (93 KiB): DRAM
Yes BLE, No WiFi - (66 KiB): DRAM
Yes BLE, Yes Wifi ... failure - (44 KiB): DRAM

What I might now be sensing is that we might be needing to increase the stack size for both BLE and WiFi to run ... but the mere presence of BLE and WiFi together linked into the environment results in there being not enough RAM for them to be together.

My gut is telling me that DRAM is where task stacks may be being allocated from.

I'm also remembering (thought can't find it) a forum or chat post which talked about the latest ESP-IDF and toolchain requiring an extra 20K of RAM to support C++ exception processing.

chegewara · 2017-10-17T04:32:36Z

Non-constant static data and zero-initialized data is placed by the linker into the 256 kB 0x3FFB0000 — 0x3FFF0000 region. Note that this region is reduced by 64kB (by shifting start address to 0x3FFC0000) if Bluetooth stack is used. Length of this region is also reduced by 16 kB or 32kB if trace memory is used. All space which is left in this region after placing static data there is used for the runtime heap.

nkolban · 2017-10-17T04:34:56Z

Have a look at this guys ... espressif/esp-idf#1072 ... this may be part of the story ... I'm not yet sure if the "patch/fix" mentioned in 1072 is available yet ... but it does sniff close.

chegewara · 2017-10-17T06:06:57Z

You can try, for debug purpose, to switch in menuconfig Reserve memory for two cores --> OFF and Run FreeRTOS only on first core --> ON. It lets me pass thru issues with low memory

chegewara · 2017-10-17T06:25:57Z

Now my test program crash at https://github.com/nkolban/esp32-snippets/blob/master/cpp_utils/tests/BLETests/SampleClientWithWiFi.cpp#L110

Most likely its still low memory issue because trace log leads me to
0x4008650a is in xQueueGenericCreate (/home/esp32/esp/esp-idf/components/freertos/./queue.c:388)
388 pxNewQueue = ( Queue_t * ) pvPortMalloc( sizeof( Queue_t ) + xQueueSizeInBytes ); and
0x4008233b is in heap_caps_malloc (/home/esp32/esp/esp-idf/components/heap/./heap_caps.c:123)
123 ret = multi_heap_malloc(heap->heap, size);

mkonnov · 2017-10-23T11:42:24Z

Guys, the problem is fixed.
Take a look into this thread: esp-idf/issues/1072

jestebanes · 2017-10-26T07:43:52Z

The problem is fixed for me too.

Best regards

nkolban · 2017-11-09T02:48:53Z

Closing for now. Re-open as needed.

ifrew · 2018-04-23T15:23:07Z

Dang. I'm getting the bootloop again when ble/wifi enabled. I'm revisiting code I have from last year to see if the ble code size had reduced. I had downloaded an updated core in march. I noticed that #define CONFIG_MAIN_TASK_STACK_SIZE is now 4096. it used to be 8192 and that had fixed the issue. Do you know when was this changed back?

Looked through the history. me-no-dev change it back on October 21st. from 8192 to 4096. Neil, there are so many threads on this issues. Any idea if the root cause was ever found? Are there other defines that fix this like the task stack size? I'm spinning up tasks in my code.

Thanks for any input.

nkolban · 2018-04-23T17:31:20Z

Apparently the stack size was changed in the Arduino environment 6 months ago ... see here:

https://github.com/espressif/arduino-esp32/pull/767/files

ifrew · 2018-04-23T17:40:04Z

Yes, I updated my post after looking at the history. Sorry about that. Still weird stuff going on. My buddy in the UK has same code base as me but he builds under IDF and gets past the bootloader loop I don’t. I’ve compared sdkconfigs and don’t see any real differences yet, still looking as he uses a different esp32 board so digging in there at the moment. Read your post about it may be related to creating tasks I think you may be right. I have other code with wifi/ble both enabled and it runs fine but I don’t use any tasks. In my current code I use tasks. However, I commented out both calls to setup the tasks and it still fails at boot going into a loop even after a clean build. Weird. From: Neil Kolban <[email protected]> Sent: Monday, April 23, 2018 10:31 AM To: nkolban/esp32-snippets <[email protected]> Cc: ifrew <[email protected]>; Comment <[email protected]> Subject: Re: [nkolban/esp32-snippets] (Waiting for Toolchain fix): BLE stack don't compile after the last me-no.dev commit (#81) Apparently the stack size was changed in the Arduino environment 6 months ago ... see here: https://github.com/espressif/arduino-esp32/pull/767/files<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fespressif%2Farduino-esp32%2Fpull%2F767%2Ffiles&data=02%7C01%7C%7Ca180d689d1c14b20982908d5a9400ad6%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636601014875131413&sdata=hxKudTxMG%2BhTE9IPUExREaqJ4XXbPY5IrvQ63L%2FWovA%3D&reserved=0> — You are receiving this because you commented. Reply to this email directly, view it on GitHub<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnkolban%2Fesp32-snippets%2Fissues%2F81%23issuecomment-383657450&data=02%7C01%7C%7Ca180d689d1c14b20982908d5a9400ad6%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636601014875131413&sdata=SCNS9RG3qOjb9uP12LILAzLVjNE5VuV64fCCoCl8BYE%3D&reserved=0>, or mute the thread<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAL-x4C35tbrpj17VKGMiJ10-iPk8sVY4ks5trg_tgaJpZM4Phh0l&data=02%7C01%7C%7Ca180d689d1c14b20982908d5a9400ad6%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636601014875131413&sdata=KhqXzN2dB%2FmvEtAnftr2%2BfupiErTOGEvW2pfirMiqFs%3D&reserved=0>.

nkolban self-assigned this Sep 23, 2017

nkolban added the bug label Sep 23, 2017

nkolban changed the title ~~BLE stack don't compile after the last me-no.dev commit~~ (Waiting for Toolchain fix): BLE stack don't compile after the last me-no.dev commit Oct 4, 2017

nkolban added the blocked label Oct 4, 2017

nkolban added waiting and removed blocked bug labels Oct 14, 2017

nkolban mentioned this issue Oct 21, 2017

BLE Central Arduino Example #45

Closed

nkolban closed this as completed Nov 9, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

(Waiting for Toolchain fix): BLE stack don't compile after the last me-no.dev commit #81

(Waiting for Toolchain fix): BLE stack don't compile after the last me-no.dev commit #81

jestebanes commented Sep 23, 2017 •

edited by nkolban

Loading

nkolban commented Sep 23, 2017

jestebanes commented Sep 26, 2017 •

edited by nkolban

Loading

nkolban commented Sep 26, 2017

jestebanes commented Sep 26, 2017

nkolban commented Oct 14, 2017

jestebanes commented Oct 15, 2017 •

edited by nkolban

Loading

nkolban commented Oct 15, 2017

jestebanes commented Oct 15, 2017

jestebanes commented Oct 15, 2017

jestebanes commented Oct 15, 2017 •

edited by nkolban

Loading

nkolban commented Oct 15, 2017

jestebanes commented Oct 16, 2017 •

edited by nkolban

Loading

nkolban commented Oct 16, 2017

jestebanes commented Oct 16, 2017

nkolban commented Oct 16, 2017

me-no-dev commented Oct 17, 2017

nkolban commented Oct 17, 2017

chegewara commented Oct 17, 2017 •

edited

Loading

nkolban commented Oct 17, 2017

chegewara commented Oct 17, 2017

nkolban commented Oct 17, 2017

chegewara commented Oct 17, 2017

chegewara commented Oct 17, 2017 •

edited

Loading

mkonnov commented Oct 23, 2017

jestebanes commented Oct 26, 2017

nkolban commented Nov 9, 2017

ifrew commented Apr 23, 2018 •

edited

Loading

nkolban commented Apr 23, 2018

ifrew commented Apr 23, 2018 via email

(Waiting for Toolchain fix): BLE stack don't compile after the last me-no.dev commit #81

(Waiting for Toolchain fix): BLE stack don't compile after the last me-no.dev commit #81

Comments

jestebanes commented Sep 23, 2017 • edited by nkolban Loading

nkolban commented Sep 23, 2017

jestebanes commented Sep 26, 2017 • edited by nkolban Loading

nkolban commented Sep 26, 2017

jestebanes commented Sep 26, 2017

nkolban commented Oct 14, 2017

jestebanes commented Oct 15, 2017 • edited by nkolban Loading

nkolban commented Oct 15, 2017

jestebanes commented Oct 15, 2017

jestebanes commented Oct 15, 2017

jestebanes commented Oct 15, 2017 • edited by nkolban Loading

nkolban commented Oct 15, 2017

jestebanes commented Oct 16, 2017 • edited by nkolban Loading

nkolban commented Oct 16, 2017

jestebanes commented Oct 16, 2017

nkolban commented Oct 16, 2017

me-no-dev commented Oct 17, 2017

nkolban commented Oct 17, 2017

chegewara commented Oct 17, 2017 • edited Loading

nkolban commented Oct 17, 2017

chegewara commented Oct 17, 2017

nkolban commented Oct 17, 2017

chegewara commented Oct 17, 2017

chegewara commented Oct 17, 2017 • edited Loading

mkonnov commented Oct 23, 2017

jestebanes commented Oct 26, 2017

nkolban commented Nov 9, 2017

ifrew commented Apr 23, 2018 • edited Loading

nkolban commented Apr 23, 2018

ifrew commented Apr 23, 2018 via email

jestebanes commented Sep 23, 2017 •

edited by nkolban

Loading

jestebanes commented Sep 26, 2017 •

edited by nkolban

Loading

jestebanes commented Oct 15, 2017 •

edited by nkolban

Loading

jestebanes commented Oct 15, 2017 •

edited by nkolban

Loading

jestebanes commented Oct 16, 2017 •

edited by nkolban

Loading

chegewara commented Oct 17, 2017 •

edited

Loading

chegewara commented Oct 17, 2017 •

edited

Loading

ifrew commented Apr 23, 2018 •

edited

Loading