- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I have to PSoC6 devices that talk BLE with each other. One is acting in a purely peripheral role, while the other acts in both central and peripheral roles. I am running a robustness test of our product where the central device connects, stays connected for 2 s, disconnects, stays disconnected for 2 s and then connects again. After running this test for a couple of minutes, the central node gets into Cy_SysLib_Halt().
The stack trace reveals that the following assert is triggered in Cy_BLE_GetConnHandleByBdHandle():
if(cHandle.attId == CY_BLE_INVALID_CONN_HANDLE_VALUE)
{
/* HALT in debug mode */
CY_ASSERT(cHandle.attId != CY_BLE_INVALID_CONN_HANDLE_VALUE);
}
Stack trace:
Cy_SysLib_Halt() at cy_syslib.c:144 0x10061330
Cy_SysLib_AssertFailed() at cy_syslib.c:177 0x1006134c
Cy_BLE_GetConnHandleByBdHandle() at cy_ble_gap.h:968 0x10060076
Cy_BLE_EventHandler() at cy_ble_event_handler.c:598 0x10060076
CyBle_HciCb() at 0x100cb566
hci_transport_read_data() at 0x100cf8be
CyBle_StackTaskHandler() at 0x100c63d0
OS_scheduler() at 0x100c6a02
<---- my code calls Cy_BLE_ProcessEvents();
tEvParam in Cy_BLE_EventHandler() is as follows:
tEvParam cy_stc_ble_gap_connected_param_t * 0x80211e8 <ucHeap+1944>
status uint8_t 12 '\f'
bdHandle uint8_t 0 '\0'
role uint8_t 0 '\0'
peerAddrType uint8_t 0 '\0'
peerAddr uint8_t [6] 0x8001952
peerAddr[0] uint8_t 12 '\f'
peerAddr[1] uint8_t 1 '\001'
peerAddr[2] uint8_t 13 '\r'
peerAddr[3] uint8_t 32 ' '
peerAddr[4] uint8_t 1 '\001'
peerAddr[5] uint8_t 15 '\017'
connIntv uint16_t 4
connLatency uint16_t 0
supervisionTO uint16_t 45945
masterClockAccuracy uint8_t 12 '\f'
tconnHandle cy_stc_ble_conn_handle_t {...}
bdHandle uint8_t 255 'ÿ'
attId uint8_t 255 'ÿ'
event cy_en_ble_event_t <optimized out>
evParam void * 0x80211e8 <ucHeap+1944>
I don't recognize peerAddr at all, I think it is garabge data
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think I know how this behaviour gets triggered. I had a flag in the advertisement which caused the central to iniate connect. I initated the connection from the callback when I received an advertisement with the flag set. I did not have advertisement filtering on and since I receive advertisement more faster than the time it takes to connect, this caused be to call Connect()-multiple times on the same address. After adding filtering, I have not seen this crash again.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
How often could this issue occur during your test? Is this a certain case after running the test for a couple of minutes?
It looks the device get a broken evParam as bdHandle is 0.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think I know how this behaviour gets triggered. I had a flag in the advertisement which caused the central to iniate connect. I initated the connection from the callback when I received an advertisement with the flag set. I did not have advertisement filtering on and since I receive advertisement more faster than the time it takes to connect, this caused be to call Connect()-multiple times on the same address. After adding filtering, I have not seen this crash again.