OTA DFU Softdevice 3.1.0 -> 7.0.1 is feasible?

RE: OTA DFU Softdevice 3.1.0 -> 7.0.1 is feasible?

Daino — Wed, 25 Jan 2023 15:44:50 GMT

Thank you very much Vidar!

RE: OTA DFU Softdevice 3.1.0 -> 7.0.1 is feasible?

Vidar Berg — Mon, 23 Jan 2023 07:44:21 GMT

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.

RE: OTA DFU Softdevice 3.1.0 -> 7.0.1 is feasible?

Daino — Fri, 20 Jan 2023 16:43:21 GMT

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.

RE: OTA DFU Softdevice 3.1.0 -> 7.0.1 is feasible?

Vidar Berg — Thu, 19 Jan 2023 16:14:25 GMT

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.

[quote user="Daino"]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...)[/quote]

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.

RE: OTA DFU Softdevice 3.1.0 -> 7.0.1 is feasible?

Daino — Wed, 18 Jan 2023 10:56:52 GMT

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!

RE: OTA DFU Softdevice 3.1.0 -> 7.0.1 is feasible?

Vidar Berg — Tue, 17 Jan 2023 13:04:10 GMT

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?

devzone.nordicsemi.com/.../7282.dfu_5F00_sdk_5F00_12.3.0_5F00_SDK_5F00_16.0.0.zip

RE: OTA DFU Softdevice 3.1.0 -> 7.0.1 is feasible?

Daino — Fri, 13 Jan 2023 11:30:09 GMT

Thank you Vidar,

here it is

RE: OTA DFU Softdevice 3.1.0 -> 7.0.1 is feasible?

Vidar Berg — Fri, 13 Jan 2023 10:03:08 GMT

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.

RE: OTA DFU Softdevice 3.1.0 -> 7.0.1 is feasible?

Daino — Fri, 13 Jan 2023 09:09:34 GMT

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

RE: OTA DFU Softdevice 3.1.0 -> 7.0.1 is feasible?

Vidar Berg — Thu, 12 Jan 2023 11:02:59 GMT

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.

RE: OTA DFU Softdevice 3.1.0 -> 7.0.1 is feasible?

Daino — Wed, 11 Jan 2023 16:00:47 GMT

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)

RE: OTA DFU Softdevice 3.1.0 -> 7.0.1 is feasible?

Vidar Berg — Wed, 11 Jan 2023 15:51:02 GMT

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)

RE: OTA DFU Softdevice 3.1.0 -> 7.0.1 is feasible?

Daino — Wed, 11 Jan 2023 15:32:03 GMT

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.

RE: OTA DFU Softdevice 3.1.0 -> 7.0.1 is feasible?

Vidar Berg — Wed, 11 Jan 2023 14:51:29 GMT

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