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

[Hieu]

Hi MaxMik,

Are you working on existing products already deployed to the field, or a new project?

I need more information about the existing setup before DFU.

• Is MBR programmed?
• What kind of bootloader is there?
• What exactly is custom about the DFU implementation? Are the new images downloaded by the application instead?

Hieu

[MaxMik]

I am working on an nRF52 840.

The DFU implementation is custom in the host implementation only, while on the nRF52 side I use the default implementation.

MBR is programmed and I use the secure bootloader available in the examples provided in the nRF SDK from nrf sdk.

Since you mentioned the MBR, this is how I generate the hex files for pkg generate. Maybe its helpful.

For the esb application:

mergehex -m mbr_nrf52_2.4.1_mbr.hex bootloader.hex bootloader_settings.hex application.hex -o app.hex

For the ble application:

mergehex -m s140_nrf52_7.2.0_softdevice.hex bootloader.hex bootloader_settings.hex application.hex -o app.hex

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

[Hieu]

Hi MaxMik,

I just want to update that I tried to setup a reproduction of the issue but met some problems with the debugging bootloader I work with failed to boot correctly.

I will keep looking into this and keep you updated.

[Hieu]

Hi MaxMik,

My failure last time turned out to be a silly human file handling mistake. I was able to DFU a BLE image today by first DFU only the SD (with sd-req set to 0x00), and then DFU only the application (with sd-req set to 0x100).

Would you like to give that a try?

Below is the information about my setup for reference.

1. Starting firmware
   1. nRF5 SDK v17.0.2 MBR (v2.4.1)
   2. nRF5 SDK v17.0.2 secure_bootloader example, pca10056_uart_debug, with the following modifications:
      1. Set NRF_BL_DFU_ENTER_METHOD_BUTTON to 0
      2. Set NRF_BL_DFU_ENTER_METHOD_PINRESET to 1
      3. Set NRF_BL_DFU_INACTIVITY_TIMEOUT_MS to 30000
         
         
   3. nRF5 SDK v17.0.2 blinky example, pca10056, mbr
      
      
   4. Bootloader settings generated with this command:
      1. nrfutil settings generate --family NRF52840 --application .\_4_app-blinky_pca10056_mbr.hex --application-version 0 --bootloader-version 0 --bl-setting-version 2 _3_bl_settings-bootloader_settings.hex
         
         
2. Confirm blinky boot fine using debugger-triggered soft reset
   
   
3. Put the device into DFU mode with the reset button
   
   
4. DFU v17.1.0 S140 v7.2.0
   1. Package generated with
      
      1. nrfutil pkg generate --hw-version 52 --softdevice .\v17.1.0_sd-s140_nrf52_7.2.0_softdevice.hex --sd-req 0x00 --key-file .\c352346.key dfu_pkg_sd-sd_req_0x00.zip
         
         
5. DFU v17.1.0 BLE HRS test image
   1. Located at: nRF5_SDK_17.1.0_ddde560\examples\dfu\secure_dfu_test_images\ble\nrf52840\hrs_application_s140.hex
   2. Package generated with
      1. nrfutil pkg generate --hw-version 52 --application-version 1 --application .\v17.1.0_app-hrs_application_s140.hex --sd-req 0x100 --key-file .\c352346.key dfu_pkg_app-sd_req_0x100.zip
         
         
6. Confirm BLE HRS image is advertising as expected

And here are the relevant project files, build artifacts, hex, and DFU packages, and log from the bootloader.

c352346_dfu-251107_02.7z

[MaxMik]

After some more trial and error, I was finally able to update my device from the softdevice-less ESB application to the BLE application with softdevice. Turns out what was causing the failures was the pin reset I was performing between processing the softdevice and processing the application. Removing that reset and replacing it with a small delay solved the issue, and I am now able to perform the updates consistently.

[Hieu]

That's good to hear. I was a little worried we reached a dead end.

Then, if everything is working as expected, then please feel free to close the ticket at your convenience.