• State Verified Answer
  • Replies 42 replies
  • Subscribers 62 subscribers
  • Views 9161 views
  • Users 0 members are here
Attachments (12) Download All
Nordic Case Info
  • Case ID: 223383
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

DFU example

DeveloperZ

Hi,

I am trying to implement the DFU example from Mesh 3.1.0SDK and 15.2.0 SDK. I am following the process mentioned here.

I am using a MacOS for development.

I am able to execute steps 1 through 9 successfully but when I execute step 10, it says:

command - nrfutil dfu serial -pkg dfu_test.zip -p usbmodem0006829949971 -b 115200 -fc --mesh

Upgrading target on usbmodem0006829949971 with DFU package /Users/xxx/xxx/xxx/xxx/dfu_test.zip. Flow control is enabled.

Failed to upgrade target. Error is: Serial port could not be opened on usbmodem0006829949971. Reason: 

Possible causes:

- bootloader, SoftDevice or application on target does not match the requirements in the DFU package.

- baud rate or flow control is not the same as in the target bootloader.

- target is not in DFU mode. If using the SDK examples, press Button 4 and RESET and release both to enter DFU mode.


I am guessing that the possible reason would be the third one i.e target isn't in the DFU mode. I am not completely sure.

What might be the reason for this dfu failure?

Thank you.

Parents
  • 0

    Hello,

    Can you please try to add the following when you call the nrfutil scripts:

    Instead of e.g. nrfutil --verbose dfu serial -pkg dfu_test.zip -p usbmodem0006829949971 -b 115200 -fc --mesh

    can you try to use the full path to the COM port:

    nrfutil --verbose dfu serial -pkg dfu_test.zip -p /dev/tty.usbmodem0006829949971 -b 115200 -fc --mesh

    It worked for someone else having some problems with Mac and nrfutil.

    BR,

    Edvin

  • 0 in reply to Edvin

    Hi

    Edvin said:
    nrfutil --verbose dfu serial -pkg dfu_test.zip -p /dev/tty.usbmodem0006829949971 -b 115200 -fc --mesh

    This command worked. It opened the serial port and it took around 10 minutes trying to do dfu and finally it failed. The response is as follows:

    Upgrading target on /dev/tty.usbmodem0006829949971 with DFU package /Users/developerbubblynet/Desktop/MeshSDK/dfu_MeshSDK310/dfu_test.zip. Flow control is enabled.

    Flushing com-port...

    Opened com-port

    Starting DFU upgrade of type 4, SoftDevice size: 0, bootloader size: 0, application size: 2468

    Sending DFU start packet, afterwards we wait for the flash on target to be initialized before continuing.

    PC -> target: 0502aabbccdd

    PC -> target: 0502aabbccdd

    PC -> target: 0502aabbccdd

    PC -> target: 0502aabbccdd

    PC -> target: 0502aabbccdd

    Failed to upgrade target. Error is: Failed to establish connection

    Possible causes:

    - bootloader, SoftDevice or application on target does not match the requirements in the DFU package.

    - baud rate or flow control is not the same as in the target bootloader.

    - target is not in DFU mode. If using the SDK examples, press Button 4 and RESET and release both to enter DFU mode.

    Closing serial port...

    The line PC -> target: 0502aabbccdd prints every 2/3 minutes and finally after 10 minutes or more, it failed.

  • 0 in reply to DeveloperZ

    Hello,

    I see that your application is running, I can see it from the log. However, if you add --verbose to your DFU command:
    nrfutil-mesh --verbose dfu serial -pkg dfu_test.zip -p COM7 -b 115200 --mesh

    (obviously with your own COM port), you will see that it says:

    Your application log says:

    0> <t: 1>, main.c, 206, ----- Bluetooth Mesh DFU Example -----
    0> <t: 8818>, serial_handler_prov.c, 267, Generating encryption keypair...
    0> <t: 13706>, main.c, 224, Initialization complete!
    0> <t: 18474>, main.c, 245, Enabling serial interface...
    0> <t: 18477>, mesh_app_utils.c, 65, Device UUID (raw): 464B4596FD473049936CE0FE34C4D5FD
    0> <t: 18480>, mesh_app_utils.c, 70, Device UUID : 96454B46-47FD-4930-936C-E0FE34C4D5FD
    0> <t: 18488>, nrf_mesh_dfu.c, 528, RADIO TX! SLOT 0, count 255, interval: periodic, handle: FFFE
    0> <t: 18493>, nrf_mesh_dfu.c, 561, SERIAL TX!
    0> <t: 18500>, main.c, 253, DFU example started!

    (RTT Log read using J-Link RTT Viewer).

    The "--verbose output from nrfutil --verbose dfu serial -pkg dfu_test.zip -p COM7 -b 115200 --mesh" suggests that there are some issues with getting a response from the serial connection. Did you change the UART pins in the application?

    Best regards,

    Edvin

  • 0 in reply to Edvin

    Hi,

    Edvin said:
    Did you change the UART pins in the application?

    Yes, I noticed that I changed the UART pin configuration. Now, I set them back to the original configuration and tried to push the DFU but the result is the same as what you saw.

  • 0 in reply to DeveloperZ

    What HW are you trying this on? Are you using a DK? Can you show me the log output and the terminal output when you try to push the DFU? Did you also reprogram the DK after changing the UART pins?

  • 0 in reply to Edvin
    Edvin said:
    What HW are you trying this on? Are you using a DK?

    Yes, I am using an nRF52 development kit.

    Edvin said:
    Can you show me the log output and the terminal output when you try to push the DFU?

    Edvin said:
    Did you also reprogram the DK after changing the UART pins?

    Yes, I repeated the whole process again with a new Mesh SDK

  • 0 in reply to DeveloperZ

    Ok. I don't know why it is not working. Can you describe how you changed the Serial interface when you changed the UART pins? Did you turn off flow control?

    Can you send the updated hex files with the correct UART settings? The previous version wasn't working, I can confirm that. But there has to be something that you have either changed, or done correctly when following the guide. Was there some part of the guide that you were uncertain of, where you may have done something incorrectly?

    I am really trying to understand why it isn't working, but all I can see from the information you describe is that the board isn't responding, so at this point, anything could be the source of the issue.

    BR,

    Edvin

Reply
  • 0 in reply to DeveloperZ

    Ok. I don't know why it is not working. Can you describe how you changed the Serial interface when you changed the UART pins? Did you turn off flow control?

    Can you send the updated hex files with the correct UART settings? The previous version wasn't working, I can confirm that. But there has to be something that you have either changed, or done correctly when following the guide. Was there some part of the guide that you were uncertain of, where you may have done something incorrectly?

    I am really trying to understand why it isn't working, but all I can see from the information you describe is that the board isn't responding, so at this point, anything could be the source of the issue.

    BR,

    Edvin

Children
Related