FreeRTOS: Safe to block BLE task created in nrf_sdh_freertos.c?

[droberson]

Background:

• Custom boards
• SDK 15.2.0
• SoftDevice: s140_nrf52_6.1.0

Hello,

We recently updated our project to use 2M PHY instead of the default 1M PHY. Our device implements over-the-air (OTA) firmware updates and writes the received firmware image to the second half of the nRF52840 internal flash. Increasing the PHY to 2M not only increased the BLE throughput, it also increased the flash operation times, especially page erase. I am aware that flash operation times depend on the amount of BLE activity so I am not surprised by this result. Unfortunately, the flash operations are now a bottleneck and I either need to slow down the OTA file transfer or block the BLE task on a RX queue until flash operations complete.

Question: Is it safe to block the BLE task created in nrf_sdh_freertos.c without losing any RX packets? I assume this is not a good idea, but wanted to double check since I couldn't find any answers online.

Thanks!

Derek

[droberson]

Hey Torbjørn,

I have seen page erase take upwards of 150+ msec roughly, so I would be blocking for up to ~200 msec at a time. The alternative is to have a very large application RX queue but I am trying to avoid that if possible.

Regarding:

"At some point data throughput will suffer, as the SoftDevice will start NAKing new data once the internal buffers fill up, but it shouldn't affect the reliability of the connection or the stack"

This is the behavior I was hoping for as opposed to the SoftDevice / BLE task dropping packets. NAK'ing packets should be fine for my purposes for now so long as it only decreases throughput and doesn't result in dropped packets.

Thanks!