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

Flash Read/Write fails after OTA DFU

Hello,

We are using the NRF52840 and softdevice S140, PCA10056 on all examples. SDK version is 15.3.

We see a problem following the secure OTA DFU protocol regarding acessing the flash. Follow the steps below to reproduce.

1. Flashed the nRF5_SDK_15.3.0_59ac345\examples\dfu\secure_bootloader\pca10056_ble\ses example onto the NRF52840 board. Done via the USB connection to the debugger.
2. Entered the board into DFU mode by pressing button 4 when turning it on.
3. Created a zip file following the secure OTA DFU instructions found in the Nordic dev site. The app is one of our own creation and has no relevance to the problem.
4. Flashed the Zip file created in step 3 using secure OTA. This finished successfully and the app worked well.
5. Using the same board, flashed the nRF5_SDK_15.3.0_59ac345\examples\peripheral\flash_fds\pca10056 example via the USB connection to the debugger.
6. Using Putty, looked at the output generated and noticed failed access attempt to both read and write to flash. See image below. The flash_fds example worked without problems before the OTA DFU was run, and continues to work on other boards.



Any thoughts?

  • Hi,

    You should compile the project with preprocessor symbol DEBUG defined, it should then print the error-code instead of "Fatal error".

    Anyways, as part of fds_init() -> flash_subsystem_init(), in flash_bounds_set() we check to see if a bootloader_addr is written to flash or not. If bootloader_addr is not found, fds will use the last 3(FDS_VIRTUAL_PAGES) pages at the end of the flash for fds data. If it finds a valid bootloader_addr, it will place the fds data below the bootloader location. In SDK 15.3 the bootloader_addr is stored in the MBR. It could be that bootloader_addr is not found, but you still have the bootloader or bootloader settings page still present in flash, and the fds then fails to initialize.

    Try to erase the flash completely, using nrfjprog -e , and then flash the flash_fds example again.

  • Hi Sigurd!

    Using nrfjprog -e did help with our problem, thanks for that.
    Am I understanding correctly when I say that whenever the bootloader size changes- for example when moving from 'non secure DFU over USB  bootloader', to 'secure DFU OTA bootloader' or vice versa- I will need to erase the flash?

    Thanks

Related