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?

[grahn]

Hi Björn,

Thanks a lot for the reply!

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.

Q3: I understand. But for this scenario we can actually take that risk since it is still possible (but not easy) for us to get physical access to our released products. Then, understanding that a power failure leads to a bricked device, what would be the sequence to upgrade the MBR? As I mentioned, we tried to do this from the bootloader, but ended up in a signal handler (0xfffffffe according to gdb backtrace) when trying to erase the first block. We used the NVMC registers directly since the SoftDevice is disabled at this point.

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?

Yes we are doing a combined upgrade of the Bootloader and the SoftDevice. However, in our case I think that there is no dependency between the Bootloader and the SoftDevice since we don't use the SoftDevice from our Bootloader (other than the MBR API which seems to be unchanged in the SoftDevice). Maybe I'm missing something here? The reason we upgrade the Bootloader is actually to fix a bug in our startup code and not to stay compatible with the SoftDevice.

Anyway, the OTA transfer of the new software (including the Bootloader) is done by our application. In this case we are storing the new Bootloader in an unused part of the flash. When the new Bootloader is successfully stored, we change the UICR registers to point to the new bootloader. We do not use the SD_MBR_COMMAND_COPY_BL.

[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){}

[grahn]

Thanks. That's basically what I tried but then got an exception when doing ERASEPAGE @0x0000. I will try this again and investigate a little bit more. I will come back with the results and some more information.

[grahn]

We figured it out. The SYSTICK was still enabled during ERASEPAGE. After disabling the SYSTICK, we managed to successfully perform the intended upgrade of our devices. Thank for your support!