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.