FreeRTOS: Safe to block BLE task created in nrf_sdh_freertos.c? (Part 2)

[droberson]

Background:

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

Please see previous post / case that was closed and cannot be reopened: https://devzone.nordicsemi.com/f/nordic-q-a/87470/freertos-safe-to-block-ble-task-created-in-nrf_sdh_freertos-c

Note: It would be nice to reopen old cases that turned out not to actually be solved. Is this possible? Perhaps allow a 10 day window or so to reopen them in scenarios such as mine. Or at least the ability to link this post to that one. Otherwise this is just an unnecessary duplicate post that someone may not find.

Hello,

I was previously told that it was safe to block the BLE (SoftDevice) task created in nrf_sdh_freertos.c while waiting for internal flash operations to complete (See post linked above). Turns out, this isn't true. In my case, FDS (Flash Data Storage) events are received through the SoftDevice task. I was performing an OTA firmware update and blocking the SoftDevice task on a BLE message RX queue until my FDS events completed because page erase takes a long time (150+ msec). If the SoftDevice task is blocked, you never receive the FDS events and end up in a deadlock.

In summary, it looks like you can only block the SoftDevice task if what you are blocking on is not processed by the SoftDevice task itself. You also run the risk of delaying any other peripheral events that are also processed by the SoftDevice task which could have unforeseen systemic effects on your application. It looks like the only solution in my case is to artificially reduce BLE throughput since flash operations are a bottleneck, or have a really large BLE message RX queue.

Question 1: Are my findings and understanding correct?

Question 2: Is reducing BLE throughput or having a really large RX queue my only options?

Thanks,

Derek

[Susheel Nuguru]

Hi,

Ovrebekk who replied to your previous post has consulted me before replying to you. I missed to see your information clearly that you have a flash event dependency. Apologies for that.

The softdevice_task in the nrf_sdh_freertos.c is designed to pull all the SDH events in the system. This includes BLE/SOC/ANT events for system that use those events. So you are right, having no time limit wait on  flash event (which is a soc event) dependency on a suspended task that is the only source of such event is a deadlock.

You can try to split the stack events by splitting the softdevice tasks into

softdevice_ble_task -> calling nrf_sdh_ble_evts_poll in nrf_sdh_ble.c
softdevice_soc_task -> calling nrf_sdh_soc_evts_poll in nrf_sdh.soc.c

The nrf_sdh_ble_evts_poll and nrf_sdh_soc_evts_poll are not designed to work independently without using overall SDH module registration. So you might have to do some changes there.

I do not have any examples to show now, but seems like this would be a good non portal project for me to demonstrate when there is time. Unfortunately you need to split this yourself this time.

[droberson]

Hey Susheel,

Thanks for following up with Torbjørn (Ovrebekk) on this! What you describe sounds interesting but I would prefer not to change the SoftDevice task as it may introduce bugs. The simplest solution based on your feedback I believe for now is to artificially reduce BLE throughput or implement some ACK mechanism to pause packet transmission until x packets are received and processed. Similar to the following:

Sender: Send 20 packets and wait for ACK

Receiver: Process 20 packets and send ACK

Sender: Send 20 packets and wait for ACK

Receiver: Process 20 packets and send ACK

etc...

Thanks for the insight into potential mitigations!

Derek