You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am trying to pair a Heltec Wireless Stick (V3) to a Polar H10 Heart Rate Monitor and get a crash when calling getServices(). This happens on the example BLEScan and BLEClient examples without any alteration (save the Service UUID of 0x180D and Characteristic UUID of 0x2A37 for the BLEClient example).
I did not have the heart rate monitor when I got the HelTec device, so I familiarized myself with the API by altering the BLEScan example to connect to every address it found to getServices() from each device and getCharacteristics() from each service similar to BLEClient. I ran it in many public places while figuring it out and probably connected to several hundred devices and it worked without a crash.
When the Polar H10 became available, the program immediately crashed. This is a bit of a problem as that is the device I specifically need to use.
The complete serial log with CORE_DEBUG_LEVEL set to VERBOSE from boot to reboot is included at the end of the post. The BLEScan I have been using is unchanged except for the service and characteristic UUIDs and a few Serial.println() calls used to isolate the crash. Nothing of substance is changed. Directly below is an excerpt from BLEScan where the service and characteristic UUIDs are set for the heart rate monitor.
// The remote service we wish to connect to.
static BLEUUID serviceUUID((uint16_t) ESP_GATT_UUID_HEART_RATE_SVC);
// The characteristic of the remote service we are interested in.
static BLEUUID charUUID((uint16_t) ESP_GATT_HEART_RATE_MEAS);
It is only possible to verify the serviceUUID is working as expected since the sketch does connect to the Polar H10 as soon as it is found, but does not get past getServices(). The serviceUUID does not seem to be the problem, though.
It appears the call to connect() completes, but the next call to getServices() causes the crash. Below is the verbose output from BLEScan during the call to getServices():
I tried getService(UUID) but got the same crash. The code for getService(UUID) is very basic and returns an element of m_servicesMap suggesting that may be the problem. That variable is assigned in ESP_GATTC_SEARCH_RES_EVT case in gattClientEventHandler(), but no log messages indicate that section of code is ever executed during connect(). The log indicates the crash happens right where the pointer to m_servicesMap is being passed back from getServices() (and getService(serviceUUID) not shown). Perhaps connect() does not populate m_servicesMap and the crash is a result of attempting to return a pointer to the uninitialized m_servicesMap variable?
This is really difficult to explain, though, since an altered BLEScan sketch connected to possibly hundreds of devices and enumerated all services and characteristics without a single crash before getting Polar H10 implying that m_servicesMap does get populated when connecting to a different device.
Below is the log for the call to connect() that seems to show that the ESP_GATTC_SEARCH_RES_EVT case in gattClientEventHandler() is not reached (but cases for ESP_GATTC_REG_EVT, ESP_GATTC_CONNECT_EVT and ESP_GATTC_OPEN_EVT are).
I switched to the espressif/arduino-esp library and it works. Setting the board to "Heltec WiFi LoRa 32(V3) / Wireless shell(V3) / Wireless stick lite (V3)" will allow to build and download.
While the BLE is working perfectly, none of the libraries for either LoRa or the OLED will work with the different board using the espressif/arduino-esp library. I need to get the LoRa radio working. That appears to be fine in the Heltec library.
I believe the quickest solution would be to update the BLE library in Heltec library to the newest from espressif/arduino-esp. (Might as well do the whole system.) I know I would certainly appreciate it.
I am trying to pair a Heltec Wireless Stick (V3) to a Polar H10 Heart Rate Monitor and get a crash when calling
getServices()
. This happens on the exampleBLEScan
andBLEClient
examples without any alteration (save the Service UUID of0x180D
and Characteristic UUID of0x2A37
for theBLEClient
example).I did not have the heart rate monitor when I got the HelTec device, so I familiarized myself with the API by altering the
BLEScan
example to connect to every address it found togetServices()
from each device andgetCharacteristics()
from each service similar toBLEClient
. I ran it in many public places while figuring it out and probably connected to several hundred devices and it worked without a crash.When the Polar H10 became available, the program immediately crashed. This is a bit of a problem as that is the device I specifically need to use.
The complete serial log with
CORE_DEBUG_LEVEL
set toVERBOSE
from boot to reboot is included at the end of the post. TheBLEScan
I have been using is unchanged except for the service and characteristic UUIDs and a fewSerial.println()
calls used to isolate the crash. Nothing of substance is changed. Directly below is an excerpt fromBLEScan
where the service and characteristic UUIDs are set for the heart rate monitor.It is only possible to verify the
serviceUUID
is working as expected since the sketch does connect to the Polar H10 as soon as it is found, but does not get pastgetServices()
. TheserviceUUID
does not seem to be the problem, though.It appears the call to
connect()
completes, but the next call togetServices()
causes the crash. Below is the verbose output fromBLEScan
during the call togetServices()
:I tried
getService(UUID)
but got the same crash. The code forgetService(UUID)
is very basic and returns an element ofm_servicesMap
suggesting that may be the problem. That variable is assigned inESP_GATTC_SEARCH_RES_EVT
case ingattClientEventHandler()
, but no log messages indicate that section of code is ever executed duringconnect()
. The log indicates the crash happens right where the pointer tom_servicesMap
is being passed back fromgetServices()
(andgetService(serviceUUID)
not shown). Perhapsconnect()
does not populatem_servicesMap
and the crash is a result of attempting to return a pointer to the uninitializedm_servicesMap
variable?This is really difficult to explain, though, since an altered
BLEScan
sketch connected to possibly hundreds of devices and enumerated all services and characteristics without a single crash before getting Polar H10 implying thatm_servicesMap
does get populated when connecting to a different device.Below is the log for the call to
connect()
that seems to show that theESP_GATTC_SEARCH_RES_EVT
case ingattClientEventHandler()
is not reached (but cases forESP_GATTC_REG_EVT
,ESP_GATTC_CONNECT_EVT
andESP_GATTC_OPEN_EVT
are).Any help with this would be greatly appreciated. I have some pressure to get these devices connected and working and this bug is far beyond me.
Thank you in advance for any assistance you can provide.
Below is the complete verbose log from start through crash:
The text was updated successfully, but these errors were encountered: