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,

The 0502aabbccdd is an echo command to see that the serial device is responding, something it was not. 

You can see the list over serial commands and serial events here:

https://www.nordicsemi.com/DocLib/Content/SDK_Doc/Mesh_SDK/v3-0-0/md_doc_libraries_serial_cmd#device-echo

The first byte (05) is the length of the packet (excluding this byte itself), and the second byte is the OPcode. 02 means echo, and the rest of the bytes is the bytes that the device is supposed to echo back.

Have you reset the device after programming it (using nrfjprog)? "nrfjprog --reset" should do the trick. If not, there is something wrong with the application, the bootloader, or possibly the device page that you have flashed. Can you try to run the 

python bootloader_verify.py 682994997 usbmodem0006829949971

command with the dev/tty. part in front of the usbmodem########?

The DFU guides are a bit tricky, because everything has to be done exactly correct for it to work. What I really recommend that you do is to write a script that compiles, generates the device page, erases the chip, programs the softdevice + bootloader + application + device page, resets the device, and then you can try to perform the dfu. I usually do a .bat script (windows), but you should be able to write a .sh script doing basically the same things.

One of these scripts that I have made is a file called test.bat, and looks like this:

make

nrfutil-mesh dfu genpkg --application _build\nrf52832_xxaa.hex --company-id 0x00000059 --application-id 1 --application-version 2 --key-file keys\private_key.txt --sd-req 0x00AF --mesh dfu_test2.zip
nrfutil-mesh dfu genpkg --application _build\nrf52832_xxaa.hex --company-id 0x00000059 --application-id 1 --application-version 3 --key-file keys\private_key.txt --sd-req 0x00AF --mesh dfu_test3.zip


cd tools\dfu
python device_page_generator.py -d nrf52832_xxAA -sd "s132_6.1.0"
cd ..\..

nrfjprog -e --snr 682654319
nrfjprog --program ..\..\nRF5_SDK_15.2.0_9412b96\components\softdevice\s132\hex\s132_nrf52_6.1.0_softdevice.hex --verify --snr 682654319
nrfjprog --program ..\bin\bootloader\gccarmemb\mesh_bootloader_gccarmemb_nrf52832_xxAA.hex --snr 682654319
nrfjprog --program _build\nrf52832_xxaa.hex --verify --snr 682654319
nrfjprog --program tools\dfu\bin\device_page_nrf52832_xxAA_s132_6.1.0.hex --verify --snr 682654319
nrfjprog --reset --snr 682654319

TIMEOUT 5

nrfutil-mesh --verbose dfu serial -pkg dfu_test2.zip -p COM7 -b 115200 -fc --mesh

Exactly this script uses an armgcc compiler, so you would of course replace "make" with manually compiling your application project. Another thing this script doesn't do is to insert the private and public key like step number 1 and 2 in the guide tells you. You must do this manually.

What you also can do to check whether your application is running is to have some logging (which the example from the guide has). Check out whether anything is logged using "RTT Viewer" from J-Link to see that your application is actually running before you start the DFU update.

BR,

Edvin

[DeveloperZ]

Hi,

Edvin said:

I usually do a .bat script (windows), but you should be able to write a .sh script doing basically the same things.

I will try this out and let you know once done. 

Edvin said:

python bootloader_verify.py 682994997 usbmodem0006829949971

This command hangs up at Resetting device.. as follows:

Reading UICR.. OK.

Reading Device page.. OK.

Resetting device..

[DeveloperZ]

Hey,

I have another question. Can't we use Segger IDE to flash the dfu code onto the board, flash the device page, reset the board and then run the DFU command? instead to executing the commands and flashing the board from command line

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