My multiple BLE client connection example rarely succeeds

[PaulELong]

I'm trying to connect my ESP32 WROOM to two BLE devices, an HM10 and HM18. Occasionally it works, but most of the time it fails in one of two ways. 1. It gets a disconnect event "gattClientEventHandler: disconnect event, reason: 62, connId: 0, my connId: 255, my IF: 4, gattc_if: 4". Or 2. it gets a "Guru Meditation Error: Core 0 panic'ed (Interrupt wdt timeout on CPU0)".

I have tried to enabled logging, taken Bluetooth sniffer traces, and and tried different variations of the code which sometimes changes which result I see more, but in all cases I would estimate it works 25% of the time. Once it's connected, it seem to stay connected, and once instance I let it stay connected all night.

I can supply code, debug traces, and sniff traces. Could somebody help me troubleshoot this behavior?

Thanks, Paul

[PaulELong]

Here's my code. I'm leveraging the BLE wrapper created by nkolban.

Code: [Select all] [Expand/Collapse]

1. /**
2.  * Create a sample BLE client that connects to a BLE server and then retrieves the current
3.  * characteristic value.  It will then periodically update the value of the characteristic on the
4.  * remote server with the current time since boot.
5.  */
6. #include <esp_log.h>
7. #include <string>
8. #include <iostream>
9. #include <sstream>
10. #include <sys/time.h>
11. #include "BLEDevice.h"
12.  
13. #include "BLEAdvertisedDevice.h"
14. #include "BLEClient.h"
15. #include "BLEScan.h"
16. #include "BLEUtils.h"
17. #include "Task.h"
18.  
19. #include "sdkconfig.h"
20.  
21. static const char* CTL_NAME = "DSD TECH";
22. static const char* HARM_NAME = "HarmCtl";
23.  
24. #define SERVICE_UUID        "0000FFE0-0000-1000-8000-00805F9B34FB"
25. #define CHARACTERISTIC_UUID "0000FFE1-0000-1000-8000-00805F9B34FB"
26. #define DESCRIPTOR_UUID     "00002902-0000-1000-8000-00805F9B34FB"
27.  
28. static BLEUUID      serviceUUID(SERVICE_UUID);
29. static BLEUUID      charUUID(CHARACTERISTIC_UUID);
30.  
31. bool finishedScanning = false;
32. bool CtlCompletedConn = false;
33. bool HarmCompletedConn = false;
34.  
35. static void notifyCallback(
36.                             BLERemoteCharacteristic* pBLERemoteCharacteristic,
37.                             uint8_t* pData,
38.                             size_t length,
39.                             bool isNotify)
40. {
41.     char arr[32];
42.  
43.     for(int i = 0; i < length && i < 32; i++)
44.     {
45.         arr[i] = pData[i];
46.     }
47.     arr[length] = '\0';
48.  
49.     printf("%s (%d)\n", arr, length);    
50. }
51.  
52. /**
53.  * Become a BLE client to a remote BLE server.  We are passed in the address of the BLE server
54.  * as the input parameter when the task is created.
55.  */
56. class MyClient
57. {
58. public:
59.     bool CompletedConn = false;
60.     bool ConnSuccess = false;
61.     std::string deviceName;
62.  
63.     MyClient(std::string s, BLEAddress* data)
64.     {
65.         deviceName = s;
66.         pAddress = new BLEAddress(*data->getNative());
67.     }
68.  
69.     ~MyClient()
70.     {
71.         pClient->disconnect();
72.  
73.         Log( "%s clean up\n", deviceName.c_str());
74.     }
75.  
76.     bool createClient()
77.     {
78.         try
79.         {
80.             //esp_ble_gap_set_prefer_conn_params(*(pAddress->getNative()), 8, 20, 0, 600);
81.             Log("Creating client connection\n");
82.             pClient = BLEDevice::createClient();
83.             Log("client object created\n");
84.  
85.             // esp_ble_gap_set_prefer_conn_params(*(pAddress->getNative()), 8, 20, 0, 6000);
86.             pClient->connect(*pAddress);
87.             // esp_ble_gap_set_prefer_conn_params(*(pAddress->getNative()), 8, 20, 0, 6000);
88.             Log("Client is Connected\n");
89.            
90.             // Obtain a reference to the service we are after in the remote BLE server.
91.             pRemoteService = pClient->getService(serviceUUID);
92.             if (pRemoteService == nullptr)
93.             {
94.                 Log("Failed to find our service UUID: %s\n", serviceUUID.toString().c_str());
95.                 ConnSuccess = false;
96.                 CompletedConn = true;
97.                 return ConnSuccess;
98.             }
99.             Log("Service retrieved\n");
100.  
101.             // Obtain a reference to the characteristic in the service of the remote BLE server.
102.             pRemoteCharacteristic = pRemoteService->getCharacteristic(charUUID);
103.             if (pRemoteCharacteristic == nullptr) {
104.                 Log("Failed to find our characteristic UUID: %s\n", charUUID.toString().c_str());
105.                 ConnSuccess = false;
106.                 CompletedConn = true;
107.                 return ConnSuccess;
108.             }
109.             Log("Remote characteristic created\n");
110.  
111.             if(pRemoteCharacteristic->canNotify())
112.                 pRemoteCharacteristic->registerForNotify(notifyCallback);
113.             Log("Char Notify created\n");
114.  
115.             ConnSuccess = true;
116.             CompletedConn = true;
117.         }
118.         catch(...)
119.         {
120.             ConnSuccess = false;
121.             CompletedConn = true;
122.             Log("!!! Exception while starting client connection\n");
123.         }
124.  
125.         return ConnSuccess;
126.     }
127.  
128.     void Send(std::string s)
129.     {
130.         if(pRemoteCharacteristic != nullptr)
131.         {
132.             pRemoteCharacteristic->writeValue(s.c_str());
133.         }
134.         else
135.         {
136.             Log("Error sending value");
137.         }
138.     }
139.  
140.     bool isConnected()
141.     {
142.         return pClient->isConnected();
143.     }
144.  
145. private:
146.     void Log(const char * format, ...)
147.     {
148.         va_list argptr;
149.         printf("%s: ", deviceName.c_str());
150.  
151.         va_start(argptr, format);
152.         vprintf(format, argptr);
153.         va_end(argptr);
154.     }
155.  
156.     BLERemoteCharacteristic* pRemoteCharacteristic = nullptr;
157.     BLERemoteService* pRemoteService = nullptr;
158.     BLEClient*  pClient = nullptr;
159.     BLEAddress* pAddress;
160. }; // MyClient
161.  
162. MyClient* pCtlClient;
163. MyClient* pHarmClient;
164.  
165. /**
166.  * Scan for BLE servers and find the first one that advertises the service we are looking for.
167.  */
168. class MyAdvertisedDeviceCallbacks: public BLEAdvertisedDeviceCallbacks
169. {
170.     bool foundBoth = false;
171.  
172.     void logprint(char *, ...)
173.     {
174.  
175.     }
176.     /**
177.      * Called for each advertising BLE server.
178.      */
179.     void onResult(BLEAdvertisedDevice advertisedDevice)
180.     {
181.         if (advertisedDevice.haveServiceUUID() && advertisedDevice.isAdvertisingService(serviceUUID))
182.         {
183.             std::string devName = advertisedDevice.getName();
184.             if(devName == CTL_NAME || devName == HARM_NAME)
185.             {
186.            
187.                 printf("Found %s!  address: %s\n", devName.c_str(), advertisedDevice.getAddress().toString().c_str());
188.        
189.                 if(devName == CTL_NAME)
190.                 {
191.                     pCtlClient = new MyClient(devName, new BLEAddress(*advertisedDevice.getAddress().getNative()));
192.                 }
193.                 else
194.                 {
195.                     pHarmClient = new MyClient(devName, new BLEAddress(*advertisedDevice.getAddress().getNative()));
196.                 }
197.  
198.                 if(foundBoth)
199.                 {
200.                     advertisedDevice.getScan()->stop();
201.                     finishedScanning = true;
202.                 }
203.  
204.                 foundBoth = true;
205.             }
206.         } // Found our server
207.     } // onResult
208. }; // MyAdvertisedDeviceCallbacks
209.  
210. /**
211.  * Perform the work of a sample BLE client.
212.  */
213. void SampleClient(void)
214. {
215.     printf("Scanning sample starting\n");
216.     BLEDevice::init("HarmCentral");
217.  
218.     BLEScan *pBLEScan = BLEDevice::getScan();
219.     pBLEScan->setAdvertisedDeviceCallbacks(new MyAdvertisedDeviceCallbacks());
220.     pBLEScan->setActiveScan(true);
221.     pBLEScan->start(15);
222.  
223.     printf("Waiting for discovery to complete: ");
224.     while(!finishedScanning)
225.     {
226.         FreeRTOS::sleep(500);
227.         printf(".");
228.     }
229.     printf("\n");
230.  
231.     if(pCtlClient->createClient() && pHarmClient->createClient())
232.     {
233.         while(pHarmClient->isConnected() && pCtlClient->isConnected())
234.         {
235.             printf("Running start...\n");
236.             //pHarmClient->Send("Hi client");
237.             //pCtlClient->Send("Hi controller");
238.             FreeRTOS::sleep(5000);
239.             printf("Running end...\n");
240.         }
241.  
242.         printf("Lost connection %s\n", pHarmClient->isConnected() ? "Controller" : "Harmonizer");
243.     }
244.     else
245.     {
246.         printf("HarmCtl = %d  Ctl = %d\n", pHarmClient->ConnSuccess, pCtlClient->ConnSuccess);
247.     }  
248.  
249.     delete pCtlClient;
250.     delete pHarmClient;
251.  
252. } // SampleClient
253.  
254. extern "C" void app_main()
255. {
256.     SampleClient();
257.     printf("================ DONE =================\n");
258.     esp_restart();
259. } // app_main
260.  

GeSHi © Codebox Plus Extension

[genedyne]

You appear to be using Neil Kolban's ESP32-snippets (you should at least mention this - it's NOT plain esp-idf code).

There is a BLE multi-connect example that might help give you some ideas: look in './esp-idf/examples/bluetooth/bluedroid/ble/gattc_multi_connect/main/gattc_multi_connect.c', and look specifically for ESP_GATTC_DISCONNECT_EVT

I'd be particularly suspicious of 'disconnect events' being properly associated with the correct device instantiation in the esp32-snippet code. I've not done multi-device connections myself, but I have some familiarity with the BLE code in question.

[PaulELong]

I posted the code, but for some reason it didn't show up on the forum. I've now changed to use the gattc_multi_connect and modified it for two devices. I changed this line "if (conn_device_a && conn_device_b /*&& conn_device_c*/ && !stop_scan_done){" While it works more consistently, I still crashes with the same stack, which I've now included below. What could be the problem?

Code: Select all

I (6571) GATTC_MULTIPLE_DEMO: Searched device DSD TECH
I (6581) GATTC_MULTIPLE_DEMO: Stop scan successfully
Guru Meditation Error: Core  0 panic'ed (Interrupt wdt timeout on CPU0)
Core 0 register dump:
PC      : 0x4008722d  PS      : 0x00060634  A0      : 0x8008a0b1  A1      : 0x3ffbe240  
0x4008722d: r_ea_elt_insert at ??:?

A2      : 0x3ffb32c8  A3      : 0x00000000  A4      : 0x00000000  A5      : 0x00000000  
A6      : 0x3ffb80ec  A7      : 0x3ffb3224  A8      : 0x40014e9c  A9      : 0x3ffbe220  
A10     : 0x3ffb32c8  A11     : 0x3ffb3224  A12     : 0x000004e2  A13     : 0x00000000  
A14     : 0x00002385  A15     : 0x04000000  SAR     : 0x00000019  EXCCAUSE: 0x00000005  
EXCVADDR: 0x00000000  LBEG    : 0x00000000  LEND    : 0x00000000  LCOUNT  : 0x00000000
Core 0 was running in ISR context:
EPC1    : 0x4008fd7f  EPC2    : 0x00000000  EPC3    : 0x00000000  EPC4    : 0x4008722d
0x4008fd7f: portENTER_CRITICAL_NESTED at E:/users/Paul/Documents/src/esp-idf/components/freertos/include/freertos/portmacro.h:328
 (inlined by) xPortInIsrContext at E:/users/Paul/Documents/src/esp-idf/components/freertos/port.c:338

0x4008722d: r_ea_elt_insert at ??:?


ELF file SHA256: c6a3d7f514379c20aef686e76ec9cb601f82f33a9d5aa7256d011ef76eca2e67

Backtrace: 0x4008722a:0x3ffbe240 0x4008a0ae:0x3ffbe270 0x40089e49:0x3ffbe290 0x4008af11:0x3ffbe2b0 0x4008bcfb:0x3ffbe2d0 0x40082acd:0x3ffbe2f0 0x4000bfed:0x3ffbd940 |<-CORRUPTED
0x4008722a: r_ea_elt_insert at ??:?

0x4008a0ae: r_lld_evt_end at ??:?

0x40089e49: r_lld_evt_end_isr at ??:?

0x4008af11: r_rwble_isr at ??:?

0x4008bcfb: r_rwbtdm_isr_wrapper at intc.c:?

0x40082acd: _xt_lowint1 at E:/users/Paul/Documents/src/esp-idf/components/freertos/xtensa_vectors.S:1153


Core 1 register dump:
PC      : 0x40153d96  PS      : 0x00060634  A0      : 0x800d3c1d  A1      : 0x3ffcbe30
0x40153d96: esp_pm_impl_waiti at E:/users/Paul/Documents/src/esp-idf/components/esp32/pm_esp32.c:486

A2      : 0x00000000  A3      : 0x00000000  A4      : 0x00000001  A5      : 0x80000001  
A6      : 0x00000003  A7      : 0x00060023  A8      : 0x800d3646  A9      : 0x3ffcbe00
A10     : 0x00000000  A11     : 0x00060623  A12     : 0x00060620  A13     : 0x00000001
A14     : 0x00060620  A15     : 0x3ffcd250  SAR     : 0x00000000  EXCCAUSE: 0x00000005  
EXCVADDR: 0x00000000  LBEG    : 0x00000000  LEND    : 0x00000000  LCOUNT  : 0x00000000

ELF file SHA256: c6a3d7f514379c20aef686e76ec9cb601f82f33a9d5aa7256d011ef76eca2e67

Backtrace: 0x40153d93:0x3ffcbe30 0x400d3c1a:0x3ffcbe50 0x4009173d:0x3ffcbe70 0x4008fc85:0x3ffcbe90
0x40153d93: esp_pm_impl_waiti at E:/users/Paul/Documents/src/esp-idf/components/esp32/pm_esp32.c:484

0x400d3c1a: esp_vApplicationIdleHook at E:/users/Paul/Documents/src/esp-idf/components/esp_common/src/freertos_hooks.c:63

0x4009173d: prvIdleTask at E:/users/Paul/Documents/src/esp-idf/components/freertos/tasks.c:3382 (discriminator 1)

0x4008fc85: vPortTaskWrapper at E:/users/Paul/Documents/src/esp-idf/components/freertos/port.c:143


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:2
load:0x3fff0018,len:4
load:0x3fff001c,len:6948
load:0x40078000,len:14344
load:0x40080400,len:4296
entry 0x400806e4

[PaulELong]

Since the problem above doesn't necessarily block me I'm moving on. I would like to understand if this is a bug in the example somewhere else, but from a prototype point of view, I can continue with my testing. But now I have new problem with the multi-connect example. I see that garbage is printed out for each connection. I think it must be related to the code in ESP_GATT_C_WRITE_DESCR_EVT. When I read the tutorial, there seems to be an inconsistency.

In the tutorial, it shows the ESP_GATTC_NOTIFY_EVT which some code to esp_bel_gattc_write_char, but that's not what the real code shows. Further more and possibly related, I don't see an explanation for the esp_ble_gattc_write_char in the ESP_GATTC_WRITE_DESC_EVET, which I think is producing the garbage.

What I found out is that if I remove the code that produces the garbage printout, then intermittently one of the two clients can't send notifications, which means I type in the serial program and the ESP_GATTC_NOTIFY_EVT isn't called.

Can somebody tell me if the tutorial is wrong and provide details as to why the write_char call might be required?

Thanks -Paul

[chegewara]

Hi
i see here few potential problems. Here for example you are assuming that client is connected, but in real you just find device with this name and create instance of this class client:

Code: Select all

            if(devName == CTL_NAME || devName == HARM_NAME)
            {
           
                printf("Found %s!  address: %s\n", devName.c_str(), advertisedDevice.getAddress().toString().c_str());
       
                if(devName == CTL_NAME)
                {
                    pCtlClient = new MyClient(devName, new BLEAddress(*advertisedDevice.getAddress().getNative()));
                }
                else
                {
                    pHarmClient = new MyClient(devName, new BLEAddress(*advertisedDevice.getAddress().getNative()));
                }
 
                if(foundBoth)
                {
                    advertisedDevice.getScan()->stop();
                    finishedScanning = true;
                }
 
                foundBoth = true;
               

Remember that device can be disconnected in any time, right after connection is open but before connection is settled.


Also backtrace you posted is well known issue with bluetooth on esp32, many times reported on github even if some may say its fixed in esp-idf master. Still its not patched in arduino.

[PaulELong]

I've switched to using the gattc_multi_connect.c example per @genedyne's advice. And that example is where the exception occurs. Glad to hear that it's been addressed. If you know of a specific patch, I would appreciate it, but I can also look and try to figure it out.

But I also run into my originally stated disconnect problem with that provided example. So I think there is still bug or missing error state handling lurking in the example provided with esp-idf.

What makes it more frustrating though, is the example doesn't match the tutorial explanation. Besides the problem I mention above, the flow chart at the top indicates that it scans for all devices first, and then connects to each, one at a time. But the example instead starts a connection when the first scan result is found. In ESP_GAP_SEARCH_INQ_RES_EVT, when a result is found it stops scanning, and calls esp_ble_gattc_open. To restart the scan, it uses the ESP_GATTC_WRITE_CHAR_EVT event, which maybe answers my questions above as to why it writes some data. But this seems a very strange way to trigger the next scan. Besides sending unwanted characters, it means trying you have to add some code to determine whether to do another start scan when you send data.

The good news is that the provided example works %90 of the time. I do see the exception and the disconnect, but it's more rare. The exception is easy to work with because it reboots and tries again. The disconnect stops the process completely, so I'm guessing I'll have to dive further into that problem at some point.

My next step is to rewrite the example so that it scans all devices first, like the flow chart, and then make the client connect a class, so I can share the event code rather than having 3 static profile event handlers. I'm close to that goal and I can use the current gattc_multi_connect.c example as a guide.

So my current open issues are:
1. Why is the example inconsistent? What is the best way to get these addressed? Should I follow up on github and report a problem there?
2. Why do the disconnects occur in the provided example? Perhaps, like you say disconnects can happen at any time. So perhaps I just need to handle the disconnect and try to reconnect. But given this is a normal use case, perhaps the example could also be reworked to handle these connects and deal with the gracefully?

Thanks -Paul

[PaulELong]

More info about #2, the messages I see with gattc_multi example are as follows.

W (8331) BT_APPL: bta_gattc_conn_cback() - cif=3 connected=0 conn_id=3 reason=0x0008
W (8331) BT_APPL: bta_gattc_conn_cback() - cif=4 connected=0 conn_id=4 reason=0x0008
W (8341) BT_APPL: bta_gattc_conn_cback() - cif=5 connected=0 conn_id=5 reason=0x0008
W (8351) BT_APPL: bta_gattc_conn_cback() - cif=6 connected=0 conn_id=6 reason=0x0008

Maybe this normal activity, but the first thing I don't understand is what are if=3 and cif=6? The other two I can attribute to my registered calls as I print them out when I enter esp_gattc_cb. Where do the other's come from?

-Paul

[PaulELong]

I still have problems. I can make the gattc_multi_connect.c reproduce my problems more frequently if I comment out the following lines:

Code: Select all

            
            //esp_log_buffer_hex(GATTC_TAG, scan_result->scan_rst.bda, 6);
            //ESP_LOGI(GATTC_TAG, "Searched Adv Data Len %d, Scan Response Len %d", scan_result->scan_rst.adv_data_len, scan_result->scan_rst.scan_rsp_len);
            adv_name = esp_ble_resolve_adv_data(scan_result->scan_rst.ble_adv,
                                                ESP_BLE_AD_TYPE_NAME_CMPL, &adv_name_len);
            //ESP_LOGI(GATTC_TAG, "Searched Device Name Len %d", adv_name_len);
            //esp_log_buffer_char(GATTC_TAG, adv_name, adv_name_len);
            //ESP_LOGI(GATTC_TAG, "\n");

This version fails more often than not. Since the statements I commented are just printing, I feel that means it's a threading issue. The failures are the same as above. Either it reboots with the exception above, or it gets a disconnect (I can't figure out where the disconnect comes from), then tries again until it fails completely leaving one of the two devices disconnected, or it does occasionally work and connects to both devices.

Concerning the stack trace when it resets, I looked on the github site and and found the issues you mention, but I don't see a resolution. I have updated my esp-idf branch to the latest, I'm not using arduino.

Is there anybody who can help me track down the issue with the example?

Thanks -Paul

[PaulELong]

I'll continue to post progress of my research in case it reveals a clue or helps somebody in the future.

I've tracked the disconnect logging back to this stack trace. This is processing a queue, which I think is created for each connection. There is an Event = 5 which is disconnect,

Code: Select all

0x4008dcb5: abort at E:/users/Paul/Documents/src/esp-idf/components/esp32/panic.c:174

0x40132efb: __assert_func at /builds/idf/crosstool-NG/.build/HOST-i686-w64-mingw32/xtensa-esp32-elf/src/newlib/newlib/libc/stdlib/assert.c:62 (discriminator 8)

0x400ff104: l2cu_release_ccb at E:/users/Paul/Documents/src/esp-idf/components/bt/host/bluedroid/stack/l2cap/l2c_utils.c:1633 (discriminator 3)

0x400ff9a9: l2cu_process_fixed_disc_cback at E:/users/Paul/Documents/src/esp-idf/components/bt/host/bluedroid/stack/l2cap/l2c_utils.c:2869

0x400ffab0: l2cu_release_lcb at E:/users/Paul/Documents/src/esp-idf/components/bt/host/bluedroid/stack/l2cap/l2c_utils.c:185

0x400fbc85: l2c_link_hci_disc_comp at E:/users/Paul/Documents/src/esp-idf/components/bt/host/bluedroid/stack/l2cap/l2c_link.c:461

0x400e8d9a: btu_hcif_disconnection_comp_evt at E:/users/Paul/Documents/src/esp-idf/components/bt/host/bluedroid/stack/btu/btu_hcif.c:630

											
0x400e9997: btu_hcif_process_event at E:/users/Paul/Documents/src/esp-idf/components/bt/host/bluedroid/stack/btu/btu_hcif.c:194

0x400e9e03: btu_hci_msg_process at E:/users/Paul/Documents/src/esp-idf/components/bt/host/bluedroid/stack/btu/btu_task.c:160

0x401072a5: osi_thread_run at E:/users/Paul/Documents/src/esp-idf/components/bt/common/osi/thread.c:68

0x4008ff5d: vPortTaskWrapper at E:/users/Paul/Documents/src/esp-idf/components/freertos/port.c:143

So now I traced the back to who entered that into the queue and added another assert in the code for when it matched the 6 long data of 4 5 4 0 0 0. This gives me this stack:

Code: Select all

PAULLO-osi_thread_post:  1000, offset=1, data[33]= 4 3E 1F A 0 0 0 0 0 20 15 8E 2 E2 90 0 0 0 0 0
D (1901) BT_L2CAP: l2cble_scanner_conn_comp: HANDLE=0 addr_type=0 conn_interval=12 slave_latency=0 supervision_tout=600
PAULLO-osi_thread_post:  1000, offset=1, data[6]= 4 5 4 0 0 0
assertion "false" failed: file "E:/users/Paul/Documents/src/esp-idf/components/bt/common/osi/thread.c", line 259, function: osi_thread_post
abort() was called at PC 0x401334bb on core 0
0x401334bb: __assert_func at /builds/idf/crosstool-NG/.build/HOST-i686-w64-mingw32/xtensa-esp32-elf/src/newlib/newlib/libc/stdlib/assert.c:62 (discriminator 8)


ELF file SHA256: 69e2c11e425bd1fa4fbabcc93f60f19b9ad00b9f47dac74220a8d7e912edb1d1

Backtrace: 0x4008d877:0x3ffcfe00 0x4008dcb5:0x3ffcfe20 0x401334bb:0x3ffcfe40 0x40107a78:0x3ffcfe70 0x400e9f75:0x3ffcfe90 0x40113a15:0x3ffcfeb0 0x40113eb2:0x3ffcfed0 0x401259cf:0x3ffcfef0 0x401259e2:0x3ffcff20 0x40106c1b:0x3ffcff40 0x401256e0:0x3ffcff60 0x401077cd:0x3ffcff80 0x4008ff5d:0x3ffcffa0
0x4008d877: invoke_abort at E:/users/Paul/Documents/src/esp-idf/components/esp32/panic.c:157

0x4008dcb5: abort at E:/users/Paul/Documents/src/esp-idf/components/esp32/panic.c:174

0x401334bb: __assert_func at /builds/idf/crosstool-NG/.build/HOST-i686-w64-mingw32/xtensa-esp32-elf/src/newlib/newlib/libc/stdlib/assert.c:62 (discriminator 8)

0x40107a78: osi_thread_post at E:/users/Paul/Documents/src/esp-idf/components/bt/common/osi/thread.c:259

0x400e9f75: btu_task_post at E:/users/Paul/Documents/src/esp-idf/components/bt/host/bluedroid/stack/btu/btu_task.c:229

0x40113a15: dispatch_reassembled at E:/users/Paul/Documents/src/esp-idf/components/bt/host/bluedroid/hci/hci_layer.c:539

0x40113eb2: hal_says_packet_ready at E:/users/Paul/Documents/src/esp-idf/components/bt/host/bluedroid/hci/hci_layer.c:454

0x401259cf: hci_hal_h4_hdl_rx_packet at E:/users/Paul/Documents/src/esp-idf/components/bt/host/bluedroid/hci/hci_hal_h4.c:310

0x401259e2: event_uart_has_bytes at E:/users/Paul/Documents/src/esp-idf/components/bt/host/bluedroid/hci/hci_hal_h4.c:318

0x40106c1b: fixed_queue_process at E:/users/Paul/Documents/src/esp-idf/components/bt/common/osi/fixed_queue.c:254

0x401256e0: hci_hal_h4_rx_handler at E:/users/Paul/Documents/src/esp-idf/components/bt/host/bluedroid/hci/hci_hal_h4.c:170

0x401077cd: osi_thread_run at E:/users/Paul/Documents/src/esp-idf/components/bt/common/osi/thread.c:68

0x4008ff5d: vPortTaskWrapper at E:/users/Paul/Documents/src/esp-idf/components/freertos/port.c:143

And again we taking things out of a queue. It process the queue and calls hci_hal_h4_rx_handler. So now again I track back who put this packet in the queue and now I'm add this stack trace. This one is a little wierd because it contains vhci_send at ??:? and r_eif_send at ??:?, rather than pointers to the esp-idf/components.

Code: Select all

I (7652) GATTC_MULTIPLE_DEMO: Scan start success
PaulLo: host_recv_pkt_cb 4 5 4 0 0 0 8 
assertion "false" failed: file "E:/users/Paul/Documents/src/esp-idf/components/bt/host/bluedroid/hci/hci_hal_h4.c", line 359, function: host_recv_pkt_cb
abort() was called at PC 0x401339a3 on core 0
0x401339a3: __assert_func at /builds/idf/crosstool-NG/.build/HOST-i686-w64-mingw32/xtensa-esp32-elf/src/newlib/newlib/libc/stdlib/assert.c:62 (discriminator 8)


ELF file SHA256: c13fa189ada715410f809411df11059d6899177f617a9e0553ede231115a98b2

Backtrace: 0x4008d877:0x3ffb5c70 0x4008dcb5:0x3ffb5c90 0x401339a3:0x3ffb5cb0 0x40125c13:0x3ffb5ce0 0x401558ee:0x3ffb5d00 0x401499ae:0x3ffb5d20 0x4001791d:0x3ffb5d40 |<-CORRUPTED
0x4008d877: invoke_abort at E:/users/Paul/Documents/src/esp-idf/components/esp32/panic.c:157

0x4008dcb5: abort at E:/users/Paul/Documents/src/esp-idf/components/esp32/panic.c:174

0x401339a3: __assert_func at /builds/idf/crosstool-NG/.build/HOST-i686-w64-mingw32/xtensa-esp32-elf/src/newlib/newlib/libc/stdlib/assert.c:62 (discriminator 8)

0x40125c13: host_recv_pkt_cb at E:/users/Paul/Documents/src/esp-idf/components/bt/host/bluedroid/hci/hci_hal_h4.c:359

0x401558ee: vhci_send at ??:?

0x401499ae: r_eif_send at ??:?

If this tickles anybody's recollection, please chime in.