nrf_storage_is_busy() never returns false

RE: nrf_storage_is_busy() never returns false

Vidar Berg — Mon, 19 Oct 2020 13:04:28 GMT

Then I think it may make sense to use fstorage. I wanted to point it out just in case it had not been considered. Good luck:)

RE: nrf_storage_is_busy() never returns false

Jur — Mon, 19 Oct 2020 13:00:39 GMT

Awesome, thanks a lot for helping me out! The flash write should not be frequent. The device will need to be configured once (through a BLE message) before using it. So the idea is this will only be done a few times in the lifetime of the device 🙂 Thanks again for the help. Really appreciated!

RE: nrf_storage_is_busy() never returns false

Vidar Berg — Mon, 19 Oct 2020 12:56:55 GMT

Hi,

Yes, I don't foresee any problems with this approach. I actaully did not think of this possibilty. I thought the idea was to use the scheduler for Softevice events so events such as BLE_GATTS_EVT_WRITE didn't have to be processed in the Softdevice IRQ context.

And as a side note, for frequent storage of data we generally recommend using Flash Data Storage (FDS) to manage the storage. It helps limit the number of costly erase operations.

RE: nrf_storage_is_busy() never returns false

Jur — Mon, 19 Oct 2020 12:45:02 GMT

Hi Vidar,

I was thinking about doing it this way:

BLE_GATTS_EVT_WRITE -> Add data to be processed to scheduler queue.
return from interrupt
In main loop, app_sched_execute() is called. -> data found in queue which should be processed.
data is processed and should be written to flash
as this is now executed in the main context (through the scheduler), nrf_fstorage_is_busy() should work.

Could you debunk this? Or are you saying that the softdevice uses the very same scheduler?

Else I think I need to indeed just assume the flash operation will complete succesfully and handle errors when they occur.

RE: nrf_storage_is_busy() never returns false

Vidar Berg — Mon, 19 Oct 2020 12:33:09 GMT

Hi,

The app scheduler will prevent the interrupt from getting blocked. But I'm afraid it won't solve your problem either, because the softdevice events are added to the scheduler queue and only processed after when returning to the main loop.

I think usually you can assume that a flash operation will complete succesfully. The fstorage callback will notify the app if there was a problem.

RE: nrf_storage_is_busy() never returns false

Jur — Mon, 19 Oct 2020 10:52:18 GMT

Hi Vidar,

Thanks for the fast response! The write function is called after a BLE write operation, which I guess is handled by the softdevice. So basically you're saying that I am blocking the softdevice interrupt with this? If I understand you correctly I could make the BLE write event trigger an interupt with pri. < 7 which will write the actual data to flash? I'll go look for some examples 🙂

As to why I want to make it blocking: I calculate a checksum of the data before writing, and directly after writing I would like to read the data again and make sure the checksum matches. I could do this by passing the checksum as an argument to the fstorage_write function, so I can do the check on a NRF_FSTORAGE_EVT_WRITE_RESULT. However, I write to flash for different reasons, which require different actions after the write. So I think making it blocking will make it a cleaner implementation for my purpose.

Update: It seems it isn't a matter of just calling an interrupt from the BLE write event. How is this normally done? When data is written to the device, I think it shouldn't be processed within the BLE_GATTS_EVT_WRITE or should it?

Update2: Is it usual to use the Scheduler for this?

Update3: The scheduler seems to be exactly what I need for this.

RE: nrf_storage_is_busy() never returns false

Vidar Berg — Mon, 19 Oct 2020 10:38:35 GMT

Hi,

The write_flash() implementation will only work if called from main the context, or from an interrupt context with lower priority than what the Softdevice interrupt has (i.e. no higher than pri. 7 which is also the lowest one available). The reason for this is that the softdevice interrupt is used to notify the app/fstorage when an asynchrounus flash operation is complete, so if it gets blocked, the fstorage 'busy' state will never get cleared.

Have you considered not making the API blocking? Note that fstorage has an internal queue, so you can queue up multiple write commands without any delays in-between.