DFU extended error 0x07

[MaxMik]

I am trying to update an nRF52 through the DFU protocol from an esb firmware without softdevice to a bluetooth firmware with softdevice included.

I am updating the device through a UART interface, using a custom implementation of the DFU protocol complying with DFU protocol (in which PRN is set to 0). I have tested my implementation with softdevice-less esb to softdevice-less esb updates and they work fine.

To create the update package, I run nrfutil v8.0.0, with the following command:

nrfutil pkg generate
        --key-file mycert.pem
        --hw-version 52
        --softdevice sd.hex
        --sd-req 0x00,0x0100
        --sd-id 0x0100
        --application-version-string APP_VERSION
        --application app.hex
        update.zip

After sending the softdevice .dat file in the "init packet" phase I receive an extended error (0x0B) with a payload of 0x07, which, according to nordic documentation is a SD version error. This happens in response to the execute request (0x04). If I immediately send another execute after the failure I get an error 0x05

If I run nrfutil pkg display on the genarated zip I get the following output:

DFU Package: <update.zip>:
|
|- Image count: 2
|
|- Image #0:
|- Type: softdevice
|- Image file: s140_nrf52_7.2.0_softdevice.bin
|- Init packet file: s140_nrf52_7.2.0_softdevice.dat
|
|- op_code: INIT
|- signature_type: ECDSA_P256_SHA256
|- signature (little-endian): b'SIGNATURE'
|
|- fw_version: 0xFFFFFFFF (4294967295)
|- hw_version 0x00000034 (52)
|- sd_req: 0x00, 0x100
|- type: SOFTDEVICE
|- sd_size: 153140
|- bl_size: 0
|- app_size: 0
|
|- hash_type: SHA256
|- hash (little-endian): b'HASH'
|
|- boot_validation_type: ['VALIDATE_GENERATED_CRC']
|- boot_validation_signature (little-endian): [b'']
|
|- is_debug: False

|
|- Image #1:
|- Type: application
|- Image file: radio_ble.bin
|- Init packet file: radio_ble.dat
|
|- op_code: INIT
|- signature_type: ECDSA_P256_SHA256
|- signature (little-endian): b'SIGNATURE'
|
|- fw_version: 0x00000322 (802)
|- hw_version 0x00000034 (52)
|- sd_req: 0x100
|- type: APPLICATION
|- sd_size: 0
|- bl_size: 0
|- app_size: 80356
|
|- hash_type: SHA256
|- hash (little-endian): b'HASH'
|
|- boot_validation_type: ['VALIDATE_GENERATED_CRC']
|- boot_validation_signature (little-endian): [b'']
|
|- is_debug: False

I have tried setting both NRF_DFU_SINGLE_BANK_APP_UPDATES=0 and NRF_DFU_SINGLE_BANK_APP_UPDATES=1, and I have NRF_DFU_APP_DOWNGRADE_PREVENTION=0

[MaxMik]

I double checked and the update zip I am using still gives the same pkg display output.

However, from further testing, I noticed this important difference:

- If I update from an application-less device that has bl and mbr only, the updates fully succeeds with no errors. 

- If I update from a device that has an esb application (in addition to bl and mbr), the update fails with the usual 0x0B 0x07.

[Hieu]

It might be a little difficult to get to the bottom of this right away.

Does the new BL support DFU on its own without an application?

If yes, can you try to DFU first with only SD+BL, and once more with only the application?
If this works, we will at least have a workaround in place while we figure out the issue.

What version of nRF5 SDK is the old bootloader from? I will try to come up with some additional logging to see if we can figure out the root cause.

[MaxMik]

The bootloader is the same across the 2 versions, taken from nRF SDK v. 17.0.2. So both bootloaders should support DFU. 

I was able to update from a MBR + BL only configuration, so bootloader should support DFU without application.

The only difference is in the settings:

- for the esb bootloader I have:

Bootloader DFU Settings:
* File:                     bl_settings_esb.hex
* Family:                   NRF52840
* Start Address:            0x000FF000
* CRC:                      0x80372F69
* Settings Version:         0x00000002 (2)
* App Version:              0x0000045F (1119)
* Bootloader Version:       0x00000001 (1)
* Bank Layout:              0x00000000
* Current Bank:             0x00000000
* Application Size:         0x0000E24C (57932 bytes)
* Application CRC:          0x85128E5F
* Bank0 Bank Code:          0x00000001
* Softdevice Size:          0x00000000 (0 bytes)
* Boot Validation CRC:      0xA0696BA0
* SD Boot Validation Type:  0x00000000 (0)
* App Boot Validation Type: 0x00000001 (1)

- for the bluetooth bootloader I have:

Bootloader DFU Settings:
* File:                     bl_settings_ble.hex
* Family:                   NRF52840
* Start Address:            0x000FF000
* CRC:                      0x4B22E60D
* Settings Version:         0x00000002 (2)
* App Version:              0x00000322 (802)
* Bootloader Version:       0x00000001 (1)
* Bank Layout:              0x00000000
* Current Bank:             0x00000000
* Application Size:         0x0001370C (79628 bytes)
* Application CRC:          0x349C4DEF
* Bank0 Bank Code:          0x00000001
* Softdevice Size:          0x00025634 (153140 bytes)
* Boot Validation CRC:      0xD6191B3A
* SD Boot Validation Type:  0x00000001 (1)
* App Boot Validation Type: 0x00000001 (1)

I am also getting a "Bad access at 0x7F000: not enough data to read 4 contiguous bytes" when I run "nrfutil nrf5sdk-tools settings display" for each of the 2 settings hex files.

[Hieu]

I couldn't figure out anything from looking at the bootloader implementation and documentation. I will probably have to try to reproduce it. Do I understand right that you have something like the bootloader with DFU over UART, and DFU mode entry by button?

[MaxMik]

Yes, I have DFU over UART on a nRF52840.

To trigger DFU I set the Reset Pin low and wait 1000 milliseconds. Then I send a DFU ping to check that the BL started in DFU and proceed with the DFU procedure: first I set PRN to 0, then get MTU, then send the initial packet and finally send the softdevice image.

Once I am done with softdevice, I reset the nRF with the same Pin, wait 1000 ms, check that BL is in DFU with ping, and repeat the same procedure with application image.