nrf_fstorage help

[JGusler]

nRF52840, SDK17.1.0 SD140

I am attempting to write a 16 byte array to NVM. This array is initialized simply as uint8_t diaper_aes_enc_key[16];. For testing/learning of the fstorage library I attempt to write to fill this array with 7s, write this to flash, read it back into the array, and make sure nothing has changed.

  //Setup flash storage
  err_code = nrf_fstorage_init(
      &my_instance,       /* You fstorage instance, previously defined. */
      &nrf_fstorage_sd,   /* Name of the backend. */
      NULL                /* Optional parameter, backend-dependant. */
  );
  APP_ERROR_CHECK(err_code);

  //THE FOLLOWING READ AND WRITE ARE FOR TESTING PURPOSES ONLY
  for (int i = 0; i < 16; i++)
  {
     diaper_aes_enc_key[i] = 7; 
  }
  
  err_code = nrf_fstorage_write(
        &my_instance,
        0x000FC000,
        diaper_aes_enc_key,
        sizeof(diaper_aes_enc_key),
        NULL
  );
  while (nrf_fstorage_is_busy(&my_instance))
  {
    //spin
  }

  NRF_LOG_INFO("write result: %d", err_code);

  err_code = nrf_fstorage_read(
        &my_instance,
        0x000FC000,
        diaper_aes_enc_key,
        sizeof(diaper_aes_enc_key)
  );
  while (nrf_fstorage_is_busy(&my_instance))
  {
    //spin
  }
  for (int i = 0; i < 16; i++)
  {
     NRF_LOG_INFO("Reading.. %X", diaper_aes_enc_key[i]);
  }

My RTT output says the write went just fine with a err_code of 0, but when I read it back the array is four 0s followed by twelve 2s. I checked with the nRF connect for desktop programmer that this section of memory would be available. What am I doing wrong?

[Einar Thorsrud]

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.

[JGusler]

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?

[Einar Thorsrud]

JGusler said:

Why would writing only flip from 1 to 0?

This is an inherent property of flash memory.

JGusler said:

Does erase set everything to 1?

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.

JGusler said:

And with erase only erasing entire pages, how would I handle only erasing the 16 bytes and not more than I want?

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.

[JGusler]

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

[Einar Thorsrud]

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.

[JGusler]

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

[Einar Thorsrud]

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.