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]

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.

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