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.

[Jørgen Holmefjord]

Hi,

Unfortunately, I do not think there is an easy way to work around this issue. I do have a couple of suggestions, but not any ready-made solutions.

My initial idea was to introduce a flag that is set whenever a flash write/erase operation is requested to the softdevice, through sd_flash_write()/sd_flash_page_erase() APIs. Since you only mention bonding, these calls are triggered by peer_manager, which uses FDS and fstorage to access flash. You would need to somehow pass the flag from the main application to the fstorage backend (nrf_fstorage_sd.c), where you set it before each successful call to one of the mentioned softdevice APIs, and clear it once fstorage receives the NRF_EVT_FLASH_OPERATION_SUCCESS/NRF_EVT_FLASH_OPERATION_ERROR events from the softdevice in nrf_fstorage_sys_evt_handler(). You can then use the flag in your application to determine if the m_radio_active flag should be togged on the radio notification events.

Another option is to use PPI and GPIOTE to toggle a GPIO on the events directly from the RADIO peripheral, specifically EVENTS_READY and EVENTS_END. You can then read the state of the GPIO in the application to know if the radio is actually active or not when you receive the radio notification events.

One through would also be to poll the NVMC READY register, to check if there is ongoing flash activity, however the CPU is halted during flash operations since the application/softdevice is executed from flash. This will most likely cause this register to always be reporting "Ready" when the CPU/application is able to access it.

Let me know if you need any more guidance on implementing any of the suggested methods.

Best regards,
Jørgen