Update Softdevice via DFU (2025 update)

[ms360]

I'm wondering if this feature is still supported. 
I'd like to update some devices from SD 5 to 7.1
I saw an old post and wanted fresh info. 

 Update Softdevice via DFU 

If this is the same, I can

• make a new bootloader with SD 7.1 
• create a DFU package for app + bootloader + SD 7.1

and that's still the solution ? 

Thanks!

[Hieu]

Hi ms360,

From the SoftDevice version number, it looks like you are trying to upgrade from nRF5 SDK v14.x.0 to v16.0.0, is that correct?

If there are some changes between that are highly desirable for your project, I will not stop you. However, please keep in mind that every bootloader update comes with a risk of the device being bricked.

Regarding updated info, the thread you cited is from late August 2020, dealing with nRF5 SDK v17.0.0, so the information there should actually be as fresh as it gets with the nRF5 SDK. Please remember that the nRF5 SDK hasn't been worked on for more than 4 years now.

I checked v14.2.0 update solution and that of v16.0.0, and the design seems to remain the same between them. You would just need to make sure that the Bootloader start address doesn't change, because there is no way to change that.

There is a change in the bootloader settings format. Bootloaders from nRF5 SDK v15.2.0 and earlier use bootloader settings version 1, while those from v15.3.0 and later only support bootloader settings version 2. You will need to enable backward compatibility for the old settings version.

Another thing to check is to make sure the new application is compatible with the old application's persistent data. You can check this by flashing without erase the SoftDevice, bootloader, and application individually on a device running the old setup, with existing data. A device from the field would be best. A test device running the hex dump from a device from the field should be equally good. An entirely new test device should also work.

Finally, I didn't know updating BL + SD + App all at once was possible. However, if that is too big to do, you can update BL + SD first, then application, as mentioned in the documents linked above.

I hope that helps.

Hieu

[ms360]

Sorry I meant I'd like to upgrade to SD v7.2.0. I'm using SDK 17.1.0 

[Hieu]

I can't think of a reason why you would meet SD version check failed like this...

Can you retry with only 0x9D for --sd-req?

[ms360]

So this was unexpected, just specifying 0x9d yielded the same result!
As if it concatenates --sd-req and --sd-id

DFU failed again. 

nrfutil pkg generate --hw-version 52 --app-boot-validation VALIDATE_ECDSA_P256_SHA256\

--sd-req 0x009D --bootloader _bootloader/bootloader_chc_v1.01.06.hex --bootloader-version 10106 \

--application _build/chc.hex --application-version 10425\

--key-file private.key --softdevice ../nRF5_SDK_17.1.0_ddde560-mirror/components/softdevice/s132/hex/s132_nrf52_7.2.0_softdevice.hex\

--sd-id 0x101 1.04.25_bl_v1.01.06.zip

|- Image count: 2

|

|- Image #0:

   |- Type: sd_bl

   |- Image file: sd_bl.bin

   |- Init packet file: sd_bl.dat

      |

      |- op_code: INIT

      |- signature_type: ECDSA_P256_SHA256

      |- signature (little-endian): b'01cbe4315a1a1f0dcda1b5f400de6c9213496ee29b576bf0ad1221c80651cccd1575fe9d2a1b8efe0eee18cfae6f456a75233741f46039419dccd907f906cbbe'

      |

      |- fw_version: 0x0000277A (10106)

      |- hw_version 0x00000034 (52)

      |- sd_req: 0x101, 0x9D

      |- type: SOFTDEVICE_BOOTLOADER

      |- sd_size: 149868

      |- bl_size: 23644

      |- app_size: 0

      |

      |- hash_type: SHA256

      |- hash (little-endian): b'ed4b49e552fe7d411a49c3e1a0ba7c82254515e2d5eaaa9b46e370dadd0052ec'

      |

      |- boot_validation_type: ['VALIDATE_GENERATED_CRC', 'VALIDATE_GENERATED_CRC']

      |- boot_validation_signature (little-endian): [b'', b'']

      |

      |- is_debug: False

[Hieu]

I notice the ZIP file name is exactly the same. Did the second command run actually create a new file?
It doesn't make sense that the ZIP package specifies both 0x9D and 0x101 as sd-req when you only pass just 0x9D.

Let's try something vastly different, 0x99 for sd-req, and 0x111 for sd-id?

[ms360]

That's coming from a makefile target, so the name is always the same (until version change).

So I did 

--sd-req 0x0099

--sd-id 0x0111

Its definitely concatenating them. 

|- Image #0:

   |- Type: sd_bl

   |- Image file: sd_bl.bin

   |- Init packet file: sd_bl.dat

      |

      |- op_code: INIT

      |- signature_type: ECDSA_P256_SHA256

      |- signature (little-endian): b'ffdbd34b5b16c4194e1d38b64f48410ff4f72bef6d7de85b4938ac0a744b49eb2f71cca6f9d5fff3551c288602abfb86b943d4e78bc4f5bc0e309c3a1f7ff887'

      |

      |- fw_version: 0x0000277A (10106)

      |- hw_version 0x00000034 (52)

      |- sd_req: 0x99, 0x111

[Hieu]

Right, then we are indeed sure that the tool combines sd-id into sd-req. On hindsight, that makes some sense.

I will have to reproduce this issue and investigate. I will keep you updated.

[ms360]

Thank you. This is the last big risk item on this project task. Any help is appreciated. 

[Hieu]

Hi ms360,

I was pulled into another assignment for a few days but have since returned and resumed looking into this.

I recreated a nRF5 SDK v14.2.0 and v17.1.0 setup, with bootloaders built in debug settings, printing out into UART.
The only difference is that I am using a nRF52840 DK instead of a nRF52 DK.

Currently, I am starting from a simpler case. The device is first flashed with only SDK v14.2.0 bootloader and SD, and I then attempt to update it with just the bootloader and SD from SDK v17.1.0.

With that setup, I have reproduced an issue, though I am not sure it is the same as yours. Refer to the log below:

<debug> app: Received calculate CRC
<info> dfu_req_handling: Before OP crc
<debug> app: Sending CRC: [0x60, 0x03, 0x01, 0:x000316AC, CRC:0xB6B733F5]
<debug> nrf_dfu_flash: Flash write success: addr=0x00053600, pending 1
<debug> app: Received execute object
<info> dfu_req_handling: Before OP execute
<info> dfu_req_handling: Valid Data Execute
<debug> nrf_dfu_settings: Writing settings...
<debug> nrf_dfu_settings: Erasing old settings at: 0x000FF000
<debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x000FF000, len=1 pages), queue usage: 2
<debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x000FF000, len=0x1B8 bytes), queue usage: 3
<info> dfu_req_handling: Doing postvalidate
<error> dfu_req_handling: Hash failure
<info> dfu_req_handling: Current bank is bank 0
<info> dfu_req_handling: Running SD version check ============== 
<warning> dfu_req_handling: SD major version numbers mismatch. Current app will be invalidated.Current: 0. New: 7.
<debug> nrf_dfu_settings: Writing settings...
<debug> nrf_dfu_settings: Erasing old settings at: 0x000FF000
<debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x000FF000, len=1 pages), queue usage: 4
<debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x000FF000, len=0x1B8 bytes), queue usage: 5
<debug> app: Sending Response: [0x4, 0xB]
<debug> nrf_dfu_flash: Flash write success: addr=0x00053680, pending 4
<debug> dfu_req_handling: Response sent.
<debug> app: Received: BLE_GAP_EVT_CONN_PARAM_UPDATE
<debug> app: conn_sup_timeout: 500
max_conn_interval: 6
min_conn_interval: 6
slave_latency 0
<debug> nrf_dfu_flash: Flash erase success: addr=0x000FF000, pending 3
<debug> nrf_dfu_flash: Flash write success: addr=0x000FF000, pending 2
<debug> nrf_dfu_flash: Flash erase success: addr=0x000FF000, pending 1
<debug> nrf_dfu_flash: Flash write success: addr=0x000FF000, pending 0
<debug> nrf_dfu_flash: This operation had a callback, calling back to 0x000F3455.
<debug> dfu_req_handling: All flash operations have completed.
<debug> dfu_req_handling: Starting reset timer.
<debug> dfu_req_handling: Attempting to reset the device.
<debug> app: In nrf_dfu_transports_close
<debug> app: num transports: 1
<debug> app: Shutting down BLE transport.
<debug> app: Disconnecting.
<debug> app: BLE transport shut down.
<debug> app: After nrf_dfu_transports_init
<debug> dfu_req_handling: Reset.
<info> app: Inside main
<debug> app: In nrf_bootloader_init
<debug> app: in weak nrf_dfu_init_user
<debug> app: In real nrf_dfu_init
<debug> nrf_dfu_settings: Running nrf_dfu_settings_init(sd_irq_initialized=false).
<debug> nrf_dfu_flash: Calling nrf_dfu_flash_init(sd_irq_initialized=false)...
<debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
<debug> app: Initializing the clock.
<debug> app: Enter nrf_dfu_continue
<error> app: Single: Invalid bank
<debug> app: Enter nrf_dfu_app_is_valid
<debug> app: Return false in valid app check
<debug> app: In nrf_dfu_transports_init
<debug> app: num transports: 1
<debug> app: Initializing BLE DFU transport
<debug> app: vector table: 0x000F1000
<debug> app: vector table: 0x000F1000
<debug> app: Error code - sd_softdevice_vector_table_base_set: 0x00000000
<debug> app: Enabling SoftDevice.
<warning> nrf_sdh_ble: RAM starts at 0x200027E0, can be adjusted to 0x20002128.
<warning> nrf_sdh_ble: RAM size can be adjusted to 0x3DED8.
<debug> app: SoftDevice enabled.
<debug> app: nrf_dfu_settings_adv_name_is_valid FALSE
<debug> app: Regular adv name

It seems I have a hash failure for some inexplicable reason ...

There is also a SD version warning that also doesn't make sense. The mismatch major version is expected, and the "current version" print is also incorrect.

Do these look like the issue you are having?

On the nRF Connect app's end, there doesn't seem to be any error.

I will continue to look into this.