BL702 BLE: assertion trap in binary library while intensive RX/TX

makc

Hello,

We tried to use BLE examples from bl_mcu_sdk/examples/ble/ to get BLE working on bl702 devices and we had to make some modifications in examples/ble projects to get examples alive. Modifications were related to device advertising name and BFBL_BLE_DISCOVER_ONGOING flag. After that we tried to achieve higher speed and we changed the logic of the examples. We made server and client sending packets as frequent as possible and reduced connection interval (both CONFIG_BT_PERIPHERAL_PREF_MIN/MAX_INT to 0x8, because according to our observations bl702 puts just one packet into connection interval). And now we've got an issue with an assertion from blecontroller library:

lld_evt_end:rx_desc_cnt(1) is less than evt->rx_cnt(2),assert!!!
, lld_evt_end
lld_evt_end:num of prog evt (0)!!!
, lld_evt_end
lld_evt_end:evt_mode(3), cur_rx_desc_cnt(1)
, lld_evt_end
ble_assert_param,return address 0x23025206
, ble_assert_param
ble_assert_param, param0=0x1, param1=0x2, file=D:/Paul/gitlab-bl_iot_sdk/bl_iot_sdk/components/network/ble/blecontroller/ip/bl

This assertion may occur after long time but if we start transmitting packets only after le_param_updated callback then the assertion is guaranteed to appear just after the callback.
Does anyone have an idea what does this assertion mean and how to avoid it ?

Our test example in the form of patch file for the bl_mcu_sdk-master repository could be downloaded here.

Alvin

Have reply to your question at https://bbs.bouffalolab.com/d/154-bl702-ble-maximum-packets-per-connection-interval

makc

Alvin,
I've tried almost the same example (adapted to my application) and I have the same issues with ble_assert_param at the client side. Moreover I've found, that there are unexpected large transfer delays (about 5 seconds) at the server side in send_frag, backtrace:

(gdb) thread 6
[Switching to thread 6 (Thread 6)]
#0  xQueueSemaphoreTake (xQueue=0x4202bb20, xTicksToWait=<optimized out>)
    at /home/makc/projects/ble-test/freertos/queue.c:1356
1356                        portYIELD_WITHIN_API();
=> 0x23005800 <xQueueSemaphoreTake+302>:        59 bf   j       0x23005796 <xQueueSemaphoreTake+196>
(gdb) bt
#0  xQueueSemaphoreTake (xQueue=0x4202bb20, xTicksToWait=<optimized out>)
    at /home/makc/projects/ble-test/freertos/queue.c:1356
#1  0x2300604a in send_frag (conn=0x4201abe4 <conns>, buf=0x4201abe4 <conns>, 
    flags=flags@entry=0 '\000', always_consume=always_consume@entry=false)
    at /home/makc/projects/ble-test/ble/ble_stack/host/conn.c:1424
#2  0x2300716e in send_buf (conn=conn@entry=0x4201abe4 <conns>, buf=buf@entry=0x4202bfd0)
    at /home/makc/projects/ble-test/ble/ble_stack/host/conn.c:1530
#3  0x230071c4 in bt_conn_process_tx (conn=0x4201abe4 <conns>)
    at /home/makc/projects/ble-test/ble/ble_stack/host/conn.c:1659
#4  0x2300bb2e in process_events (ev=0x42016420 <events+40>, ev@entry=0x420163f8 <events>, count=1, 
    count@entry=3) at /home/makc/projects/ble-test/ble/ble_stack/host/hci_core.c:4490
#5  0x2300bb52 in hci_tx_thread (p1=<optimized out>)
    at /home/makc/projects/ble-test/ble/ble_stack/host/hci_core.c:4583
#6  0x00000000 in ?? ()

I seems, that some low-level events are missing or incorrectly handled while doing intensive TX and this leads to the TX queue blocking. Described TX locking is relatively rare case. The test firmware could successfully performing for several hours, but in some undefined condition server stucks at the TX queue. And this TX stuck occurs many times at past week.