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.

[Ole Bauck]

You could use timeslot API instead, see this tutorial.

Don't you get two notifications on flash write/erase? If this is the case how can you get out of sync?

[Jordan Archer]

It's been a while since I looked at timeslots, but I think it had the same problem. It's actually the radio notification that gets out of sync, not the flash. With active flash operations the radio free time could be shifted by quite a bit. Long enough to push you out of the window and then get stepped on by another radio operation. It changes the dynamics of the problem, but it still exists.

[Ole Bauck]

I meant do you get two radio notifications when doing a flash operation. If flash operation gives two radio notifications and no radio radio notifications is happening in between, then there will be no problem, only less time to do critical tasks. For example: flash start -> flash end -> radio start -> radio end will work fine, but radio start -> flash start -> flash end -> radio end will lead to time between radio start and radio end where the application thinks the radio is off. I will check with the developers if this is the case. I don't think timeslots should be affected by the flash operations, but need to check this also.

[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.

[Ole Bauck]

Yes that is a problem. You can try to set the interrupt priority to APP_PRIORITY_HIGH and no other interrupt priority at that level. Most of the drivers should be using APP_PRIORITY_LOW, check nrf_drv_config.h. I cannot guarantee that the SoftDevice will not block the interrupt, but it should give the application some time during the connection event. I would recommend using timeslot instead.