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]

Going to high priority didn't help. It reduced the rate of causing problems, but it still existed. As I recall, I think time slot showed some of the same symptoms. I didn't really have time to totally isolate what's going on.

Do you know for sure that time slot will solve the issue? I hate to re-spend the time doing that again and finding another hole. These take a while to chase down. Actually if I had one request, that would be to add a SD call to return a simple count of radio events. Then I could tell if something happened at any time during my processing.

And for references, I'm using S110.

Back to the original question. Is there any plan to fix the radio notification/flash notification errata?