Bootloader and nRF Connect can't resume DFU

[Cyril]

Hello,

I'm testing the bootloader with SDK v.15 and I found a state when DFU won't resume (on BLE transport).

I crashed nRF Connect randomly, in that case, between the first and second object. Here is the log:

<debug> app: Shutting down transports (found: 1) // BLE disconnected from remote
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_CREATE (data) // Second block creation
<debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x00051000, len=1 pages), queue usage: 0
<debug> nrf_dfu_req_handler: Creating object with size: 4096. Offset: 0x00001000, CRC: 0x1B4AC781
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<debug> nrf_dfu_flash: Flash erase success: addr=0x00051000, pending 0
<debug> nrf_dfu_ble: Advertising...

Then, it won't resume, even after reset, here is the log pointing out the error:

<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_EXECUTE (command)
<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: 0
<debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x000FF000, src=0x2000A7C0, len=440 bytes), queue usage: 1
<debug> nrf_dfu_req_handler: Writing valid init command to flash.
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<debug> nrf_dfu_ble: Set receipt notif
<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_req_handler: Handle NRF_DFU_OP_OBJECT_SELECT (data)
<debug> nrf_dfu_req_handler: crc = 0x1B4AC781, offset = 0x1000, max_size = 0x1000
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<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_req_handler: Handle NRF_DFU_OP_OBJECT_EXECUTE (data)
<error> nrf_dfu_req_handler: Invalid data. expected: 4096, got: 0
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x8
<warning> nrf_dfu_ble: DFU request 4 failed with error: 0x8

The issue is that s_dfu_settings.progress.firmware_image_offset equals s_dfu_settings.progress.firmware_image_offset_last.

Do you have any idea how to fix that issue?

That issue looks critical as I simply can't resume the DFU if I try to send the same package. Here is a screenshot of nRF Connect:

Let me know if you have more question.

Best

[Cyril]

This bug can be reproduced quite easily, I killed nRF Connect for Android while performing the upgrade and after several times, I got the same bug.

[tesc]

Hi,

First, I am sorry for the late response on this one.

Reading between the lines it looks like you get it to work if you provide a different DFU package from the one you used when it fails. Can you confirm that?

Can you provide a hex dump from when this has happened? ("nrfjprog --readcode filename.hex" for dumping the flash contents to a file named "filename.hex".) If you do not want to share this publicly then please create a private ticket and refer to this thread.

Regards,
Terje

[Cyril]

Hello,

Also sorry for the delay, I'm not totally focused on the bootloader right now...

Correct, if I provide a different DFU package it works (bootloader settings are not re-used).

I tried to replicate the bug using the examples you provide along with nRF Connect for Android (OnePlus 3T and OnePlus 6). I flashed my PCA10056 with the secure BLE bootloader and tried to upload the example image (hrs_application_s140.zip). I killed nRF Connect while uploading the image and after a few tests, I had the same bug.

More information

- It seems to appear when the bootloader doesn't reset at all after being disconnected: advertising resumes as expected, then I re-connect and try to send the same image, and got OPERATION_NOT_PERMITTED.
Then even if it resets several times, I'm not able to send the same image and got OPERATION_NOT_PERMITTED each time I try to send the image.
- But, if after being disconnected during upload, it resumes advertising but then reset (before reconnected and trying to send the image), the bug is not present anymore. Probably a variable not being reset correctly when disconnected.

One workaround in the short-term would be to reset the bootloader when disconnected.

Best

[Cyril]

Another weird thing is that the BLE disconnection is not always notified to nrf_dfu_ble.c (event BLE_GAP_EVT_DISCONNECTED).
When not notified, we have to wait for the bootloader watchdog to reset the bootloader which is, to my mind, too long to resume DFU.

[tesc]

Hi,

Thanks to your report and detailed descriptions our software engineers have identified an issue: If the DFU is aborted at one particular moment, in-between two objects, it may enter the state that you are experiencing.

It only happens on disconnect + reconnect, as that does not trigger a reset of the DFU target.

The problem is that the connection is lost immediately after a create_object, and when the connection is reestablished the DFU controller performs an execute before resuming the update. They propose fixing it by resetting the settings on disconnect, either through (a potentially modified) nrf_dfu_settings_init(), or as you suggested by doing a reset.

Regards,
Terje