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]

It appears that my understanding of fstorage was poor, and my explanation above was only partially correct. My apologies. 

You are right, of course. The fstorage write and erase operations are put in queue and executed sequentially. After each completed operation you will get an event in return. So contrary to what I said before, calling fstorage_write() twice right after one another is not a problem. Write and erase operations are still asynchronous though. And that can be a challenge when you also use the synchronous read operation. Going back to your initial questions:

Q1) The read operation implements memcpy. The word blocking might be a bit misleading, but the point is that the read operation is synchronous. I.e. the entire read operation completes before the CPU moves on to the next task. Unless an interrupt occurs. As is the case with all other code, a read operation will be interrupted by higher priority interrupts. 

Q2) Yes. Your read operations can get interrupted by write operations, and you risk reading garbage values. To avoid that it is your responsibility to make sure that there are no pending write operations before you start a read operation. You can check this using nrf_fstorage_is_busy() or control it yourself via the events you get in return.