nRF Mesh DFU over the air

[lidorelias3]

Hello,
I'm trying to set up the DFU over the air mesh. Using the mesh SDK 5 and nRF SDK 7.1.0.

Using the DFU example from nrf sdk17.1.0, I successfully ran it.

When I tried to execute the DFU example located in mesh_sdk5, I cannot find my board via NRF connect app and cannot send a DFU package.

After reading some documentation, I have not been able to add DFU features to my application.

How do I add DFU over the air to my mesh network application?

Is it necessary to use the DFU bootloader and then add the application that uses buttonless DFU over mesh on top of it?  If so, how can I connect all this in Segger studio?

On nRF52832, I am using NRF SDK 7.1 and mesh SDK 5.

I appreciate your help in advance!

[Edvin]

Hello,

The bootloaders in the nRF5 (normal SDK) and the mesh SDK are a bit different.

The Mesh bootloader uses Mesh communication, and since phones don't support that, then you can't find the device in nRF Connect for Android/iOS. To send out a mesh-bootloader-image, you need to use a separate DK, connected to a computer, and then use a tool called nrfutil, which is tailored for the Mesh SDK (please note that this is a separate nrfutil than the "normal" nrfutil tool. They just have the same name). 

A guide on how to perform a Mesh DFU is described here:

https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.meshsdk.v5.0.0/md_doc_user_guide_modules_dfu_configuring_performing.html

Hint: It is possible to download the mesh version of nrfutil and rename it to something like nrfutil-mesh by renaming the .exe file, and hence have both installed at the same time. 

If you want to update the device using a mobile phone, then you would need to use the bootloader from the normal SDK. This is a quicker bootloader, in terms of throughput and speed of the DFU process, but you can only update one device at the time. The advantage with the mesh bootloader is that you can update multiple nodes (using the same application ID) in the network at once. The disadvantage is that it is fairly slow, but it happens in the background while the old application is running, so in an end product, this will happen in the background while the nodes are still working as normal.

Best regards,

Edvin

[lidorelias3]

Thank you so much! It never occurred to me that nrfutil has a mesh-specific version.

As I followed the guide, I got stuck on the part where I had to transfer the .zip from one DK to another with the following error:

D:\Nordic\mesh-nrfutil>nrfutil-mesh --verbose dfu serial -pkg dfu_test.zip -p COM3 -b 115200 -fc --mesh
Upgrading target on COM3 with DFU package D:\Nordic\mesh-nrfutil\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: 2416
Sending DFU start packet, afterwards we wait for the flash on target to be initialized before continuing.
1: PC -> target: 0502aabbccdd
2: PC -> target: 0502aabbccdd
3: PC -> target: 0502aabbccdd
4: PC -> target: 0502aabbccdd
5: PC -> target: 0502aabbccdd
6: PC -> target: 0502aabbccdd
7: PC -> target: 0502aabbccdd
8: PC -> target: 0502aabbccdd
9: PC -> target: 0502aabbccdd
10: 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.
- if the error is ERROR_BUSY at the beginning of the DFU process,increase the value of PAGE_ERASE_TIME_MAX by few milliseconds.
Closing serial port...

I did steps 3 to 6 (in Preparing for DFU) on both DKs. Could that be the problem or am I doing it correctly?

After the reset, neither of my DKs is showing any lights.

[Edvin]

lidorelias3 said:

Is there a way to include those commands using Segger? 

I suggest you create a file that you call e.g.: "my_flash_script.bat", and then you paste those commands into that file (from a normal text editor). Then you can run this script from a command line whenever you do any updates,  and it will flash all the required files. It is also possible to run this script from segger, if you enter the project settings (remember to select "common" from the drop down curtain menu), then go to Debug -> Target Script, and select the "Load begin script". You can remove the 

program C:\Users\lidor\Desktop\netled\Netbag\build\serial_nrf52832_xxAA_s132_7.2.0_Debug\serial_nrf52832_xxAA_s132_7.2.0.hex

from your script, as this will be programmed by the program action in Segger. Or you can include it, and just run the script from the command line.

Please remember that when you are dealing with bootloaders like this, you should use the option "target -> Attach debugger" when you want to debug, as this will not upload a modified application .hex file, which may be rejected by the bootloader.

So nrf_mesh_dfu_init() returns NRF_ERROR_NOT_SUPPORTED. Try debugging to find out why.

Is it because dfu_cmd_handler_set() doesn't return NRF_SUCCESS? If so, what does it return?

Try to figure out why it returns what it returns, and perhaps you are able to determine the cause of the issue. If not, let me know what it returns.

BR,

Edvin

[lidorelias3]

NRF_ERROR_NOT_SUPPORTED has been fixed. As you suggested, I used build and debug instead of attaching a debugger.

When transferring new firmware via serial connection, there is the same issue as before:

lidorelias3 said:

Error type data: : 0B

What can be the cause for that?

[Edvin]

Hello,

Sorry for the late reply. I have been out of office. I was back now only for a day. I'll be back August 1st. I am sorry I didn't have time to look into this now. Due to limited staffing during the summer, I don't think anyone will look into this case, so if you need a reply sooner, I suggest you try to create a new ticket where you describe your latest question. Please specify where it says "Error type data: : 0B".

A question that you can look into in the meantime is:

I see that your line numbers (from the log) are different than mine. Did you change anything inside these files? What is located in your nrf_mesh_dfu.c line 421, and serial.c line 226? I see that the nrf_mesh_dfu.c logging is just a few lines shifted, but none the less, it means that you changed something in this file. The logging from serial.c I can't find in my SDK, so did you add it yourself? 

Perhaps you should try your application in a clean, unmodified, freshly unzipped SDK?

Best regards,

Edvin

[lidorelias3]

Hey,

I added the log at line 226. As you suggested, I tried using a freshly unzipped MESH SDK. Now I only get the log "new firmware" at line 418, not the log at serial.c. As before, the DFU process doesn't work at all. I have no idea what the problem is.

[Edvin]

what does the cmd / terminal from nrfutil say when you try to perform the DFU at this point?

[lidorelias3]

D:\Nordic\mesh-nrfutil>nrfutil-mesh --verbose dfu serial -pkg dfu_test.zip -p COM3 -b 115200 --mesh
Upgrading target on COM3 with DFU package D:\Nordic\mesh-nrfutil\dfu_test.zip. Flow control is disabled.
Flushing com-port...
Opened com-port
Starting DFU upgrade of type 4, SoftDevice size: 0, bootloader size: 0, application size: 2416
Sending DFU start packet, afterwards we wait for the flash on target to be initialized before continuing.
1: PC -> target: 0502aabbccdd
target -> PC: 0582aabbccdd
Got echo response
Sending DFU init packet
Sending ready packet
1: PC -> target: 1378fdff040fd76e663c59000000020004000000
target -> PC: 16a6045900000002000400000059000000010001000000
target -> PC: 03847800
1: PC -> target: 1378fdff040fd76e663c59000000020004000000
target -> PC: 16a6045900000002000400000059000000010001000000
target -> PC: 03847800
Sending start packet
1: PC -> target: 1478fcff0000d76e663cffffffff5c02000040000c
target -> PC: 03847887
2: PC -> target: 1478fcff0000d76e663cffffffff5c02000040000c
target -> PC: 03847887
3: PC -> target: 1478fcff0000d76e663cffffffff5c02000040000c
target -> PC: 03847887
4: PC -> target: 1478fcff0000d76e663cffffffff5c02000040000c
target -> PC: 03847887
5: PC -> target: 1478fcff0000d76e663cffffffff5c02000040000c
target -> PC: 03847887
6: PC -> target: 1478fcff0000d76e663cffffffff5c02000040000c
target -> PC: 03847887
7: PC -> target: 1478fcff0000d76e663cffffffff5c02000040000c
target -> PC: 03847887
8: PC -> target: 1478fcff0000d76e663cffffffff5c02000040000c
target -> PC: 03847887
9: PC -> target: 1478fcff0000d76e663cffffffff5c02000040000c
target -> PC: 03847887
10: PC -> target: 1478fcff0000d76e663cffffffff5c02000040000c
target -> PC: 03847887


Failed to upgrade target. Error is: Device returned status code ERROR_INVALID_DATA (135) on a DFU data 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.
- if the error is ERROR_BUSY at the beginning of the DFU process,increase the value of PAGE_ERASE_TIME_MAX by few milliseconds.
Closing serial port...

[Edvin]

Is there some way for me to reproduce what you are seeing? I have been able to successfully perform a Mesh DFU using the nRF5 SDK for Mesh 5.0.0 in combination with nRF5 SDK 17.0.2. Did you try this?

Also, are you completely sure that you are using the correct keys? If you are not sure, please try to follow this guide, using an unmodified set of nRF5 SDK 17.0.2 and nRF5 SDK for Mesh v5.0.0.

At least, following this guide, I was able to upgrade the nRF52832 DK using the mesh bootloader.

Best regards,

Edvin

[lidorelias3]

I successfully performed a Mesh DFU using nRF5 SDK for Mesh 5.0.0 in combination with nRF5 SDK 17.0.2 using the example provided in Mesh 5.0.0. I received an ERROR_INVALID_DATA error when I tried to copy parts of the example into my program. From the example, I copied the relevant parts. Can I integrate Mesh DFU into my program this way?

Yes, the keys are correct. Checked it again.

My error may be related to how I copied the relevant part from the Mesh DFU example. 

[lidorelias3]

UPDATE!

I verified that the code I copied from the Mesh DFU example matches the code I have on my DK. After adding some missing stuff, I was able to DFU my DK!

nrfutil-mesh --verbose dfu serial -pkg blinky.zip -p COM3 -b 115200 --mesh
Upgrading target on COM3 with DFU package D:\Nordic\mesh-nrfutil\blinky.zip. Flow control is disabled.
Flushing com-port...
Opened com-port
Starting DFU upgrade of type 4, SoftDevice size: 0, bootloader size: 0, application size: 2180
Sending DFU start packet, afterwards we wait for the flash on target to be initialized before continuing.
1: PC -> target: 0502aabbccdd
target -> PC: 0582aabbccdd
Got echo response
Sending DFU init packet
Sending ready packet
1: PC -> target: 1378fdff040fe9016a5259000000010002000000
target -> PC: 16a6045900000001000200000059000000010001000000
target -> PC: 1378fdff04000000000059000000010002000000
target -> PC: 03847800
1: PC -> target: 1378fdff040fe9016a5259000000010002000000
target -> PC: 1378fdff040fe9016a5259000000010002000000
target -> PC: 03847800
Sending start packet
1: PC -> target: 1478fcff0000e9016a52ffffffff2102000000000c
target -> PC: 0da2010459000000010002000000
target -> PC: 03847800
Waiting for 0.0 seconds for flash bank erase to complete.
Sending firmware file
  [------------------------------------]    1%  00:08:411: PC -> target: 1978fcff0100e9016a520000012075c301005dc301005fc30100
target -> PC: 03847800
1: PC -> target: 1978fcff0200e9016a5261c3010063c3010065c3010000000000
target -> PC: 03847800
  [------------------------------------]    2%  00:08:341: PC -> target: 1978fcff0300e9016a5200000000000000000000000067c30100
target -> PC: 03847800
1: PC -> target: 1978fcff0400e9016a5269c30100000000006bc301006dc30100
target -> PC: 03847800
  [#-----------------------------------]    3%  00:05:371: PC -> target: 1978fcff0500e9016a526fc301006fc301006fc301006fc30100
target -> PC: 03847800
1: PC -> target: 1978fcff0600e9016a526fc301006fc301006fc301006fc30100
target -> PC: 03847800
......................
  [##################################--]   95%  00:00:031: PC -> target: 1978fcff8300e9016a52214602a8fff748fe039b002bf4d00198
target -> PC: 03847800
1: PC -> target: 1978fcff8400e9016a52d3e90021904702a8fff748fef4e70528
target -> PC: 03847800
  [###################################-]   97%  00:00:021: PC -> target: 1978fcff8500e9016a5201d0fff712fe04b010bd00bf74c80100
target -> PC: 03847800
1: PC -> target: 1978fcff8600e9016a5215c80100000000000d0e0f1000000000
target -> PC: 03847800
  [###################################-]   98%  00:00:001: PC -> target: 1978fcff8700e9016a520338fdd87047000050c8010058c80100
target -> PC: 03847800
1: PC -> target: 1978fcff8800e9016a520800000050c8010050c8010008000000
target -> PC: 03847800
  [####################################]  100%          1: PC -> target: 0d78fcff8900e9016a520090d003
target -> PC: 03847800
DFU upgrade took 86.2359998226s
Closing serial port...

Closing serial port...
Device programmed.

However, I see the following output in the debugger:

nrf_mesh_dfu.c,  593, 	SERIAL TX (type: 65534)
serial_handler_device.c,  125, Echo data: : AABBCCDD
nrf_mesh_dfu.c,  418, 	New firmware!
main.c,   72, DFU type Application
main.c,  117, Requesting DFU transfer with bank at 0x0004B000
nrf_mesh_dfu.c,  554, 	RADIO TX! SLOT 0, count 3, interval: periodic, handle: FFFD
nrf_mesh_dfu.c,  593, 	SERIAL TX (type: 65533)
nrf_mesh_dfu.c,  554, 	RADIO TX! SLOT 0, count 3, interval: periodic, handle: FFFD
nrf_mesh_dfu.c,  593, 	SERIAL TX (type: 65533)
nrf_mesh_dfu.c,  458, 	DFU start
nrf_mesh_dfu.c,  554, 	RADIO TX! SLOT 6, count 6, interval: exponential, handle: FFFC
nrf_mesh_dfu.c,  357, Erase complete (0x4B000)
nrf_mesh_dfu.c,  361, Flash idle.
nrf_mesh_dfu.c,  482, 	DFU segment rx: 1/137
nrf_mesh_dfu.c,  554, 	RADIO TX! SLOT 7, count 3, interval: exponential, handle: FFFC
nrf_mesh_dfu.c,  352, Write complete (0x2000FE98)
nrf_mesh_dfu.c,  361, Flash idle.
nrf_mesh_dfu.c,  482, 	DFU segment rx: 2/137
nrf_mesh_dfu.c,  554, 	RADIO TX! SLOT 1, count 3, interval: exponential, handle: FFFC
nrf_mesh_dfu.c,  352, Write complete (0x2000FE98)
nrf_mesh_dfu.c,  361, Flash idle.
nrf_mesh_dfu.c,  482, 	DFU segment rx: 3/137
nrf_mesh_dfu.c,  554, 	RADIO TX! SLOT 2, count 3, interval: exponential, handle: FFFC
nrf_mesh_dfu.c,  352, Write complete (0x2000FE98)
nrf_mesh_dfu.c,  361, Flash idle.
............
nrf_mesh_dfu.c,  482, 	DFU segment rx: 135/137
nrf_mesh_dfu.c,  554, 	RADIO TX! SLOT 3, count 3, interval: exponential, handle: FFFC
nrf_mesh_dfu.c,  352, Write complete (0x2000FE98)
nrf_mesh_dfu.c,  361, Flash idle.
nrf_mesh_dfu.c,  482, 	DFU segment rx: 136/137
nrf_mesh_dfu.c,  554, 	RADIO TX! SLOT 4, count 3, interval: exponential, handle: FFFC
nrf_mesh_dfu.c,  352, Write complete (0x2000FE98)
nrf_mesh_dfu.c,  361, Flash idle.
nrf_mesh_dfu.c,  482, 	DFU segment rx: 137/137
nrf_mesh_dfu.c,  629, 	TIMER set: 30000000us delay (@117850342)
nrf_mesh_dfu.c,  554, 	RADIO TX! SLOT 5, count 3, interval: exponential, handle: FFFC
nrf_mesh_dfu.c,  352, Write complete (0x2000FE98)
nrf_mesh_dfu.c,  361, Flash idle.

As a result, my DK has two lights on and does not go to the new program I updated to (blinky example).

After restarting the device, it returns back to my program and not to the blinky example.

[Edvin]

You need to let it wait a few seconds (10 seconds?) after it says "Device programmed.", and it should restart into the new FW. Please try with the unmodified DFU example first, to make sure that everything is set up correctly before you try to apply this to your own application. 

BR,
Edvin