Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

nrf_fstorage help

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?

Parents
  • 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.

Reply
  • 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.

Children
Related