BLE stack gets stuck in assert during reapeted connect/disconnect tests

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
user_1516261
Level 2
Level 2

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

0 Likes
1 Solution

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.

View solution in original post

0 Likes
2 Replies
ShipingW_81
Moderator
Moderator
Moderator
500 replies posted 250 solutions authored 250 replies posted

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.

0 Likes

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.

0 Likes