DFU from SD 1.0.0-3 to 4.0.2

RE: DFU from SD 1.0.0-3 to 4.0.2

grahn — Fri, 02 Jun 2017 12:18:38 GMT

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!

RE: DFU from SD 1.0.0-3 to 4.0.2

grahn — Tue, 23 May 2017 06:38:06 GMT

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.

RE: DFU from SD 1.0.0-3 to 4.0.2

bjorn-spockeli — Fri, 19 May 2017 11:39:03 GMT

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

RE: DFU from SD 1.0.0-3 to 4.0.2

grahn — Fri, 19 May 2017 06:37:09 GMT

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.

RE: DFU from SD 1.0.0-3 to 4.0.2

bjorn-spockeli — Thu, 18 May 2017 14:33:46 GMT

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?