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).

[Vidar Berg]

Yes, this answers my question. Thanks. The key thing here is that the .vectors section is linked to the same start address in both builds. 

After the failed DFU, can you please run 'nrfjprog --memrd 0x0 --n 0x80000 > flash.txt and upload the output here? Or the data between 0x78000 - 0x78400 if you are not able to share everything here in a public ticket.

[Daino]

Thank you Vidar,

here it is

[Vidar Berg]

Hello,

I do not see anything that is obviously wrong in your memory dump. But the value @ 0x26000 is suspiciously close to the corrupt stack pointer value shown in your register readout earlier. Maybe the bootloader is trying to boot the application before it has been uploaded.

I tried to perform a complete DFU from nRF5 SDK 12.3.0/s132 v3.0.0 to nRF5 16.0.0/s132 v.7.0.1 with the original bootloader projects here to see if I could reproduce, but I could not.

Could you also do a 'memrd' after having programmed the new FW with the programmer, and then compare that to post-DFU-full.txt? 

7282.dfu_sdk_12.3.0_SDK_16.0.0.zip

[Daino]

Here the dump from the same device updated with the programmer.

SD and BL looks identical. MBR and Application are different. Also some minor differences in the MBR param area and BL param area (0x7E000/0x7F000).

Also the memory just before the application (0x258C0 - 0x25FFF) is not 0xFF in the post-DFU one, which seems a little bit weird to me (I don't know what this data is...)

What do you think? Thank you!

[Vidar Berg]

Could you try to start a debug session with the new bootloader project after the failed DFU attempt to see if you can figure out when hardfault is raised or why it does not enter DFU mode? I did go through the post-DFU-full.txt file again and compared it against REFLASHED.txt but nothing appears to be out of the ordinary. 

Daino said:

Also the memory just before the application (0x258C0 - 0x25FFF) is not 0xFF in the post-DFU one, which seems a little bit weird to me (I don't know what this data is...)

I understand this looks suspicious, but it is just a padding area reserved by the Softdevice which has not been cleaned up by the bootloader. 

The padding ensures the application starts on page aligned address (0x1000) and that we can make minor bug fix releases without changing the image size.