DFU from SD 1.0.0-3 to 4.0.2

[grahn]

Hi,

We started out developing an application using the SoftDevice 1.0.0-3 (from SDK 0.9.2). We now need to upgrade to SoftDevice 4.0.2 (included in SDK 13.0.0).

We already have products with SoftDevice 1.0.0-3 that have been released to customers and we are trying to figure out how we can perform the DFU OTA which includes SoftDevice 4.0.2.

Note - we have our own implementation of DFU and OTA, hence we do not use the SDK for this. We only use the SoftDevice from the SDK. We have been using our own implementation successfully for a long time, but this is the first we actually have to upgrade the SoftDevice as part of a new release.

This is what we do:

When upgrading the SoftDevice, we extract the non-MBR parts of it, transfers it to the device OTA. The bootloader will then write it flash address 0x1000. We use the following command to extract the non-MBR parts from the SoftDevice:

$ arm-none-eabi-objcopy -Iihex -Obinary --remove-section .sec1 --gap-fill=0xff ~/nRF5_SDK_13.0.0/components/softdevice/s132/hex/s132_nrf52_4.0.2_softdevice.hex sd.bin

Of course, the application code is also updated to reflect the API changes in the SoftDevice.

This is what happens, and a short analysis of why it fails:

After performing the upgrade, the application will no longer start. If we compare the flash memory contents of a board that has been programmed via JTAG (4.0.2) and a board that has been upgraded 1.0.0-3 to 4.0.2 (using OTA), the ONLY difference when comparing the binary dumps of the complete 512 Kb flash memory is @ address 0x0 to 0x1000 which is the MBR. This is expected since we did not upgrade the MBR. But we expected that the board would still start up, using the old MBR (1.0.0-3).

If we extract the MBR (using arm-none-eabi-objcopy) from the 4.0.2 SoftDevice and write it using JTAG to the bricked board, it starts up again as expected. See the command sequence below.

$ arm-none-eabi-objcopy -Iihex -Oihex -R .sec2 -R .sec3 ~/nRF5_SDK_13.0.0/components/softdevice/s132/hex/s132_nrf52_4.0.2_softdevice.hex mbr.hex

$ nrfjprog --erasepage 0x0-0x1000 -f NRF52

$ nrfjprog --program mbr.hex -f NRF52

-> Board is now running SoftDevice 4.0.2 and the new application.

Questions:

Do we HAVE to switch to the MBR included in SoftDevice 4.0.2?

If not, then how do we get a board running with the combination of MBR 1.0.0-3 and SoftDevice 4.0.2?

If we have to change the MBR, then how can we do this without using JTAG? We tried, but ended up in a signal handler (0xfffffffe according to gdb backtrace) when trying to erase the first block, which contains the MBR. We disabled all the interrupts before the erase started.

[bjorn-spockeli]

Hi Grahn,

The S132 v1.0.0-3.alpha was never intended as a production-ready SoftDevice, hence the Alpha designation.

Q1: Do we HAVE to switch to the MBR included in SoftDevice 4.0.2? A1: Yes, since the MBR in S132 v1.0.0-3.alpha is 12kB, it expects the SoftDevice to start from this address. You cannot place the S132 v4.0.2 at 0x3000, since this has been compiled to start at 0x1000.

Q2: If we have to change the MBR, then how can we do this without using JTAG? A2: It is not possible to change the MBR, i.e. erase the old and replace it with a new MBR, without risking bricking the device. If you get a power failure during the flash operation that overwrites the old MBR with the new, then the device is bricked.

I assume that you're doing a combined Bootloader and SoftDevice update in order to keep them compatible with eachother. Are you using the SD_MBR_COMMAND_COPY_BL command to perform the Bootloader swap?

[bjorn-spockeli]

Ok, if you're willing to take that risk then erasing the MBR should be straight-forward, i.e.

//Enable Erase mode
NRF_NVMC->CONFIG = 0x02;
while(!NRF_NVMC->READY){}

// Erase the flash pages from 0x0000 to 0x3000
NRF_NVMC->ERASEPAGE = 0x00000000;
while(!NRF_NVMC->READY){}
NRF_NVMC->ERASEPAGE = 0x00001000;
while(!NRF_NVMC->READY){}
NRF_NVMC->ERASEPAGE = 0x00002000;
while(!NRF_NVMC->READY){}