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.

[Edvin]

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

[DeveloperZ]

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.

[DeveloperZ]

Yes, I was able to program every file(softdevice, boot loader, application, device page) with nrfjprog but boot loader verification hangs!!!

[Edvin]

Can you send the hex files here? I would like to try.

Also, you may try using the nRF Programmer, which is part of nRF Connect 2 for Desktop. Maybe it gives some more information on why it isn't working.

BR,

Edvin

[DeveloperZ]

Hi, I have put the hex files and the Blinky dfu packet in this folder here. Please let me know if you need any other files. 

Edvin said:

you may try using the nRF Programmer, which is part of nRF Connect 2 for Desktop

Okay, I will try and let you know the update.

Thank you.

[Edvin]

You can upload it here on devzone. Just click insert -> image/video/file

[DeveloperZ]

Hi,

Sorry about that. I added the files below:

device_page_nrf52832_xxAA_s132_6.1.0.hex

dfu_nrf52832_xxAA_s132_6.1.0.hex

mesh_bootloader_serial_gccarmemb_nrf52832_xxAA.hex

s132_nrf52_6.1.0_softdevice.hex

5074.dfu_test.zip

[Edvin]

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

[DeveloperZ]

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.

[Edvin]

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?

[DeveloperZ]

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

[Edvin]

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