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.

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

[Daino]

Hi Vidar,

running the code step-by-step it looks like the DFU executes successfully.

From my limited understanding it seems like the DFU finds a valid application and tries to run it. Then probably the application fails because it does not find the good SD.

EDIT:

Deep diving why the app was executed, we found out that the line

if (!app_is_valid(crc_on_valid_app_required())) inside dfu_enter_check()

was commented out, to speed up the startup and save energy (our application runs with a very low duty cycle and every millisecond counts to reach year-long battery life)... So basically the app CRC is never verified by the DFU. This allows the unexpected execution of the old app just after the DFU/SD update.

The good news: bringing back the CRC control, the OTA update is now successfully completed Thank you for your support all along the way!

Just as a closing note: do you see any viable alternative to bringing back the full CRC calculation in the DFU? We would really like to keep the boot-up as fast as possible.

[Vidar Berg]

Hi,

I am glad to hear that you found the issue  The problem with commenting out the line you mentioned is that you not only skip the CRC checksum validation, but also the .bank_code check here:

This explains why the bootloader attempted to boot the application before it had been uploaded.

To correctly disable CRC validation, you can use the '--app-boot-validation NO_VALIDATION' option when you generate your Bootloader settings page and DFU package with nrfutil. 

From the nrfutil help menus:

$ nrfutil pkg generate --help

Usage: nrfutil pkg generate [OPTIONS] ZIPFILE

  Generate a zip package for distribution to apps that support Nordic DFU OTA.
  The application, bootloader, and SoftDevice files are converted to .bin if
  supplied as .hex files. For more information on the generated package, see:
  http://developer.nordicsemi.com/nRF5_SDK/doc/
...

  --app-boot-validation [NO_VALIDATION|VALIDATE_GENERATED_CRC|VALIDATE_GENERATED_SHA256|VALIDATE_ECDSA_P256_SHA256]
                                  The method of boot validation for
                                  application.
                                  
$ nrfutil settings generate --help
Usage: nrfutil settings generate [OPTIONS] HEX_FILE

...

  --app-boot-validation [NO_VALIDATION|VALIDATE_GENERATED_CRC|VALIDATE_GENERATED_SHA256|VALIDATE_ECDSA_P256_SHA256]
                                  The method of boot validation for
                                  application.

[Daino]

Thank you very much Vidar!