fstorage_read and coordination with the Softdevice

[superpak]

nrf52832

SDK 14.2

NVMC and SD backend both

Hi,

I had a question about the nrf_fstorage_read function. In a previous answer, it was mentioned that fstorage_read function is blocking. I would like to know a few
more details about this:

Q1. It was mentioned: "Read operations are implemented using memcpy function, and will block until read is completed." What is meant by block here? If I call fstorage_read, will it really block the CPU
and no other instructions can be performed until the data is read?(even in the SoftDevice backend)

Q2. With the Softdevice backend, if I call fstorage_write, it will break the large write into smaller writes that will be coordinated between NVM and the Radio. Now if I call
fstorage_read when this coordination is going on, I could read NVM and then get interrupted to write to NVM and then come back again into the read. The data read could not be different from
the data in NVM?

Q3. fstorage_read by itself just calls memcpy and doesn't really do any coordination. It is not even queued. So can this be a problem? The smaller writes can occur during fstorage_read and we
could read data that is not actually the real data?

Thanks.

[MartinBL]

Hi,

One thing one must understand is that the NVMC backend is synchronous and the SD is asynchronous. So if you use the NVMC backend, all your calls to read and write functions will be executed sequentially one after another. In other words, given this code:

fstorage_write();
fstorage_write();

the call to fstorage_write() at line 1 will complete the entire write operation before your application can move on to the second line of code. 

The SD backend on the other hand is asynchronous, meaning that given the code above, the call to fstorage_write() at line 1 completes immediately and leaves it up to the Softdevice to handle the write operation. When the operation completes you will get a NRF_FSTORAGE_WRITE_RESULT event returned from the Softdevice. If you call fstorage_write() twice one after another as in the code above, the first write operation will not be able to complete and you might run into trouble. What you need to do is to make sure that all fstorage operations are completed before you proceed with the next one. 

fstorage_write();
// Wait for the NRF_FSTORAGE_WRITE_RESULT 
fstorage_write();

 

The explanation above assumes that you are not starting any fstorage operations from interrupt contexts. If you an interrupt should happen to start an fstorage operation while another one is already in progress you will run into trouble again. As you say, it could e.g. lead to sections of data being overwritten while you are reading. To avoid this you should use a scheduler or flags in your interrupts to make sure to process all fstorage operations from your main context. 

EDIT 22.03.2018: fstorage_write() instead of fstorage_read() for better example. 

[superpak]

Hi MartinBL.

Thanks for your response. But looking at the nrf_fstorage_sd.c file, it does not seem like that the nrf_fstorage_read(..) operation is handled by the SoftDevice. The read implementation for the NVMC backend and the SD backend are both the same so it doesn't seem like the SD is coming into play for the read operation.

Also, if you look at the code for the event_send routine in nrf_fstorage_read(..) for the SD backend, it never sends a NRF_FSTORAGE_EVT_READ_RESULT as you mentioned. It only sends results for write and erase events. So if I do call nrf_fstorage_read(..), I will never get a NRF_FSTORAGE_EVT_READ_RESULT on completion because its not even part of the code!

Please let me know.

Thanks!