STM32WB BLE performance with sequencer, android

[FwPro]

We're working with the STM32WB developer board and we've encountered "slow BLE writes" with android.

While trying to make our BLE writes faster, we determined that if we remove the "GATT_NOTIFY_WRITE_REQ_AND_WAIT_FOR_APPL_RESP | GATT_NOTIFY_READ_REQ_AND_WAIT_FOR_APPL_RESP" event flags-- when we add a service characteristic, the BLE write speeds increases from approximately 10KB to 120KB per second.

Can anyone provide any insight into the link between sequencer latencies and expected throughput? like, most importantly, I think: what sort of latencies stop Android from writing several packets during a connection interval because we really need to reenable those events to get at the incoming data.

Our EVT_BLUE_GATT_WRITE_PERMIT_REQ handler seems to be really simple; it's just memcpy plus some basic C data processing plus the code from STM's framework.

Perhaps we shouldn't be using the ST sequencer?

New Note Added:

Please note, we came across these community posts and they seem to indicate that the read and write events come with performance issues:

https://community.st.com/s/question/0D73W0000004aVD/detail?s1oid=00Db0000000YtG6&s1nid=0DB0X000000DYbd&emkind=chatterCommentNotification&s1uid=0050X000007vx8D&emtm=1598477671004&fromEmail=1&s1ext=0&t=1598539349121

https://community.st.com/s/question/0D53W00000Diwl2SAB/bleota-for-large-files-keeps-failing

Moreover, we haven't found any documentation-- yet, about how to ensure that these write events will let us reliably send data quickly. To the contrary, the community posts have led us to believe that-- since the communication core was losing data, read and write events were added to the API but there was also a performance hit.

Is this analysis correct?

If yes, can someone from ST help us manage our performance expectations?

Thanks,

-M

[Christophe Arnal]

Hello,

There is a limitation spotted in the two posts you listed where it is possible to lose data received from the remote if the background task hci_user_evt_proc() on CPU2 is not process often enough to read incoming data.

The way to workaround this is to add the property GATT_NOTIFY_WRITE_REQ_AND_WAIT_FOR_APPL_RESP to the characteristic that is written by the remote. This ensures the CPU2 is waiting an acknowledgment from the CPU1 that the packet has been processed. If the CPU1 is acknowledging slower the packets than the rate they are received on the CPU2 by the remote device, the BLE flow control is raised over the air. This requests the remote to keep sending the same packet until it has been acknowledged by the CPU2.

We made some data throughput measurement to check the overhead due to the property GATT_NOTIFY_WRITE_REQ_AND_WAIT_FOR_APPL_RESP that requires for each packet received the sending to CPU2 of the aci_gatt_write_resp() command from CPU1.

We did not see any impact on the performance.

In order to move forward on your test case, I would recommend to check how often you are processing hci_user_evt_proc() and how long it runs. I believe you are running your EVT_BLUE_GATT_WRITE_PERMIT_REQ handler from that context.

The sequencer does not add any latency but it is a bare metal implementation so the main property of a baremetal implementation is to run each background task until completion. If you have some other tasks running in the sequencer which can be running for a significant amount of time ( lets says several tens of ms), then this will delay the processing of hci_user_evt_proc() .

If your issue is coming from the rate hci_user_evt_proc() is called, there will several way to fix it :

• moving to an OS. This will help you stopping any running task to schedule hci_user_evt_proc().
• in a baremetal implementation, making sure any task does not hold the processor for too long so that other background tasks have some opportunity to run ( there will be some facilities with the Sequencer to help scheduling).

Anyway, everything starts with the study on how often is currently executed hci_user_evt_proc() in your application.

Regards

[vishalkeshavamurthy]

Hi @Christophe Arnal , could you please elaborate on this ? I am looking for documentation as to how to use the scheduler to ensure hci_user_evt_proc()  gets sufficient time. What facilities are you referring to? It would be wonderful if you can point me towards some working examples involving non trivial background tasks that run for a long time

• in a baremetal implementation, making sure any task does not hold the processor for too long so that other background tasks have some opportunity to run ( there will be some facilities with the Sequencer to help scheduling).