RE: Reentrancy with SDK15.3

Randy Lee — Fri, 25 Oct 2024 14:05:26 GMT

that's exactly what I needed to know... thank you.

RE: Reentrancy with SDK15.3

Susheel Nuguru — Fri, 25 Oct 2024 13:17:59 GMT

[quote user=""]*) These are eventually being called by the soft device but I don't know in what context... Are these essentially ISR level calls being made from the SD so that they are preemptive (i,.e. if I'm in the callbacks too long I'm going to get overrun by another)?[/quote]

Yes, the callbacks triggered by the SoftDevice (e.g., ble_evt_handler) are indeed called from the SoftDevice's Interrupt Service Routine (ISR) context. The SoftDevice runs at a high interrupt priority level, so when it triggers an event (like BLE_GAP_EVT_ADV_REPORT), it is effectively running in an ISR. This means:

Preemption is enabled: The SoftDevice can interrupt lower-priority tasks, but other ISRs with a higher priority than the SoftDevice ISR (like other critical hardware interrupts) can still preempt the SoftDevice ISR.

Time sensitivity: If your handler takes too long to execute, you risk causing issues, such as missed BLE events or potential overrun situations. Hence, it's crucial to keep these callbacks short and efficient, deferring longer operations to a different context (like a FreeRTOS task).

[quote user=""]*) Can I use semaphores inside those callbacks so that I can hold off calls that are happening too often?[/quote]

FreeRTOS FromISR Functions: When interacting with FreeRTOS from an ISR, you need to use the special "FromISR" versions of functions. For example:

xSemaphoreGiveFromISR() instead of xSemaphoreGive()
xQueueSendFromISR() instead of xQueueSend()

Deferring Work to Tasks: A common pattern is to defer longer operations to a FreeRTOS task by using a semaphore or queue to signal the task from the ISR. This approach allows the ISR (callback) to quickly return, avoiding potential problems with reentrancy and keeping the SoftDevice responsive.

[quote user=""]*) Can these callbacks in fact be overlapped or does the SD itself wait till it all comes back to it before sending another one?[/quote]

The SoftDevice itself can queue multiple events escpecially when the events are triggered from the higher priority contexts within the softdevice, but does not call your event handler if a previous event is still being processed. In other words, the SoftDevice does not "re-enter" the same event callback. This means you don't have to worry about reentrancy within the same event type.

However, you can still run into issues if multiple different ISRs (or callbacks) try to access shared resources. For example, if you have a high-priority ISR that modifies data that another ISR (from the SoftDevice) also accesses, you need to ensure proper synchronization (e.g., with mutexes or critical sections).