Fixing radio notification and flash write/erase conficts.

[Jordan Archer]

Is there a plan to fix this errata limitation from errata limitations documented on 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 (FORT-809).

Because of this limitation, if you are doing a fair amount of flash write/erase operations (not excessive), you can't tell when you've been interrupted for BLE operation, in critical operations such as ADC samples, in a very quiet rf environment. It could be a flash operation completing that was reported as an RF toggle. And worse yet, reported as a radio toggle event when it was, or wasn't.

I've captured this with some testing. And seen the recommended "toggle" method of tracking radio activity get out of sync, because a flash operations completed in the middle. So a toggle for radio start and then a radio stop is only reported as one event.

[Jordan Archer]

What I've caught is occasionally getting only one radio notification. This causes the radio notification to be out of sequence. It's rare, but if you do enough flash operations, this triggers. UART traffic may make this worse.

My theory is that because radio notification are interrupts, if softdevice signals a radio event, but that doesn't get serviced immediately because of a pending or active flash operation. The second radio notification interrupt is sent, before the first is serviced by the application level. So it only sees one interrupt when two happened. So it's not that the notification got lost. It's that the nature of radio even interrupts is that you can have only one pending.