Using Reserved virtual page space for storing very critical value which needs to be saved for a very long time.

[Gaurav]

Value can only be changed on characteristics write. Every time a new value has to be written to the critical component , I first erase the page and then write on that page.

/** Erase the page and then write to the reserved flash**/
ret_code_t ret = nrf_fstorage_erase(&reserve_fs,write_address,1,NULL);
return nrf_fstorage_write(&reserve_fs, write_address, page_tag_data1, 4 * sizeof(uint32_t), NULL);

This is the code snippet.

Is there a possibility that this method breaks at some point.

I am also doing GC(garbage collection) on the rest of the pages, can gc be done on this page as well.

[Kenneth]

The main problem with your implementaton is a power failure between page erase and writing new data. It is likely you will end up in a situation with no data in the reserved page in this situation, so this is something you at least need to handle in some way. Other than that it should be fine.

To ensure your reserved page is not touched by the FDS module (that for instance can run GC) I sugggest to place the reserved page outside of the FDS area.

Best regards,
Kenneth

[Gaurav]

Thanks Kenneth.

Reserved space in my code snippet is actually space out of FDS pages, i.e., start of Bootloader address till end of FDS virtual pages.

Will this method be saved from any unexpected erase and writes.

[Gaurav]

Just to add on the failure mode. We have seen FDS page getting marked as "UNDEFINED" header and the data was present on the half page and wiped out on other half.

Is this behavior normal, because we have replicated several times and seen it.

[Kenneth]

Not sure I fully understand, but if you want to reserve flash pages between FDS and bootloader for your own usage (and have it untouched by FDS module), the look into using this define from sdk_config.h:

// <o> FDS_VIRTUAL_PAGES_RESERVED - The number of virtual flash pages that are used by other modules.
// <i> FDS module stores its data in the last pages of the flash memory.
// <i> By setting this value, you can move flash end address used by the FDS.
// <i> As a result the reserved space can be used by other modules.

#ifndef FDS_VIRTUAL_PAGES_RESERVED
#define FDS_VIRTUAL_PAGES_RESERVED 0
#endif

[Gaurav]

That's correct Kenneth, I have used same reserved section and wrote on the address pointed to this page. But is the erase or write a blocking function and do we have to wait for them to finish of their tasks.

[Kenneth]

The CPU wil be totally blocked while erase and write operations occur, so any interrupts and code executing will be halted until the flash operation completes. Though have in mind that the flash operation will be scheduled by the softdevice, so it does not happen immediately when the flash api is called.

Kenneth

[Gaurav]

Thanks Kenneth. 

Does this mean that the function call nrf_fstorage_erase is fully blocking, i.e. we dont have to wait for the callback event registered during NRF_FSTORAGE_DEF(nrf_fstorage_t reserve_fs)?

I ask this so that we can avoid doing any other transactions till the callback signifying end of erase page is recieved.

Another issue that we have seen during further debug is that when GC is getting interrupted during supply glitch, we are seeing that only the first 1024 words are getting erased in a page (whose size is 2048 words). For example if the page 0x60000 - 0x62000 was interrupted during erase, we see that all words between 0x60000-0x61000  are 0xFFFFFFFF, whereas 0x61000-0x62000 still has its original data. This behavior is very consistent in the way that every single corrupted page is erased only midway. Is this expected behavior? Does this also mean that if we keep FDS_PAGE_SIZE as 1024 words we will be able to avoid page corruption?

Request your urgent assistance on these questions as we have had to keep the production on hold and are unsure of the fix we have implemented.

Best,

Gaurav

[Kenneth]

Hello,

Please see Figure 1 Memory layout here:
https://infocenter.nordicsemi.com/topic/ps_nrf52833/memory.html

As you can see the there are (0...127)128 flash pages with a size of 0x1000. So if you want to erase code flash adress 0x60000 - 0x62000, then that is 2 flash pages, not one flash page. 

Gaurav said:

Does this mean that the function call nrf_fstorage_erase is fully blocking, i.e. we dont have to wait for the callback event registered during NRF_FSTORAGE_DEF(nrf_fstorage_t reserve_fs)?

I assume here that you are using a softdevice here, and in your case the softdevice will schedule the erase operation, the erase operation will occur when it have least impact on other softdevice operations such as connections. While the flash operation is occuring, it can take up to 87.5ms, then the entire CPU execution is halted by hardware. For comparison when writing data to flash the CPU execution is halted with 42.5us for each 32-bit word. It's only when the callback return that you know the operation have completed.

Best regards,
Kenneth