USB-BLE Bootloader stuck unable to DFU after DFU process was interrupted

[m.li]

Hello,

We've recently updated our BLE-USB bootloader from using SDK v15.2.0 to v17.0.2 and noticed an issue. Our USB-BLE bootloader was created with the USB-serial bootloader as the base. We then added the ble transport files, soft-device-related files, and relevant sdk config flags on top.

We call the USB-serial dfu in nrfutil using the following command:

nrfutil dfu usb-serial -pkg package.zip -p COM75

When we interrupt the nrfutil dfu (e.g. through keyboard interrupt), the device bootloader will get stuck in a state where subsequent dfu attempts through nrfutil will not go through and output this error message:

File "C:\Python27\Scripts\nrfutil-script.py", line 11, in <module>
load_entry_point('nrfutil==5.1.0', 'console_scripts', 'nrfutil')()
File "C:\Python27\lib\site-packages\click-7.1.2-py2.7.egg\click\core.py", line 829, in __call__
return self.main(*args, **kwargs)
File "C:\Python27\lib\site-packages\click-7.1.2-py2.7.egg\click\core.py", line 782, in main
rv = self.invoke(ctx)
File "C:\Python27\lib\site-packages\click-7.1.2-py2.7.egg\click\core.py", line 1259, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "C:\Python27\lib\site-packages\click-7.1.2-py2.7.egg\click\core.py", line 1259, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "C:\Python27\lib\site-packages\click-7.1.2-py2.7.egg\click\core.py", line 1066, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "C:\Python27\lib\site-packages\click-7.1.2-py2.7.egg\click\core.py", line 610, in invoke
return callback(*args, **kwargs)
File "C:\Python27\lib\site-packages\nrfutil-5.1.0-py2.7.egg\nordicsemi\__main__.py", line 1000, in usb_serial
timeout)
File "C:\Python27\lib\site-packages\nrfutil-5.1.0-py2.7.egg\nordicsemi\__main__.py", line 955, in do_serial
dfu.dfu_send_images()
File "C:\Python27\lib\site-packages\nrfutil-5.1.0-py2.7.egg\nordicsemi\dfu\dfu.py", line 129, in dfu_send_images
self._dfu_send_image(self.manifest.application)
File "C:\Python27\lib\site-packages\nrfutil-5.1.0-py2.7.egg\nordicsemi\dfu\dfu.py", line 102, in _dfu_send_image
self.dfu_transport.send_firmware(data)
File "C:\Python27\lib\site-packages\nrfutil-5.1.0-py2.7.egg\nordicsemi\dfu\dfu_transport_serial.py", line 301, in send_firmware
response['crc'] = self.__stream_data(data=data, crc=response['crc'], offset=i)
File "C:\Python27\lib\site-packages\nrfutil-5.1.0-py2.7.egg\nordicsemi\dfu\dfu_transport_serial.py", line 475, in __stream_data
response = self.__calculate_checksum()
File "C:\Python27\lib\site-packages\nrfutil-5.1.0-py2.7.egg\nordicsemi\dfu\dfu_transport_serial.py", line 413, in __calculate_checksum
raise NordicSemiException('Did not receive checksum response from DFU target. '
pc_ble_driver_py.exceptions.NordicSemiException: Did not receive checksum response from DFU target. If MSD is enabled on the target device, try to disable it ref. https://wiki.segger.com/index.php?title=J-Link-OB_SAM3U

The device's bootloader is stuck in this mode until we reflash it. We've tried using nrfutil on another computer but dfu still fails with this message. We've also tried this with nrfutil version 6.1.0.

We did not have this issue on the v15.2.0 bootloader. Is there something introduced in the latest SDK revisions since v15.2.0 that causes conflict between the USB and BLE dfu transports?

Thanks for your help.

[m.li]

Additional question: Is there a way to force the bootloader to restart the DFU from the start (i.e. no resuming) if it is interrupted during the DFU process?

Edit: I've found a workaround by changing nrf_bootloader_fw_activate() in nrf_bootloader_fw_activation.c:

    switch (p_bank->bank_code)
    {
...
        case NRF_DFU_BANK_INVALID:
        default:
            nrf_dfu_settings_progress_reset(); // Added to force a DFU progress reset if the DFU was interrupted
            NRF_LOG_INFO("No firmware to activate.");
            return ACTIVATION_NONE;
    }

Will this have unintended effects on the rest of the bootloader operations?

[Amanda Hsieh]

Hi, 

Sorry for the delay. 

Have you tried to disable the MSD class as the warning suggested (Disabling MSD - remember power-cycle at the end)?

Are you able to update successfully without the keyboard interrupt?

Can you provide the debug log while the error happened? 

What do you update? SD+BL or SD+BL+APP?

Please post the command you are using to generate the package.

See my explanation in this post. 

-Amanda

[m.li]

> Have you tried to disable the MSD class as the warning suggested (Disabling MSD - remember power-cycle at the end)?

We have tried to disable MSD on the J-Link but it did not make a difference. We are also not using the Development Kit.

> Are you able to update successfully without the keyboard interrupt?

Yes, the device is able to be DFU successfully when nrfutil is not interrupted.

> Can you provide the debug log while the error happened? 

We did not log yet as it is a bit difficult to get debug messages set up with the bootloader. Will update with the log when it is available.

> What do you update? SD+BL or SD+BL+APP?

We are only updating the Application.

> Please post the command you are using to generate the package.

We use this command to generate the DFU package:

nrfutil pkg generate --hw-version 52 --application-version 0 --application app.hex --sd-req 0x00 --sd-id 0x0100 --key-file ../NordicSDK/keys/private.key app_dfu_package.zip

Thanks for your reply.

[Amanda Hsieh]

Hi, 

Does the issue also happen to the unmodified SDK 15.2 bootloader? 

m.li said:

Yes, the device is able to be DFU successfully when nrfutil is not interrupted.

Can the application run successfully after DFU updating?

m.li said:

We did not log yet as it is a bit difficult to get debug messages set up with the bootloader. Will update with the log when it is available.

It's good to have log to know what happen on the device. 

m.li said:

We are only updating the Application.

What is the application? Does it require SD s140_nrf52_7.2.0 to run? Does the board already contain SD s140_nrf52_7.2.0 before DFU updating?

It seems you are running usb-bootloader based on SDK15.2 to update the application running with s140_nrf52_7.2.0. Is that right?

-Amanda

[Karlo]

Hi, i have same issue, when DFU process was interrupted DFU gets stuck and cant resume with update. It only happens when updating via USB (nrfutil).
Here is log

<warning> nrf_dfu_serial_usb: Could not read from CDC. Error: 0x92.
<debug> nrf_dfu_serial: Set receipt notif target: 0
<debug> nrf_dfu_serial_usb: Allocated buffer 20009D10
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_RECEIPT_NOTIF_SET
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<debug> nrf_dfu_serial: Sending Response: [0x2, 0x1]
<debug> nrf_dfu_serial: Received serial mtu
<debug> nrf_dfu_serial_usb: Allocated buffer 20009D10
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_MTU_GET
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<debug> nrf_dfu_serial: Sending Response: [0x7, 0x1]
<debug> nrf_dfu_serial_usb: Allocated buffer 20009D10
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_SELECT (command)
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<debug> nrf_dfu_serial: Sending Response: [0x6, 0x1]
<debug> nrf_dfu_serial_usb: Allocated buffer 20009D10
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_EXECUTE (command)
<debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
<info> nrf_dfu_settings: Backing up settings page to address 0xFE000.
source, write not needed. Skipping.
<debug> nrf_dfu_req_handler: Writing valid init command to flash.
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<debug> nrf_dfu_serial: Sending Response: [0x4, 0x1]
<debug> nrf_dfu_serial_usb: Allocated buffer 20009D10
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_SELECT (data)
<debug> nrf_dfu_req_handler: crc = 0x0, offset = 0x0, max_size = 0x1000
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<debug> nrf_dfu_serial: Sending Response: [0x6, 0x1]
<debug> nrf_dfu_serial_usb: Allocated buffer 20009D10
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_CREATE (data)
<debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x00027000, len=1 pages), queue usage: 0
<debug> nrf_dfu_req_handler: Creating object with size: 4096. Offset: 0x00000000, CRC: 0x00000000
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<debug> nrf_dfu_serial: Sending Response: [0x1, 0x1]
<debug> nrf_dfu_serial_usb: Allocated buffer 2000A514
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_WRITE (data)
<debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x00027000, src=0x20009D14, len=1024 bytes), queue usage: 1
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<debug> nrf_dfu_serial_usb: Allocated buffer 2000AD18
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_WRITE (data)
<debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x00027400, src=0x2000A518, len=1024 bytes), queue usage: 2
0x1
<error> nrf_dfu_serial_usb: Failed to allocate buffer!
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_WRITE (data)
<debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x00027800, src=0x2000AD1C, len=1024 bytes), queue usage: 3
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<error> nrf_dfu_serial_usb: Failed to allocate buffer!
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_WRITE (data)
<error> nrf_dfu_req_handler: Write request too long
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x3
<warning> nrf_dfu_serial: DFU request completed with result: 0x3
<debug> nrf_dfu_flash: Flash erase success: addr=0x00027000, pending 3
<debug> nrf_dfu_flash: Flash write success: addr=0x00027000, pending 2
<debug> nrf_dfu_flash: Flash write success: addr=0x00027400, pending 1
<debug> nrf_dfu_flash: Flash write success: addr=0x00027800, pending 0