broke after pull #121

d3cline · 2017-10-10T05:22:54Z

I did a git pull tonight which broke my build.
I am sure it is something obvious I am missing,

/home/d3cline/Arduino/libraries/BLE/src/BLEClient.cpp: In member function 'void BLEClient::gattClientEventHandler(esp_gattc_cb_event_t, esp_gatt_if_t, esp_ble_gattc_cb_param_t*)':
/home/d3cline/Arduino/libraries/BLE/src/BLEClient.cpp:166:55: error: no matching function for call to 'BLEUUID::BLEUUID(esp_gatt_id_t&)'
    BLEUUID uuid = BLEUUID(evtParam->search_res.srvc_id);
                                                       ^
In file included from /home/d3cline/Arduino/libraries/BLE/src/BLERemoteService.h:17:0,
                 from /home/d3cline/Arduino/libraries/BLE/src/BLEClient.h:18,
                 from /home/d3cline/Arduino/libraries/BLE/src/BLEClient.cpp:14:
/home/d3cline/Arduino/libraries/BLE/src/BLEUUID.h:26:2: note: candidate: BLEUUID::BLEUUID()
  BLEUUID();
  ^
/home/d3cline/Arduino/libraries/BLE/src/BLEUUID.h:26:2: note:   candidate expects 0 arguments, 1 provided
/home/d3cline/Arduino/libraries/BLE/src/BLEUUID.h:25:2: note: candidate: BLEUUID::BLEUUID(esp_gatt_srvc_id_t)
  BLEUUID(esp_gatt_srvc_id_t srcvId);
  ^
/home/d3cline/Arduino/libraries/BLE/src/BLEUUID.h:25:2: note:   no known conversion for argument 1 from 'esp_gatt_id_t' to 'esp_gatt_srvc_id_t'
/home/d3cline/Arduino/libraries/BLE/src/BLEUUID.h:24:2: note: candidate: BLEUUID::BLEUUID(uint8_t*, size_t, bool)
  BLEUUID(uint8_t* pData, size_t size, bool msbFirst);
  ^
/home/d3cline/Arduino/libraries/BLE/src/BLEUUID.h:24:2: note:   candidate expects 3 arguments, 1 provided
/home/d3cline/Arduino/libraries/BLE/src/BLEUUID.h:23:2: note: candidate: BLEUUID::BLEUUID(esp_bt_uuid_t)
  BLEUUID(esp_bt_uuid_t uuid);
  ^
/home/d3cline/Arduino/libraries/BLE/src/BLEUUID.h:23:2: note:   no known conversion for argument 1 from 'esp_gatt_id_t' to 'esp_bt_uuid_t'
/home/d3cline/Arduino/libraries/BLE/src/BLEUUID.h:22:2: note: candidate: BLEUUID::BLEUUID(uint32_t)
  BLEUUID(uint32_t uuid);
  ^
/home/d3cline/Arduino/libraries/BLE/src/BLEUUID.h:22:2: note:   no known conversion for argument 1 from 'esp_gatt_id_t' to 'uint32_t {aka unsigned int}'
/home/d3cline/Arduino/libraries/BLE/src/BLEUUID.h:21:2: note: candidate: BLEUUID::BLEUUID(uint16_t)
  BLEUUID(uint16_t uuid);
  ^
/home/d3cline/Arduino/libraries/BLE/src/BLEUUID.h:21:2: note:   no known conversion for argument 1 from 'esp_gatt_id_t' to 'uint16_t {aka short unsigned int}'
/home/d3cline/Arduino/libraries/BLE/src/BLEUUID.h:20:2: note: candidate: BLEUUID::BLEUUID(std::__cxx11::string)
  BLEUUID(std::string uuid);
  ^
/home/d3cline/Arduino/libraries/BLE/src/BLEUUID.h:20:2: note:   no known conversion for argument 1 from 'esp_gatt_id_t' to 'std::__cxx11::string {aka std::__cxx11::basic_string<char>}'
/home/d3cline/Arduino/libraries/BLE/src/BLEUUID.h:18:7: note: candidate: constexpr BLEUUID::BLEUUID(const BLEUUID&)
 class BLEUUID {
       ^
/home/d3cline/Arduino/libraries/BLE/src/BLEUUID.h:18:7: note:   no known conversion for argument 1 from 'esp_gatt_id_t' to 'const BLEUUID&'
/home/d3cline/Arduino/libraries/BLE/src/BLEUUID.h:18:7: note: candidate: constexpr BLEUUID::BLEUUID(BLEUUID&&)
/home/d3cline/Arduino/libraries/BLE/src/BLEUUID.h:18:7: note:   no known conversion for argument 1 from 'esp_gatt_id_t' to 'BLEUUID&&'
/home/d3cline/Arduino/libraries/BLE/src/BLEClient.cpp:167:94: error: no matching function for call to 'BLERemoteService::BLERemoteService(esp_gatt_id_t&, BLEClient*)'
    BLERemoteService* pRemoteService = new BLERemoteService(evtParam->search_res.srvc_id, this);
                                                                                              ^
In file included from /home/d3cline/Arduino/libraries/BLE/src/BLEClient.h:18:0,
                 from /home/d3cline/Arduino/libraries/BLE/src/BLEClient.cpp:14:
/home/d3cline/Arduino/libraries/BLE/src/BLERemoteService.h:29:2: note: candidate: BLERemoteService::BLERemoteService(esp_gatt_srvc_id_t, BLEClient*)
  BLERemoteService(esp_gatt_srvc_id_t srvcId, BLEClient* pClient);
  ^
/home/d3cline/Arduino/libraries/BLE/src/BLERemoteService.h:29:2: note:   no known conversion for argument 1 from 'esp_gatt_id_t' to 'esp_gatt_srvc_id_t'
/home/d3cline/Arduino/libraries/BLE/src/BLERemoteService.h:27:7: note: candidate: BLERemoteService::BLERemoteService(const BLERemoteService&)
 class BLERemoteService {
       ^
/home/d3cline/Arduino/libraries/BLE/src/BLERemoteService.h:27:7: note:   candidate expects 1 argument, 2 provided
exit status 1
Error compiling for board ESP32 Dev Module.

The text was updated successfully, but these errors were encountered:

d3cline · 2017-10-10T05:35:41Z

nm, guessing its #82 , :(

d3cline · 2017-10-10T05:38:46Z

I have the 'old' toolchain,

$ xtensa-esp32-elf-gcc -v
Using built-in specs.
COLLECT_GCC=xtensa-esp32-elf-gcc
COLLECT_LTO_WRAPPER=/home/d3cline/esp/xtensa-esp32-elf/bin/../libexec/gcc/xtensa-esp32-elf/5.2.0/lto-wrapper
Target: xtensa-esp32-elf
Configured with: /home/ivan/e/crosstool-NG/.build/src/gcc-5.2.0/configure --build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu --target=xtensa-esp32-elf --prefix=/home/ivan/e/crosstool-NG/builds/xtensa-esp32-elf --with-local-prefix=/home/ivan/e/crosstool-NG/builds/xtensa-esp32-elf/xtensa-esp32-elf/sysroot --with-sysroot=/home/ivan/e/crosstool-NG/builds/xtensa-esp32-elf/xtensa-esp32-elf/sysroot --with-newlib --enable-threads=no --disable-shared --with-pkgversion='crosstool-NG crosstool-ng-1.22.0-61-gab8375a' --disable-__cxa_atexit --enable-cxx-flags='-fno-exceptions -fno-rtti' --with-gmp=/home/ivan/e/crosstool-NG/.build/xtensa-esp32-elf/buildtools --with-mpfr=/home/ivan/e/crosstool-NG/.build/xtensa-esp32-elf/buildtools --with-mpc=/home/ivan/e/crosstool-NG/.build/xtensa-esp32-elf/buildtools --with-isl=/home/ivan/e/crosstool-NG/.build/xtensa-esp32-elf/buildtools --with-cloog=/home/ivan/e/crosstool-NG/.build/xtensa-esp32-elf/buildtools --with-libelf=/home/ivan/e/crosstool-NG/.build/xtensa-esp32-elf/buildtools --enable-lto --enable-target-optspace --without-long-double-128 --disable-libgomp --disable-libmudflap --disable-libssp --disable-libquadmath --disable-libquadmath-support --disable-nls --disable-multilib --enable-languages=c,c++ --disable-libstdcxx-verbose
Thread model: single
gcc version 5.2.0 (crosstool-NG crosstool-ng-1.22.0-61-gab8375a)

d3cline · 2017-10-10T06:20:17Z

I tried updating but that didn't help

$ xtensa-esp32-elf-gcc -v
Using built-in specs.
COLLECT_GCC=xtensa-esp32-elf-gcc
COLLECT_LTO_WRAPPER=/home/d3cline/esp/xtensa-esp32-elf/bin/../libexec/gcc/xtensa-esp32-elf/5.2.0/lto-wrapper
Target: xtensa-esp32-elf
Configured with: /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/configure --build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu --target=xtensa-esp32-elf --prefix=/builds/idf/crosstool-NG/builds/xtensa-esp32-elf --with-local-prefix=/builds/idf/crosstool-NG/builds/xtensa-esp32-elf/xtensa-esp32-elf/sysroot --with-sysroot=/builds/idf/crosstool-NG/builds/xtensa-esp32-elf/xtensa-esp32-elf/sysroot --with-newlib --enable-threads=no --disable-shared --with-pkgversion='crosstool-NG crosstool-ng-1.22.0-73-ge28a011' --disable-__cxa_atexit --enable-cxx-flags='-fno-rtti -ffunction-sections' --with-gmp=/builds/idf/crosstool-NG/.build/xtensa-esp32-elf/buildtools --with-mpfr=/builds/idf/crosstool-NG/.build/xtensa-esp32-elf/buildtools --with-mpc=/builds/idf/crosstool-NG/.build/xtensa-esp32-elf/buildtools --with-isl=/builds/idf/crosstool-NG/.build/xtensa-esp32-elf/buildtools --with-cloog=/builds/idf/crosstool-NG/.build/xtensa-esp32-elf/buildtools --with-libelf=/builds/idf/crosstool-NG/.build/xtensa-esp32-elf/buildtools --enable-lto --enable-target-optspace --without-long-double-128 --disable-libgomp --disable-libmudflap --disable-libssp --disable-libquadmath --disable-libquadmath-support --disable-nls --disable-multilib --enable-languages=c,c++ --disable-libstdcxx-verbose --enable-threads=posix --enable-gcov-custom-rtio
Thread model: posix
gcc version 5.2.0 (crosstool-NG crosstool-ng-1.22.0-73-ge28a011)

nkolban · 2017-10-10T13:18:38Z

Unfortunately the Arduino BLE libraries have a sign on them "Out of Order" for just now. It is hoped to be back in service in about a week.

d3cline · 2017-10-10T13:25:39Z

Do you really feel it will be fixed in a week? I know it is not your fault, it is espriff's but I am starting to feel they can go the way of commodore and dragon computer if they can't get customer demand right and fast. I have already wasted 6 months waiting for this chip to be what I need and I was ready to move forward with PCBA, etc... This is beyond disappointing.

nkolban · 2017-10-10T13:42:39Z

Things take time. Let us review the story. A little over 2 weeks ago new function was added into the development stream of the ESP-IDF. ESP-IDF has releases and "best so far". The current release is 2.1 and the best so far is the ESP-IDF Master. The ESP-IDF master made some changes that broke the existing BLE C++ classes that work against both ESP-IDF and Arduino. However, because the release at 2.1 is ... well ... a release, the libraries continued to work. What caused grief was the fact that the Arduino-ESP32 libraries were refreshed to use the latest ESP-IDF from master (not the a release build). In there is what I consider the error to be (opinion).

Arduino-ESP32 bases itself on ESP-IDF pre-GA 3.0 and not a release. That's the mistake. The purpose of having a development stream is that things are allowed to break. Releases are polished and should be as clean and solid as can be.

There is even more to the story in that for the last two weeks, there have been significant holidays in China where Espressif is based. I live in the US ... if a problem comes up on December 23rd, I will stand up and say no-one is going to look at it with conviction until January 2nd.

For me, I look at the ESP32 with patience and calmness. Things take time. Development of any quality product is is a marathon and not a sprint. If memory serves me correctly, the ESP32 isn't even one year old yet. Things take time.

d3cline · 2017-10-10T13:54:15Z

Thanks for all the effort. I guess I will have to sit and wait until it is fixed or the nordic chips get here.

nkolban · 2017-10-14T03:23:16Z

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.

carlkyu · 2017-10-14T18:24:09Z

I just rebuilt using the latest Arduino ESP32 project. I'm using the 'included' BLE examples. (Congrats!)

On my sparkfun ESP32, I'm unable to run most of the examples. I get this on my Serial.

E (1167) esp_pthread: pthread_setspecific: not supported!
abort() was called at PC 0x400e93ff on core 0

Backtrace: 0x400894f8:..
Rebooting...

This happens whenever BLEDevice::createServer(); is called. I noticed that BLE_scan does not require a server -- so that example works great.

nkolban · 2017-10-14T18:55:59Z

First thing I'd want to look at is to make sure that the toolchain was also upgraded to the latest level. I'm new to working in Arduino land ... do you have a link to the instructions you followed?

On my Linux environment, I would run the following command to see what version of the toolchain I am using:

$ cd <ArduinoRoot>/hardware/espressif/esp32/tools/xtensa-esp32-elf/bin
$ ./xtensa-esp32-elf-cc -v

At the time of writing, I expect to see the following:

gcc version 5.2.0 (crosstool-NG crosstool-ng-1.22.0-73-ge28a011)

Is this what you also see?

carlkyu · 2017-10-14T19:26:44Z

Thanks for the quick response/look.
I got the same running that command.

...
Thread model: posix
gcc version 5.2.0 (crosstool-NG crosstool-ng-1.22.0-73-ge28a011)

I followed these instructions. Specifically, I'm on a MAC (and those instructions), but I don't think that should break things.
https://github.com/espressif/arduino-esp32#installation-instructions

nkolban · 2017-10-14T20:39:52Z

Trying the sample called "BLE_server", all works for me. It would have been too easy/nice if I could get it to fail the same way. It tried it on a variety of boards including a Sparkfun.

Suggestions I might offer:

Create a brand new instance of Arduino IDE and re-build the ESP32 environment. Lets just be as sure as we can be that there is nothing "left over" from previous releases.
In the exception/trace that is logged. Specifically, if there is a back trace, we can decode that by looking at the tool found here:

https://github.com/me-no-dev/EspExceptionDecoder

One can paste in the backtrace and get a decode of where within the code an exception was detected. Extremely useful for reporting/debugging.

We can find a time where we are both online and do a screen sharing session to have a fresh pair of eyes looking at the puzzle.

carlkyu · 2017-10-14T21:14:59Z

Wow. Thanks for the offer. Before the screen sharing. Here's what I did.

I purged the Arduino folder in the user dir to start from scratch. I did not replace Arduino IDE because I don't think that has any relation. I also did not replace my gcc compiler (or python on my MAC) because I don't think that's used.

I followed the instructions to install the toolchain on:
https://github.com/espressif/arduino-esp32#installation-instructions
And then I went to install the debug trace tool:
https://github.com/me-no-dev/EspExceptionDecoder

I then just used the default BLE_server example and got the same results.

"E (1167) esp_pthread: pthread_setspecific: not supported!"

This time I was able to use the exception trace tool to get resolve this:

0x400894f8: invoke_abort at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/esp32/./panic.c line 553
0x400895f7: abort at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/esp32/./panic.c line 553
0x400e8f13: __cxxabiv1::__terminate(void (*)()) at /Volumes/build/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc line 112
0x400e8f5a: std::terminate() at /Volumes/build/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc line 112
0x400e894a: __cxa_get_globals at /Volumes/build/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/eh_globals.cc line 133
0x400e8fc7: __cxa_throw at /Volumes/build/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/eh_throw.cc line 65
0x400da9d7: std::__throw_length_error(char const*) at /Volumes/build/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/src/c++11/functexcept.cc line 122
0x400e1a0a: std::__cxx11::basic_string  , std::allocator  >::_M_create(unsigned int&, unsigned int) at /Volumes/build/idf/crosstool-NG/.build/xtensa-esp32-elf/build/build-cc-gcc-final/xtensa-esp32-elf/libstdc++-v3/include/bits/basic_string.h line 2200
0x400e1b96: std::__cxx11::basic_string  , std::allocator  >::_M_mutate(unsigned int, unsigned int, char const*, unsigned int) at /Volumes/build/idf/crosstool-NG/.build/xtensa-esp32-elf/build/build-cc-gcc-final/xtensa-esp32-elf/libstdc++-v3/include/bits/basic_string.h line 2200
0x400e1ee1: std::__cxx11::basic_string  , std::allocator  >::_M_replace(unsigned int, unsigned int, char const*, unsigned int) at /Volumes/build/idf/crosstool-NG/.build/xtensa-esp32-elf/build/build-cc-gcc-final/xtensa-esp32-elf/libstdc++-v3/include/bits/basic_string.h line 2200
0x400e1f21: std::__cxx11::basic_string  , std::allocator  >::assign(char const*) at /Volumes/build/idf/crosstool-NG/.build/xtensa-esp32-elf/build/build-cc-gcc-final/xtensa-esp32-elf/libstdc++-v3/include/bits/basic_string.h line 2200
0x400e1f31: std::__cxx11::basic_string  , std::allocator  >::operator=(char const*) at /Volumes/build/idf/crosstool-NG/.build/xtensa-esp32-elf/build/build-cc-gcc-final/xtensa-esp32-elf/libstdc++-v3/include/bits/basic_string.h line 2200
0x400d8d6e: FreeRTOS::Semaphore::give() at /Users/user/Documents/Arduino/hardware/espressif/esp32/libraries/BLE/src/FreeRTOS.cpp line 126
0x400d5bb9: BLEServer::handleGATTServerEvent(esp_gatts_cb_event_t, unsigned char, esp_ble_gatts_cb_param_t*) at /Users/user/Documents/Arduino/hardware/espressif/esp32/libraries/BLE/src/BLEServer.cpp line 115
0x400d4df9: BLEDevice::gattServerEventHandler(esp_gatts_cb_event_t, unsigned char, esp_ble_gatts_cb_param_t*) at /Users/user/Documents/Arduino/hardware/espressif/esp32/libraries/BLE/src/BLEDevice.cpp line 47
0x400fa2f9: 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
0x400f67a2: btc_task at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/bt/bluedroid/btc/core/btc_task.c line 85

Thanks so much for your support and help so far!

carlkyu · 2017-10-14T21:19:23Z

Also, after all this, I was able to successfully run BLE_scan with no problems at all! So the BLE stack and HW seems okay. Just BLEDevice::createServer() in particular. Are you sure its not some weird threading issue or something related to my compiler or compiler setting?

carlkyu · 2017-10-14T21:44:46Z

So one more data point. I just started from scratch on a windows PC I had laying around. Went through the same process. Did not need python on windows, as they have a get.exe tool for PC install.

Same error. I'm starting to think its SparkFUN's ESP 32 implementation.

carlkyu · 2017-10-14T22:01:17Z

Apologies for spamming this thread. However, this is relevant. Found this thread. It appears others have had the same problem I'm experiencing.

espressif/arduino-esp32#423
"MarosValter commented on Aug 28"
"alexkirillov had a similar experience."

They may be using the SparkFun ESP32 board as well. I wonder if this is board specific.

nkolban · 2017-10-14T22:46:36Z

Something I forgot to ask ... are you running the Arduino IDE on Windows or Linux?

carlkyu · 2017-10-14T23:18:51Z

I've now tried these libraries on MacOSX Arduino IDE and also Windows Arduino IDE. Exactly the same error message results/problem.

When my NodeMCU ESP32 board comes from Amazon, I'll try again and see if I get the same results. So far, on PC and MAC on a SparkFun ESP32 IOT board, I get this panic and reboot behavior.

nkolban · 2017-10-14T23:27:16Z

I too have a Sparkfun board (the red-one) and can't re-produce the problem. While it may be your board, that would surprise me. We have more tests that we can perform. First ... have you been trying any programming at the ESP-IDF level? I'm still looking for something else in your environment that may be "contaminating". An example of this would be having installed other versions of ESP-IDF for other purposes.

Another test we can perform is to 100% erase the ESP32 flash memory. If you have the ESP-IDF installed, we can run "make erase_flash". This will 100% wipe flash and your device will be fully reset ready for a new flash from the Arduino IDE.

carlkyu · 2017-10-15T00:14:32Z

Okay, so I installed ESP-IDF. And ran their hello_world. I was also able to make erase_flash my board and it cleared my board at 7.7s. After that, I tried the Arduino examples again. Same result. Do you have instructions to try to make BLE_server project using ESP-IDF?

I can try that then.

Thanks

nkolban · 2017-10-15T01:24:07Z

The samples for ESP-IDF are found here:

https://github.com/nkolban/esp32-snippets/tree/master/cpp_utils/tests/BLETests

I hate to make you learn ESP-IDF just to get to Arduino. If needed, I'll be happy to spend time on a screen share with you.

With others working and you not, I'm head scratching on the possibilities. It will likely be a "duh" moment when we find it ... but isn't that always the way. You say you have another board on order? I had heard that the Sparkfun had issues related to serial output and a clock setting had to be changed but I'm not seeing that affect our story. Its a head scratcher. If we look at the distinction between your environment and others the common culprits are:

Installed software (ESP-IDF, Arduino, Arduino-ESP32 libs, BLE libs)
Environment variables
...

While I haven't previously been able to point to an ESP32 board and say "its broke" ... I guess it is always possible. In my testing, I have boxes of them and haven't yet broken one.

Pouring over the trace you got. I have another (new) idea ... lets try and capture BLE Trace. The library that provides BLE also includes BLE tracing ... see the following for how to engage it:

https://github.com/nkolban/esp32-snippets/blob/master/cpp_utils/ArduinoBLE.md#switching-on-debugging

Change that flag, rebuilt in Arduino and re-flash. Ideally, we will get some new clues/hints. The problem is being recorded south of the BLE libraries ... but it may give us a hint.

carlkyu · 2017-10-15T02:32:49Z

Very gracious of you to offer your time and help to screen share to track this down. So, I have some interesting news!

When I switched on debugging to level 5. BLE_server fully worked!! With a lot more verbose output. Perhaps this is some kind of race condition? I then tried it at different debug levels (starting with 1 again.) 1 causes the same panic and reboot. Apparently debug levels 1-4 present identically and panic/reboot. Debug level 5 works. I tried switching back 1 and 5 multiple times because I thought it might have been a compile or flash memory issue with the board -- it clearly works on 5 and does not work on 1. STRANGE!

I was able to replicate this behavior on my Windows Arduino IDE as well as MACOSX Arduino IDE.

carlkyu · 2017-10-15T02:33:59Z

BTW, when I saw that 1-4 present identically -- I mean the output on the Serial Monitor was identically sparse. There's no additional information until you get to 5. So I just don't know why one works over the other!!

carlkyu · 2017-10-15T02:41:37Z

Also, because I hate forum/discussions that link to outside pages (that might break) to provide a fix. I was able to fix the panic/reboot problem by editing from "1" to "5"

#define CONFIG_LOG_DEFAULT_LEVEL 5

in

(ArduinoIDE)/hardware/espressif/esp32/tools/sdk/include/config/sdkconfig.h

nkolban · 2017-10-15T03:10:50Z

This is actually good (but worrying) news ... what we have now is another symptom of this #109 .

It appears to manifest (in your case in a different place) but the story feels different. It seems that when we have debugging on, no problem but switch debugging off ... problem. Worse ... in #109, we took it further and have shown it not to be a race condition. The good news is that you now at least have an interim fix ... run with verbose debugging. Obviously that isn't ideal and isn't our intent to leave that that way ... but it will allow you to make some progress while we look to a cure.

carlkyu · 2017-10-15T03:42:08Z

Yes thank you for your help and hopefully you'll find what's happening and fix both problems.

nkolban · 2017-10-15T05:12:51Z

If possible, I'd like y'all to run another test. In the

(ArduinoIDE)/hardware/espressif/esp32/tools/sdk/include/config/sdkconfig.h

take a copy of it and then edit it.
Find the line that reads:

#define CONFIG_OPTIMIZATION_LEVEL_DEBUG 1

and change it to:

#define CONFIG_OPTIMIZATION_LEVEL_RELEASE 1

switch off the debugging by setting

#define CONFIG_LOG_DEFAULT_LEVEL 1

In #109 we seem to see that make a difference in that problem and we are curious if changing the optimization to release will have a similar effect with this problem.

carlkyu · 2017-10-15T05:47:57Z

Unfortunately, that did not work. I tried several variations -- but really the only thing that made a difference is CONFIG_LOG_DEFAULT_LEVEL 5. RELEASE/DEBUG seemed to make no difference.

It did not work with RELEASE and LOG_DEFAULT_LEVEL 1.

nkolban · 2017-10-15T15:52:53Z

You are making me work on this one ... that's great. Feel free to ping me on IRC on channel #ESP32 as needed. The GREAT news is that I recreated here. Since that is big news, let me explain what I did. In #125, another user has the same puzzle. He isn't using Sparkfun ... so I was about to discount Sparkfun as the puzzle but then it dawned on me ... I have quite a few devices ... why don't I just try and plug in a selection of mine. I plugged in board A, it worked, board B ... it worked ... board C ... and BANG ... it failed. Doing my traces, it is an exact match for your puzzle. On another hunch, I have a few copies of board C ... so just to validate, I plugged in a different instance of board C ... and it worked (Oh No!!!). I went back to the first board C ... and it failed ... I validated a couple of times that this was recreatable. What this seems to tell me that the puzzle isn't just "some boards work and some don't" but rather "some instances of a given model of board work and others don't". My next tests will be to examine those two boards and look for distinctions (release levels etc etc).

nkolban · 2017-10-15T16:36:13Z

https://pasteboard.co/GP4foQe.jpg

Link to picture above.

Here is a picture of my boards ... the one on top fails, the one on the bottom works. As you can see, they are both DevKitC ... it should also be obvious that the one on the top has no shielding while the one on the bottom does. This is how "they came" ... I believe the one on the top is older that the one on the bottom. Using the system call "esp_chip_info" they both report identical information:

model: 0
features: 0x50
cores: 2
revision: 0

nkolban · 2017-10-15T18:12:25Z

Great news!!!

We have a fix/workaround which I have tested on my failing system. First, let me give you the story so that it is recorded for the record. Today I found that I have one board (of many) which fails in the same way as that of other users reported. What is different from this one board than from the others, I don't know ... however it is my oldest board so makes me think that there might be some internal hardware revision that is causing grief. That said, I wasn't happy with the notion of saying "You are out of luck if you have an old board". So I dug deeper and deeper into the code. Since switching on trace causes the problem to disappear, the thinking was a race condition (and that does appear to be the final answer). So I inserted printf() statements throughout the code until I got to the area that causes the problem.

Within the BLE code there are "callbacks" in play all over the place. These callbacks are executed when data is received asynchronously from the ESP32 BLE partner. Because these callbacks can occur at any time and are executed on a separate thread/task, we have to guard against data being corrupted ... for example, data being modified in one thread while a callback occurs right in the middle of that and attempts to step on the data that is being modified. To that end we use Semaphores to provide a mutual exclusion ... when Thread A is manipulating the data, Thread B can't touch it until Thread A completes. In the latest toolchain supplied by Espressif, this whole area was re-worked to use a new threading model called "pthreads". That's as much as I know about that except to say that when code is changed, things tend to break.

In the BLE C++ code there is a method coded as follows:

void FreeRTOS::Semaphore::give() {
	xSemaphoreGive(m_semaphore);
	ESP_LOGV(LOG_TAG, "Semaphore giving: %s", toString().c_str());
	m_owner = "<N/A>";
} // Semaphore::give

What this method does is release a semaphore and then, if debugging is enabled, log that it was released. By pure experimentation, I found that when we don't delay after the release of the semaphore, we break but if we do pause (eg. by invoking the debug line we work). I have changed the code to:

void FreeRTOS::Semaphore::give() {
	xSemaphoreGive(m_semaphore);
#ifdef ARDUINO_ARCH_ESP32
	FreeRTOS::sleep(10);
#endif
	ESP_LOGV(LOG_TAG, "Semaphore giving: %s", toString().c_str());
	m_owner = "<N/A>";
} // Semaphore::give

This sleeps for 10msecs and everything seems to work solidly. Again it should be noted that:

The problem only manifested on a few boards
The problem seems constrained to Arduino-ESP32 runtime and doesn't seem to manifest in ESP-IDF runtime.

With these code changes in place, we seem to be good. Now we need to figure out how we want to distribute patches since Arduino-ESP32 is now distributing the BLE classes.

My best guess is the following:

Go to your <Arduino>/hardware/espressif/esp32/librarues/BLE directory and remove all the files in there. Now repopulate that directory with the files found here:

https://github.com/nkolban/ESP32_BLE_Arduino

which includes the fixes for this issue. Rebuilt and re-test.

I'll work with the Arduino-ESP32 project owner to see how we can get the Arduino-ESP32 refreshed.

carlkyu · 2017-10-15T18:21:06Z

Very cool. Congrats on tracking this down so readily and implementing a pretty simple but effective fix!

nkolban · 2017-10-15T18:54:06Z

Thanks for the kind words ... this one was painful. Hours and hours of slow plodding .... but like the marines say (which I am so far away from being like one it isn't funny) ... leave no user behind :-)

I'll be interested to hear from good folks like yourself who may say "I had the problem, grabbed the new code and now I don't". We also have espressif/arduino-esp32 number 731 to try and get to the bottom of it ... but that will require some guru mediation from those with more knowledge. The BLE C++ classes live in "user code" space and not deep in the internals which is where timing and threading is implemented.

carlkyu · 2017-10-15T20:53:57Z

I'll give the updated code a shot late tonight or mid day tomorrow and let you know.

d3cline · 2017-10-15T21:15:10Z

I just saw these updated messages, I will read all of this and test the changes and report my findings ASAP. I know I can be an abrasive personality, but I am really grateful for the work, downstream is some good things waiting for it.

d3cline · 2017-10-15T22:24:19Z

I can't get the examples to build. I have tried a few the current one I am trying is
https://raw.githubusercontent.com/nkolban/esp32-snippets/master/cpp_utils/tests/BLETests/SampleRead.cpp

To get this far I,

did a git pull for the esp32 repo
verified I am on the right idf version as above
The ./libraries/BLE directory was already empty, I copied the contents of https://github.com/nkolban/ESP32_BLE_Arduino into it, it was missing 'Tasks.cpp and Tasks.h' so I searched the repo for them and copied them from https://github.com/nkolban/esp32-snippets/tree/642987a835e02625cf68ff1897ca688349f7a74e/cpp_utils

This is where it currently fails,

arduino.ar(main.cpp.o):(.literal._Z8loopTaskPv+0x0): undefined reference to `setup()'
arduino.ar(main.cpp.o):(.literal._Z8loopTaskPv+0x4): undefined reference to `loop()'
arduino.ar(main.cpp.o): In function `loopTask(void*)':
/home/d3cline/Arduino/hardware/espressif/esp32/cores/esp32/main.cpp:15: undefined reference to `setup()'
/home/d3cline/Arduino/hardware/espressif/esp32/cores/esp32/main.cpp:17: undefined reference to `loop()'
collect2: error: ld returned 1 exit status
exit status 1
Error compiling for board ESP32 Dev Module.

jestebanes · 2017-10-15T22:32:49Z

Hello Neil, great great work I have no words to express my admiration
I test my code without WIFI and the new semaphore fix and for the very first time BLE work smoothly.
With the previous versions of BLE, I saw my ESP advertising every two or three seconds, now is advertising every 42mS, this is great news for me.

Best regards

d3cline · 2017-10-15T22:42:20Z

I think the missing setup and loop functions are it, just noticed will try and update. (that was it, got it building, will report my findings actually running on chip shortly)

d3cline · 2017-10-15T23:05:03Z

After moving around the functions from the example I got it to broadcast. I want to try to integrate it into some of my i2c stuff and see if I can use it for my 'production' which would be a great boon and allow me to move off of curie for prototyping. (I won't update until it is very stable)

nkolban · 2017-10-15T23:13:17Z

I think we are quite some way from being "stable" ... this is a community effort and we are all learning as we go along. Keep your expectations low but realize that when problems are found, they'll be looked at quickly ... just not professionally.

d3cline · 2017-10-15T23:19:31Z

I work for a host and have for 8 years, I understand the open source community. and am very grateful. I also understand sometimes upstream providers need to be goaded a little (not you, the chip manufs upstream). Thanks again. I will do what I can to provide feedback and break things. If you would, can you update this thread when these changes have made it into the main repo?

nkolban · 2017-10-16T00:46:48Z

Not a problem sir. Will update this issue with the news when the changes are part of the Arduino-ESP32 distribution.

d3cline · 2017-10-16T13:27:50Z

So far I have been able to send data I captured from I2C over 2 characteristics of 80 bytes each. So this works for my needs, I have noticed some kind of bug when I have it disconnected from the serial and I am tracking this down, it might be my circuit design. Just wanted to post that as far as I can tell everything seems to be working at least with the client read example. I want to be sure things are more stable before I pull the latest down again so I will keep an eye on this thread. Thanks again.

nkolban · 2017-11-04T22:46:18Z

Closing for just now. Re-open as needed.

nkolban added the blocked label Oct 10, 2017

d3cline mentioned this issue Oct 11, 2017

RFC: BLE support espressif/arduino-esp32#423

Closed

7 tasks

nkolban added waiting and removed blocked labels Oct 14, 2017

nkolban mentioned this issue Oct 15, 2017

BLE arduino example Crash #125

Closed

nkolban added a commit that referenced this issue Oct 15, 2017

Fixes for #121

e215aa9

nkolban mentioned this issue Oct 15, 2017

Race condition with semaphores ... manifesting in BLE libraries espressif/arduino-esp32#731

Closed

nkolban mentioned this issue Oct 15, 2017

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

Closed

medamarko mentioned this issue Oct 16, 2017

Pthread not supported on BLE write example espressif/arduino-esp32#733

Closed

pieman64 mentioned this issue Nov 3, 2017

ESP32 reboots periodically Edzelf/ESP32-Radio#49

Open

nkolban closed this as completed Nov 4, 2017

broke after pull #121

broke after pull #121

Comments

d3cline commented Oct 10, 2017

d3cline commented Oct 10, 2017 • edited

d3cline commented Oct 10, 2017 • edited

d3cline commented Oct 10, 2017

nkolban commented Oct 10, 2017

d3cline commented Oct 10, 2017

nkolban commented Oct 10, 2017 • edited

d3cline commented Oct 10, 2017

nkolban commented Oct 14, 2017

carlkyu commented Oct 14, 2017

nkolban commented Oct 14, 2017

carlkyu commented Oct 14, 2017

nkolban commented Oct 14, 2017

carlkyu commented Oct 14, 2017

carlkyu commented Oct 14, 2017

carlkyu commented Oct 14, 2017

carlkyu commented Oct 14, 2017

nkolban commented Oct 14, 2017

carlkyu commented Oct 14, 2017

nkolban commented Oct 14, 2017

carlkyu commented Oct 15, 2017

nkolban commented Oct 15, 2017

carlkyu commented Oct 15, 2017

carlkyu commented Oct 15, 2017

carlkyu commented Oct 15, 2017 • edited

nkolban commented Oct 15, 2017

carlkyu commented Oct 15, 2017

nkolban commented Oct 15, 2017

carlkyu commented Oct 15, 2017

nkolban commented Oct 15, 2017

nkolban commented Oct 15, 2017

nkolban commented Oct 15, 2017

carlkyu commented Oct 15, 2017

nkolban commented Oct 15, 2017 • edited

carlkyu commented Oct 15, 2017

d3cline commented Oct 15, 2017 • edited

d3cline commented Oct 15, 2017

jestebanes commented Oct 15, 2017

d3cline commented Oct 15, 2017 • edited

d3cline commented Oct 15, 2017

nkolban commented Oct 15, 2017

d3cline commented Oct 15, 2017

nkolban commented Oct 16, 2017

d3cline commented Oct 16, 2017

nkolban commented Nov 4, 2017

d3cline commented Oct 10, 2017 •

edited

d3cline commented Oct 10, 2017 •

edited

nkolban commented Oct 10, 2017 •

edited

carlkyu commented Oct 15, 2017 •

edited

nkolban commented Oct 15, 2017 •

edited

d3cline commented Oct 15, 2017 •

edited

d3cline commented Oct 15, 2017 •

edited