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.

[Edvin]

Hello,

Well, yes and no. The issue is the signing of the application that is flashed when you program the device via an IDE. IDEs doesn't use the .hex file, but rather the .out file to be able to debug the application. When using this file, the key that was used in the settings page will change the CRC of the application, and the bootloader will not validate it as a valid application (it believes that someone has messed with/changed the Firmware). If this is what you have done, then that is probably why the application is not responding to the serial messages, because the application is not running. Try to flash your .hex files using nrfjprog, and see whether that works better.

You can download it here:

https://www.nordicsemi.com/Software-and-Tools/Development-Tools/nRF5-Command-Line-Tools

Best regards,

Edvin.

[DeveloperZ]

Hey,

No, I have been using nrfjprog only to perform the dfu.

Also, any idea on why the boot loader verification is hung up at Resetting Device..

Reading UICR.. OK.

Reading Device page.. OK.

Resetting device..

[Edvin]

So can you try to use nrfjprog to program all the files?

[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.