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.