• State Verified Answer
  • Replies 5 replies
  • Subscribers 74 subscribers
  • Views 2854 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 206696
Options
Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

Parents
  • 0

    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

Reply
  • 0

    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

Children
  • 0 in reply to tesc

    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

  • 0 in reply to tesc

    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.

Related
Terms of service