OTA DFU Softdevice 3.1.0 -> 7.0.1 is feasible?

[Daino]

Hi!

We have some legacy IoT devices currently running with s132 3.1.0 softdevice (yes... very old). We would like to push a major update of the fleet, with our latest firmware running on s132 7.0.1 

The DFU OTA is partially working: the first step is going well (SD + BL update) but then the procedure timeouts! The app update part is never reached. The device is then bricked.

I'm using the following command to generate the zip package:

nrfutil pkg generate --application "APP.hex" --application-version {app_ver} --softdevice "s132_nrf52_7.0.1_softdevice.hex" --bootloader "DFU.hex" --bootloader-version {bootloader_ver} --hw-version {hw_ver} --sd-req 0x91,0xCB --sd-id 0xCB --key-file "dfu_private_key.pem" DFU.zip'

This package is fully working on a 7.0.1 device, but it is unable to update a legacy 3.1.0 device.

I've also realized that the flash requirements are changing between the 2 soft devices... there is something that I'm missing?

Any help would be really appreciated! Thank you!

[Vidar Berg]

Hi,

It should be possible to update the Softdevice from this version. The bootloader will change the flash layout dynamically to accomodate for the larger softdevice size.

After the connection times out, can you try to start a scan and see if the device is advertising in DFU mode (as "DFUTarg" or similiar)? Alternatively, connect a debugger to your device and run "nrfjprog --readregs". This will read out the CPU registers from the chip, which may help us determine what state it is in.

Best regards,

Vidar

[Daino]

Hi Vidar,

Nothing is advertising.

$ nrfjprog.exe -f NRF52 --readregs
R0: 0x00000004
R1: 0xFFFFFFF9
R2: 0x20000004
R3: 0x000251CB
R4: 0x00001000
R5: 0x0007E080
R6: 0x0007E000
R7: 0x00000000
R8: 0x00000000
R9: 0x00000000
R10: 0x00000000
R11: 0x00000000
R12: 0x0007E37F
SP: 0x2F00E830
LR: 0xFFFFFFF9
PC: 0x000251D8
xPSR: 0x61000003
MSP: 0x2F00E830
PSP: 0x00000000

I've also dumped the memory with nrfjprog.exe -f NRF52 --readcode --readuicr DUMP_AFTER_DFU.hex and I see big chuncks of memory that match what we should expect, in particular after 0x1000 (SD) and 0x78000 (BL), so I might assume that the SD+BL transfer went well.

[Vidar Berg]

Hi,

Thanks. The CPU registers show that the program has entered a hardfault exception. Have you checked if the Bootloader start address is the same in the new and old bootloader (address is stored at 0x10001014 in UICR)

[Daino]

UICR is not changed. Here the hex diff of the memory dump pre and post-DFU procedure, value is the same (aka 0x78000 / 0x7E000 as expected). 

Also, I don't know if it helps, but there is a weird value on the Bank0 Code (0xAC):

$ nrfutil settings display DUMP_DFU.hex

Bootloader DFU Settings:

* File:                     DUMP_DFU.hex

* Family:                   nRF52

* Start Address:            0x00000000

* CRC:                      0xA516844A

* Settings Version:         0x00000002 (2)

* App Version:              0x00000001 (1)

* Bootloader Version:       0x0000012C (300)

* Bank Layout:              0x00000001

* Current Bank:             0x00000000

* Application Size:         0x0002A388 (172936 bytes)

* Application CRC:          0x1921E29E

* Bank0 Bank Code:          0x000000AC

* Softdevice Size:          0x000248C0 (149696 bytes)

* Boot Validation CRC:      0xE3E24184

* SD Boot Validation Type:  0x00000000 (0)

* App Boot Validation Type: 0x00000001 (1)

[Vidar Berg]

Sorry, I was not clear. The UICR will not be updated during a DFU. What I am wondering is if the bootloader start address stored at 0x10001014 is identical to the start address you built your new bootloader with. As you may know, it is not possible to relocate the bootloader through DFU.

Bank code 0xAC corresponds to NRF_DFU_BANK_VALID_SD_BL, which is to be expected if the bootloader crashed after the SD+BL transfer was completed.

[Daino]

Hi Vidar,

Dumping the UICR from the legacy HW I read this:

:020000041000EA
:10100000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0
:10101000FFFFFFFF0080070000E00700FFFFFFFF6A

As far I can tell this mean a bootloader address at 0x78000. Which matches the linker address FLASH_START=0x78000 in the DFU project (and output hex) of the newer FW.

Is this answering your question or am I missing something?

The only difference that I see is the .init section that happens to be in 0x78400 in the legacy FW, and 0x78200 in the new one (.vectors, on the other side, are well aligned on both at 0x78000).