This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Fixing radio notification and flash write/erase conficts.

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.

Parents
  • 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.

Reply
  • 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.

Children
No Data
Related