This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

DFU (sometimes) erases app data

Dear Nordic,

I changed the value in the Bootloader to not erase the 4k just before the bootlader.

NRF_DFU_APP_DATA_AREA_SIZE 4096

In the app I changed the rom size to end just before this space.

I save my user settings in this location. But what I found is that one out of 20 updates seems to erase this block as well.

Not sure what is going on, it works in general. Is there something I am missing? The image I update with is not changing in size, so I expect the same result each time.

Parents
  • Hi,

    Which SDK version are you using? The bootloader should respect the NRF_DFU_APP_DATA_AREA_SIZE, and testing with the same firmware you should get the same behaviour on every upgrade. Could it be that it is your application that is corrupting the reserved flash page and not the bootloader? How do you read and write to that page? Can you confirm that you do not use the flash data storage (FDS) library (directly or via the peer manager)?

  • Hi,

    I am using the latest sdk 17.0.2. The app it self does not write to this part, it only reads from it. The idea is that we write to it via the jtag in factory (ID and stuff like that). The app just reads it.

    So the App itself does not change it. The boot loader is the secure ble boot loader. I changed the keys, removed the button option, set a new name and changed the app data size.

    So minimal change.

    It seems more prevalent when the new image I load has a different size than the one on there. That being said, they are still relatively small, so the dual buffer thing should still work



  • Hi,

    I am not able to see how the bootloader could corrupt the flash page right before the bootloader with NRF_DFU_APP_DATA_AREA_SIZE set to 4096, nor have I found any other similar reports. Therefor I wonder if it is worth looking into your application as well.

    Could it be something else that triggers this, perhaps just the application resetting or something else that the app does after DFU? Even though this page should only be read I understand you also write to flash in your application. How do you write to flash in your application, using which libraries etc? Also, do you use the peer manger (which in turn use the FDS)? Which parts of the flash do you write to? Could it be an error there which causes an erase to include more pages than it should?

Reply
  • Hi,

    I am not able to see how the bootloader could corrupt the flash page right before the bootloader with NRF_DFU_APP_DATA_AREA_SIZE set to 4096, nor have I found any other similar reports. Therefor I wonder if it is worth looking into your application as well.

    Could it be something else that triggers this, perhaps just the application resetting or something else that the app does after DFU? Even though this page should only be read I understand you also write to flash in your application. How do you write to flash in your application, using which libraries etc? Also, do you use the peer manger (which in turn use the FDS)? Which parts of the flash do you write to? Could it be an error there which causes an erase to include more pages than it should?

Children
No Data
Related