BLE Radio notification provide incorrect radio active state value

[hjz]

Our system is currently using the ble_radio_notificaiton components provided by nrf5_sdk version 16, and we have noticed that occasionally after ble pairing + bonding operations, the radio active value would be flipped, getting the radio_active == false then radio_active == true. And the duration between the 2 events are close to the NRF_SDH_BLE_GAP_EVENT_LENGTH we set + the notification distances. And the frequency we get this notification pairs in the same as our current connection interval.

So looking at the ble_radio_notification.c implementation the radio_active value is just a static bool value m_radio_active that is toggled on every SWI1_IRQHandler(). So I was wondering it is possible for SWI1_IRQHandler() here to be missed, especially during BLE pairing + bonding operations when flash writing happening for BLE bonding info. Also our connection interval is pretty fast around 120ms.

If we are missing SWI1_IRQHandler() due to flash writing events, if there any work around to properly get the radio notifications?

[Jørgen Holmefjord]

Hi,

I believe that this is caused by the following limitation in the softevice, as described in the s140 v7.0.1 Release notes:

Limitations
SoftDevice
- If Radio Notifications are enabled, flash write and flash erase operations initiated through the SoftDevice API will be notified to the application as Radio Events (DRGN-5197/FORT-809).

During bonding operation, the bonding data is stored to flash. I believe that it would be possible to monitor the calls to the SD flash API, and prevent the radio notifications flag to toggle during such a scenario, but the softdevice will schedule flash operations between other tasks, so this will also cause you to lose the actual radio events during a flash procedure.

Best regards,
Jørgen

[hjz]

Hi Jorgen, Thanks for the reply that make sense.

Is there a way to work around this issue? We are okay with missing radio events, it just messes up our job scheduler when it sends the incorrect radio status.

We have tried to change the IRQ priority level for ble radio notification to the highest via ble_radio_notification_init(), and that seems to have at least stopped the incorrect radido status value, but from the explanation you provided changing the IRQ level really won't help here?

I guess I am also trying to understand more of exactly what is the state of the chip or softdevice while a flash write and erase operation is happening.