nrf_fstorage help

RE: nrf_fstorage help

Einar Thorsrud — Mon, 10 Oct 2022 14:31:35 GMT

That is correct. So when you for instance update a record, what happens is that the current record is marked as dirty (by flipping another bit in the record header from '1' to '0'), and a new record is written.

RE: nrf_fstorage help

JGusler — Mon, 10 Oct 2022 14:23:44 GMT

So with only setting File ID and record keys, is the actual memory address just set under the hood?

RE: nrf_fstorage help

Einar Thorsrud — Mon, 10 Oct 2022 13:23:40 GMT

Yes, FDS plays nicely with the SoftDevice. In fact, all our BLE examples that support bonding use FDS, as that is the file system used by the peer manager to store bonds.

RE: nrf_fstorage help

JGusler — Mon, 10 Oct 2022 13:10:17 GMT

Okie dokie, does FDS play nicely with softdevices? Thank you for all the info!

RE: nrf_fstorage help

Einar Thorsrud — Mon, 10 Oct 2022 07:10:29 GMT

[quote user="JGusler"]Why would writing only flip from 1 to 0?[/quote]

This is an inherent property of flash memory.

[quote user="JGusler"]Does erase set everything to 1? [/quote]

Yes, erasing flash memory means flipping all bits to 1. On the nRF devices the smallest unit you can erase are flash pages, which are 4 kB blocks on the nRF52 series devices.

[quote user="JGusler"]And with erase only erasing entire pages, how would I handle only erasing the 16 bytes and not more than I want?[/quote]

It is not possible. That is why you often would want to use a file system (like FDS) to handle the complexities of this for you.

RE: nrf_fstorage help

JGusler — Fri, 07 Oct 2022 13:34:58 GMT

Why would writing only flip from 1 to 0? Does erase set everything to 1? And with erase only erasing entire pages, how would I handle only erasing the 16 bytes and not more than I want?

RE: nrf_fstorage help

Einar Thorsrud — Fri, 07 Oct 2022 11:51:17 GMT

Hi,

This code snippet looks correct, but I do not see the full application so there could be something outside of this that is problematic.

Other than that, one important point is that writing only flip bits from '1' to '0', so a possible explanation for the data corruption you are seeing is that the flash you are writing to has not been erased first. You could simply read and log the content of the destination address before writing to check that.