Unable to run Secure DFU boot loader update using SDK 17.1

RE: Unable to run Secure DFU boot loader update using SDK 17.1

RVM — Sat, 30 Aug 2025 02:29:51 GMT

Visiting this in 2025 and I notice that while you select to use the SoftDevice S140 when creating the bootloader, but you select the SoftDevice S132 when creating the DFU update package.

Is that intentional?

RE: Unable to run Secure DFU boot loader update using SDK 17.1

KTM — Wed, 24 Aug 2022 11:54:57 GMT

I was using by mistake a CC310 without interrupts version and that is why there was a crash i guess

My fault

RE: Unable to run Secure DFU boot loader update using SDK 17.1

Hung Bui — Thu, 18 Aug 2022 09:27:07 GMT

Hi Igor,
Thanks for the information and the sniffer trace.
From what I can see in the log and the trace, I suspect that the bootloader crashed at some point right after the execute command (0x04) from the central when the init packet is sent. You can see the sequence here:
https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.1.0/lib_dfu_transport_ble.html?cp=8_1_3_5_2_2_3_0#lib_dfu_transport_msc_init

In the sniffer trace you can see that there was no response after the command (0x04) :

Because there was no response after the write request, you receives a GATT ERROR.

What you can do is to check if the same problem can be reproduced on the stock bootloader example. Please try to test without the application, only softdevice + bootloader.

Do you use WDT in your application ? If you do have there could be a chance that the WDT was not handled properly in the bootloader and cause a reset.

If you can reproduce the issue on an unmodified bootloader (test without application ) we can test here and check if there is any problem with it. Please also do a cross check with the unmodified bootloader from SDK v17.0 .

RE: Unable to run Secure DFU boot loader update using SDK 17.1

KTM — Thu, 18 Aug 2022 09:09:50 GMT

I continued a debug and finally managed to upload through a DFU an application...The problem was that i used libnrf_cc310_bl_0.9.13 from no-interrupts folder and used the following command line:

nrfutil pkg generate --hw-version 52 --application-version 1 --application ble_app_uart_pca10040_s132.hex --sd-req 0x101 --key-file private.key oxitone_dfu_package.zip

While the correct command is:

nrfutil pkg generate --hw-version 52 --application-version 1 --application ble_app_uart_pca10040_s132.hex --sd-req 0x100 --key-file private.key oxitone_dfu_package.zip

However still have a problem.

After a download an application is not running since probably SD is erased - i read a memory through NRF programmer and SD does not appear to be there at all...

Does above command line generates an application package only ?

RE: Unable to run Secure DFU boot loader update using SDK 17.1

KTM — Thu, 18 Aug 2022 08:31:05 GMT

and here is an air trace (btt file) that is related to the my today's reply (logs from device and Android phone)devzone.nordicsemi.com/.../dfu.btt

RE: Unable to run Secure DFU boot loader update using SDK 17.1

KTM — Thu, 18 Aug 2022 08:21:28 GMT

I have tried the same thing that you suggested with debug version and able to observe logs. (BTW I replaced libnrf_cc310_bl_0.9.13 from original to the nRF5_SDK_17.1.0_ddde560\nRF5_SDK_17.1.0_ddde560\external\nrf_cc310_bl\lib\cortex-m4\hard-float\no-interrupts\ library since i use IAR 8 and hit wchar error on linkage).

Here is a device side Log (From RTT):

<debug> nrf_dfu_settings: Erasing old settings at: 0x000FF000

<debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x000FF000, len=1 pages), queue usage: 0

<debug> nrf_dfu_flash: Flash erase success: addr=0x000FF000, pending 0

<debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x000FF000, src=0x2000A298, len=896 bytes), queue usage: 1

<debug> nrf_dfu_flash: Flash write success: addr=0x000FF000, pending 0

<info> nrf_dfu_settings: Backing up settings page to address 0xFE000.

<debug> nrf_dfu_settings: Writing settings...

<debug> nrf_dfu_settings: Erasing old settings at: 0x000FE000

<debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x000FE000, len=1 pages), queue usage: 1

<debug> nrf_dfu_flash: Flash erase success: addr=0x000FE000, pending 0

<debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x000FE000, src=0x20005A1C, len=896 bytes), queue usage: 1

<debug> nrf_dfu_flash: Flash write success: addr=0x000FE000, pending 0

<debug> app: Enter nrf_bootloader_fw_activate

<info> app: No firmware to activate.

<info> app: Boot validation failed. No valid app to boot.

<debug> app: DFU mode because app is not valid.

<info> nrf_bootloader_wdt: WDT is not enabled

<debug> app: in weak nrf_dfu_init_user

<debug> app: timer_stop (0x20005978)

<debug> app: timer_activate (0x20005978)

<info> app: Entering DFU mode.

<debug> app: Initializing transports (found: 1)

<debug> nrf_dfu_ble: Initializing BLE DFU transport

<debug> nrf_dfu_ble: Setting up vector table: 0x000F1000

<debug> nrf_dfu_ble: Enabling SoftDevice.

<debug> nrf_dfu_ble: Configuring BLE stack.

<debug> nrf_dfu_ble: Enabling the BLE stack.

<debug> nrf_dfu_ble: No advertising name found

<debug> nrf_dfu_ble: Using default advertising name

<debug> nrf_dfu_ble: Advertising...

<debug> nrf_dfu_ble: BLE DFU transport initialized.

<debug> nrf_dfu_flash: Initializing nrf_fstorage_sd backend.

<debug> app: Enter main loop

<debug> nrf_dfu_ble: Connected

<debug> nrf_dfu_ble: Received BLE_GAP_EVT_CONN_PARAM_UPDATE

<debug> nrf_dfu_ble: max_conn_interval: 12

<debug> nrf_dfu_ble: min_conn_interval: 12

<debug> nrf_dfu_ble: slave_latency: 0

<debug> nrf_dfu_ble: conn_sup_timeout: 600

<debug> nrf_dfu_ble: Received BLE_GAP_EVT_CONN_PARAM_UPDATE

<debug> nrf_dfu_ble: max_conn_interval: 6

<debug> nrf_dfu_ble: min_conn_interval: 6

<debug> nrf_dfu_ble: slave_latency: 0

<debug> nrf_dfu_ble: conn_sup_timeout: 500

<debug> nrf_dfu_ble: Received BLE_GAP_EVT_CONN_PARAM_UPDATE

<debug> nrf_dfu_ble: max_conn_interval: 12

<debug> nrf_dfu_ble: min_conn_interval: 12

<debug> nrf_dfu_ble: slave_latency: 0

<debug> nrf_dfu_ble: conn_sup_timeout: 600

<debug> nrf_dfu_ble: Received BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST (request: 517, reply: 247).

<debug> nrf_dfu_ble: Received BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST.

<debug> nrf_dfu_ble: Received BLE_GAP_EVT_DATA_LENGTH_UPDATE (27, max_rx_time 2120).

<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_SELECT (command)