I'm attempting Mesh DFU on an Ubuntu 16.04 system. Here are the steps in the quick start guide along with corresponding notes on my setup:
nrfutil keys --gen-key private_key.txt -> Key stored in the mesh src code home directory - .../nrf5_SDK_for_Mesh_v2.0.1_src/private_key.txt
nrfutil keys --show-vk hex private_key.txt -> Stored public key in .json file: .../nrf5_SDK_for_Mesh_v2.0.1_src/tools/dfu/bootloader_config_default.json (application version = 1)
DFU package generation: (a) Modifed in examples/dfu/flash_placement.xml, modifed line 32 to <MemorySegment name="RAM" start="$(RAM_PH_START)" size="$(RAM_SIZE)">
(b) At .../nrf5_SDK_for_Mesh_v2.0.1_src, ran mkdir build; cd build; cmake -GNinja -DTOOLCHAIN=gccarmemb -DPLATFORM=nrf52840_xxAA ..; ninja to build my examples.
(c) I verified on nRFGo Studio the softdevice for s140 shows up as 0x00A9.
Using that I generated the DFU package and device page for beaconing example application as follows:
nrfutil dfu genpkg --application ~/Nrf_sdk_code_base/nrf5_SDK_for_Mesh_v2.0.1_src/build/examples/beaconing/beaconing_nrf52840_xxAA_s140_6.0.0.hex --company-id 0x00000059 --application-id 1 --application-version 5 --key-file /home/shubhangi/Nrf_sdk_code_base/nrf5_SDK_for_Mesh_v2.0.1_src/private_key.txt --sd-req 0x00A9 --mesh ~/Nrf_sdk_code_base/nrf5_SDK_for_Mesh_v2.0.1_src/examples/beaconing/dfu_test4.zip.
python3 device_page_generator.py -d nrf52840_xxAA -sd "s140_6.0.0"
(d) On my target board, I ran (since my board is not connected to an active serial port I flashed the DFU application with no serial).
nrfjprog --eraseall; nrfjprog --program bin/softdevice/s140_6.0.0/s140_nrf52_6.0.0_softdevice.hex --chiperase; nrfjprog --program bin/bootloader/gccarmemb/mesh_bootloader_serial_gccarmemb_nrf52840_xxAA.hex; ./nrfjprog --program .../nrf5_SDK_for_Mesh_v2.0.1_src/build/examples/dfu/dfu_no_serial_nrf52840_xxAA_s140_6.0.0.hex; ./nrfjprog --program .../nrf5_SDK_for_Mesh_v2.0.1_src/tools/dfu/bin/device_page_nrf52832_xxAA_s132_5.0.0.hex; ./nrfjprog --reset
Finally, to perform the DFU, on a second development board (/dev/ttyACM1, on which I did not flash the software as above) connected to my PC, I ran
nrfutil --verbose dfu serial -pkg ~/Nrf_sdk_code_base/nrf5_SDK_for_Mesh_v2.0.1_src/examples/beaconing/dfu_test4.zip -p /dev/ttyACM1 -b 115200 -fc --mesh
And here is the log:Upgrading target on /dev/ttyACM1 with DFU package /home/shubhangi/Nrf_sdk_code_base/nrf5_SDK_for_Mesh_v2.0.1_src/examples/beaconing/dfu_test4.zip. Flow control is enabled. [------------------------------------] 0%Flushing com-port...Opened com-portStarting DFU upgrade of type 4, SoftDevice size: 0, bootloader size: 0, application size: 123996Sending DFU start packet, afterwards we wait for the flash on target to be initialized before continuing.PC -> target: 0502aabbccddPC -> target: 0502aabbccddPC -> target: 0502aabbccddPC -> target: 0502aabbccddPC -> target: 0502aabbccdd
Failed to upgrade target. Error is: Failed to establish connection
I also pressed button 4 and reset together to ensure target is in DFU. I'm not sure what other steps to try. Please help
A quick update, I flashed the software onto the host board (the one connected via serial port /dev/ttyACM1 onto my Ubuntu PC) as well, still see the error.
You need to download all the firmware (steps 5 through 9) also for the board that you use for performing the DFU from.
The use case is that you have a number of nodes, and then you connect to one of those nodes over serial in order to upgrade the full network (including the node that you connect to.)
I'm finally able to perform a DFU over mesh on 2 nodes. Couple of observations:
1. On using Ubuntu on my PC, I always see the error "Failed to upgrade target. Error is: Failed to establish connection".
Not sure of the reason.. It could be that the nrfutil looks for "COM" ports, only available on Windows? That is a random guess.
On using Windows, I was able to get past this error.
2. Now moving onto Windows:
I ported over all my build files (including the device page generated) from my Ubuntu PC to Windows PC. Then I ran
nrfutil --verbose dfu serial -pkg C:\Users\shubhang\Downloads\nrf5_SDK_for_Mesh_v2.0.1_src\examples\dfu\all_executables_for_dfu_ported_from_ub\dfu_test4.zip -p COM5 -b 115200 -fc --mesh
And this failed with (log as below)
...Opened com-portStarting DFU upgrade of type 4, SoftDevice size: 0, bootloader size: 0, application size: 123996Sending DFU start packet, afterwards we wait for the flash on target to be initialized before continuing.PC -> target: 0502aabbccddtarget -> PC: 0582aabbccddGot echo responseSending DFU init packetPC -> target: 1378fdff040f9e18084759000000010005000000target -> PC: 16a6045900000001000500000059000000010001000000target -> PC: 03847800PC -> target: 1378fdff040f9e18084759000000010005000000target -> PC: 03847800
Failed to upgrade target. Error is: Crashed on start packet
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...
So it appeared that there was some issue with my build. Although not sure what this could be.
3. Finally, I repeated the process using the precompiled dfu application and precompiled blinky hex files in my DFU package. This DFU update succeeded, and now I'm able to see both of my boards blinking!
4. On Windows, what is the recommended toolchain to use, to build my applications? I have gccarm (cmake/ninja) and Segger Embedded Studio installed on Ubuntu. It would be good if you could give me a tip as to which one works well in Windows.
Thank you very much!
I am happy to hear that you had some success!
The trials in 3., did you do that on Ubuntu or on Windows only? I managed to get the same behavior as you initially reported (only difference in the log was "[----] 0%" missing), after partially performing steps 5-6, trying, performing step 7, trying again, performing steps 8-9, then try again. After that I had to both perform steps 5-9 and after that physically turn the board off and on again, but then it worked. So it looks to me that it is possible to force the board into a state where it does not answer (repeated "PC -> target: 0502aabbccdd" messages from nrfutil), by partially programming it then attempting a DFU session.
nRF5 SDK for Mesh supports both gcc/cmake and Segger Embedded Studio on all platforms. Which one to choose mostly depends on taste (SES gives you an IDE, while with gcc/cmake you edit cmake files directly but are free to use any editor of choice.) If you plan on combining Bluetooth Mesh with BLE then SES is the safer option, as SES is supported both by nRF5 SDK for Mesh and nRF5 SDK.