Update Softdevice via DFU (2025 update)

RE: Update Softdevice via DFU (2025 update)

Hieu — Sat, 11 Oct 2025 16:44:06 GMT

Huh, interesting. That is the default address of the bootloader with debug options and RTT logging enabled. Do you think your bootloader maybe already have logging?

In any cases, unless your application has some data between 0x71000 and 0x73000, the bootloader starting at 0x71000 shouldn't really matter.

If necessary, you can also change the start address back to 0x73000. It just means that we can't test with the debug version of the SDK v17.1.0 bootloader.
Here is the same project I edited to start at 0x73000.

devzone.nordicsemi.com/.../p01_5F00_bl_2D00_dbg_5F00_uart.zip

As for sending over the application, that works too, as long as it can run on a nRF52840 DK. You can open a private case, with a link to this one, and ask it to be assigned to me.

I am out of office on Monday but will return on Tuesday.

RE: Update Softdevice via DFU (2025 update)

ms360 — Sat, 11 Oct 2025 15:14:15 GMT

My bootloader starts at 0x73000. I don't think this will work.
I'm happy to share my project privately off forum.

RE: Update Softdevice via DFU (2025 update)

Hieu — Fri, 10 Oct 2025 20:37:18 GMT

Here is the v14.2.0 SDK bootloader project, with the nRF52832 Debug target that I have modified to start at 0x71000 (where the v17.1.0 debug-build bootloader starts) and log over UART. Perhaps that would help?

devzone.nordicsemi.com/.../p01_5F00_bl_2D00_dbg_5F00_uart_2D00_addr_5F00_shifted.zip

As for the application, I think either yours or the ble_app_buttonless_dfu example would work. Perhaps your project would be better for reproduction?

RE: Update Softdevice via DFU (2025 update)

ms360 — Fri, 10 Oct 2025 17:35:00 GMT

I would have to build a debug bootloader from scratch on a v14.2.0 SDK.
The thing is I'm stuck with whatever this deployed version is, so if its not a mostly stock bootloader, I may run into some problems.

I'll reach out to the original engineer and see if I can get some more information.

RE: Update Softdevice via DFU (2025 update)

Hieu — Thu, 09 Oct 2025 21:38:01 GMT

Right, after I got your response, I changed priority to verify the workaround by updating only SD + BL to v17.1.0 first. After a little blundering, I got things to work now, in this order:

Starting with: nRF5 SDK v14.2.0 SD + BL + App
DFU nRF5 SDK v17.1.0 SD + BL
DFU nRF5 SDK v17.1.0 App

Basically, the workaround is proven.

However, this also means I cannot reproduce the issue you are having.

Are you able to setup a test device with debug bootloader and see more information from within the bootloader?

RE: Update Softdevice via DFU (2025 update)

ms360 — Wed, 08 Oct 2025 17:42:12 GMT

Here is the log from my BL+SD DFU test

devzone.nordicsemi.com/.../mtF-1.txt

RE: Update Softdevice via DFU (2025 update)

ms360 — Wed, 08 Oct 2025 17:30:52 GMT

Thanks Hieu! Seems like we have a path forward.

[quote userid="9456" url="~/f/nordic-q-a/124565/update-softdevice-via-dfu-2025-update/550852"]

Nonetheless, this presents us with a workaround: you could DFU BL+SD first, and then APP later. Is this acceptable?

[/quote]

I tried this a few weeks ago and got a similar failure. I will follow up with logs when I get a chance. It would be acceptable if this could work.

[quote userid="9456" url="~/f/nordic-q-a/124565/update-softdevice-via-dfu-2025-update/550852"]

Another workaround would be to manually decode the .dat file in the package, edit the sd_req field for the BL+SD image, then re-encode it and repackage it.

[/quote]

This would also be acceptable as this would hopefully be a one time thing. Is it just a hex edit? do I need to change a checksum as well? Is it a manual re-encoding, then just a zip?

RE: Update Softdevice via DFU (2025 update)

Hieu — Wed, 08 Oct 2025 00:31:11 GMT

Hi ms360,

It looks like my previous log was from an accident. I couldn't reproduce it anymore.

Turns out that the nRF52840 cannot have bootloader updated with its S140 v5.0.0-2.alpha, so I had to recreate everything on a nRF52832 environment.

With that, I now reproduced the issue and has started to see some clues. It looks like that even though the package would include 2 sd-req entries, at the checking step, the count is only 1, so it only checks the first entry, which is 0x101, and would fail.

I am trying to figure out if that is an issue from the mobile app DFU library or from the command parsing of the bootloader.

It doesn't seem possible to switch the order of the sd-req entries in the package with nrfutil either. It also doesn't make sense to me why the BL+SD image part would need to include the application's SD requirement...

Nonetheless, this presents us with a workaround: you could DFU BL+SD first, and then APP later. Is this acceptable?

Another workaround would be to manually decode the .dat file in the package, edit the sd_req field for the BL+SD image, then re-encode it and repackage it.

Beyond that, I am also having a signature failure issue for some unknown reason... I didn't have that with the nRF52840 project with the exact same source code and key pair, so that is another mystery to figure out. But the focus now is to figure out this SD requirement issue.

To be sure you will not have this same signature issue, could you please try to DFU only BL+SD first, regardless of whether or not you could do that for your final project?

RE: Update Softdevice via DFU (2025 update)

ms360 — Mon, 06 Oct 2025 17:21:02 GMT

Thanks Hieu.
I don't have space to enable RTT logging in these bootloaders so I've been running blind there.
It looks like you're also failing the valid app check, that's definitely different.

Here is the entire nrf connect DFU attempt log

devzone.nordicsemi.com/.../XmtF.txt

RE: Update Softdevice via DFU (2025 update)

Hieu — Sun, 05 Oct 2025 22:49:45 GMT

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.

RE: Update Softdevice via DFU (2025 update)

ms360 — Mon, 29 Sep 2025 16:33:44 GMT

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

RE: Update Softdevice via DFU (2025 update)

Hieu — Mon, 29 Sep 2025 16:29:29 GMT

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.

RE: Update Softdevice via DFU (2025 update)

ms360 — Fri, 26 Sep 2025 18:25:03 GMT

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

RE: Update Softdevice via DFU (2025 update)

Hieu — Fri, 26 Sep 2025 17:10:26 GMT

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?

RE: Update Softdevice via DFU (2025 update)

ms360 — Fri, 26 Sep 2025 14:22:31 GMT

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

RE: Update Softdevice via DFU (2025 update)

Hieu — Fri, 26 Sep 2025 12:05:27 GMT

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?

RE: Update Softdevice via DFU (2025 update)

ms360 — Wed, 24 Sep 2025 22:23:00 GMT

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

RE: Update Softdevice via DFU (2025 update)

ms360 — Wed, 24 Sep 2025 22:11:24 GMT

Thanks Hieu.

I'm running into "SD version check failed", I had to use nrf connect to get the verbose failure.

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

--sd-req "0x101","0x9D" --bootloader /Users/mike/p/_bootloader/bootloader_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 _binaries/chc_1.04.25_bl_v1.01.06.zip

Zip created at _binaries/chc_1.04.25_bl_v1.01.06.zip

Checking the SD version, I see 0x9d via nrfjprog.

mike@slavebox HC % nrfjprog --familly NRF52 --memrd 0x0000300C

0x0000300C: FFFF009D |....|

Checking the DFU package, I can see sd_req is right for the bootloader update

DFU Package: <_binaries/chc_1.04.25_bl_v1.01.06_2.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'fb3b9dab932a7c76ea11a660ca17c1eafad08fdb7f2474076853d656475167482f8e4eebb1618f8b496f72ea3177a27b05d18bb9d2ce41c084ae0c82a711ae4a'

|

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

|

|- Image #1:

|- Type: application

|- Image file: chc.bin

|- Init packet file: chc.dat

|

|- op_code: INIT

|- signature_type: ECDSA_P256_SHA256

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

|

|- fw_version: 0x000028B9 (10425)

|- hw_version 0x00000034 (52)

|- sd_req: 0x101

|- type: APPLICATION

|- sd_size: 0

|- bl_size: 0

|- app_size: 149528

|

|- hash_type: SHA256

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

|

|- boot_validation_type: ['VALIDATE_ECDSA_P256_SHA256']

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

|

|- is_debug: False

RE: Update Softdevice via DFU (2025 update)

Hieu — Wed, 24 Sep 2025 14:02:35 GMT

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