Protect NVM from being overwritten during reflash

[Brian]

I'm using the pstorage driver on the nRF51 to maintain several NVM variables. The NVM functions correctly and maintains state between power cycles. However, when I reflash the device using OTA reflash (application only, not SoftDevice), all of my NVM variables are reset to 0xFF. How do I prevent reflashing from modifying my NVM variables?

This is the command line I'm using to generate the zip file used for OTA reflash -

nrfutil dfu genpkg myProgram.zip --application myProgram.hex --application-version 0xffff --dev-revision 0xffff --dev-type 0xffff --sd-req 0xfffe

Thanks

Brian

[FormerMember]

The "Preserving application data" section in the bootloader documentation explains what to do to avoid loosing data during the DFU operation.

[Brian]

Thanks Kristin! I'm using SDK 9.0, and found the dfu_types.h file used by my bootloader. I changed the #define of DFU_APP_DATA_RESERVED from 0 to CODE_PAGE_SIZE (which is 0x400). I then rebuilt my bootloader and app, and combined them into a .zip file with nrfutil, like this: "nrfutil dfu genpkg strobe.zip --application myApplication.hex --bootloader myBootloader.hex --application-version 0xffff --dev-revision 0xffff --dev-type 0xffff --sd-req 0xfffe

When I try to reflash this zip file to my device using nRF Toolbox, I get a message that says it is updating part 1 of 2, then a message that it is disconnecting from the device, and then a message saying the upload failed. My device no longer boots up now. Any idea what went wrong? Thanks.

[FormerMember]

Do you use single bank or dual bank DFU?

[Brian]

I'm using the dual-bank bootloader - based off of the Makefile in .../examples/dfu/bootloader/pca10028/dual_bank_ble_s110/armgcc. Is it possible that trying to update both bootloader and application at the same time did not fit in the available free space? Does this mean I need to perform the updates as 2 separate steps - first the bootloader, then the application? I'm assuming the change I made to DFU_APP_DATA_RESERVED does not change the actual code size of the bootloader, correct? Thanks...

[FormerMember]

The principle of dual bank update is that there has to be enough available free space for what you want to update. So yes, if there is not enough space for a new bootloader and a new application at the same time, they will have to be updated in two separate steps. First bootloader and then the application would be the best.

DFU_APP_DATA_RESERVED is just a size, so the start address for the bootloader will still be the same. Note: If using pstorage and reserving 0x400, 0x400 will only correspond to the swap page in pstorage, see more in this post.

Regarding DFU_APP_DATA_RESERVED, I would recommend you to take a look at this post.

[Brian]

Thank you for the links above. I'm calling device_manager_init() before calling pstorage_register, so I've set DFU_APP_DATA_RESERVED to CODE_PAGE_SIZE * 3. I've also looked at the map files for both my bootloader and app. I should have plenty of free space to update both of these together. My bootloader starts at 0x3b800, and my app goes from 0x18000 to 0x24A28, which has a length of 0xca28. With DFU_APP_DATA_RESERVED set to CODE_PAGE_SIZE * 3, I believe that the App Data section then goes from 0x3ac00 to 0x3b800. This leaves a Free Space section from 0x24a28 to 0x3ac00, which is 0x161d5 in length. I've now tried to update my bootloader only over-the-air using the following command to generate the .zip file: nrfutil dfu genpkg my_bootloader.zip --bootloader my_bootloader.hex --dev-revision 0xffff --dev-type 0xffff --sd-req 0xfffe I copy the resulting file to my Android phone, and using nRF Toolbox, I reflash the bootloader. The reflash process indicates it is successful, however, my device will no longer boot up! The only change I've made is adding: #define DFU_APP_DATA_RESERVED CODE_PAGE_SIZE * 3 to dfu_types.h. I see in the last link above a reference to a similar problem. The suggested solution is to modify dfu_bl_image_validate() because the DFU_BANK_1_REGION_START has changed from the old bootloader to the new bootloader. Could you explain further what that modification should be? Thanks.