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!

[lidorelias3]

There are 41 lines in it, and I posted them all. I also have a bug on this forum where when I post a replay, I can only see it when I use the edit feature...

Or half of the replay like so:

I'll try to post the results again:

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: 1378fdff040f77ea951b59000000010002000000
target -> PC: 0384788e
2: PC -> target: 1378fdff040f77ea951b59000000010002000000
target -> PC: 0384788e
3: PC -> target: 1378fdff040f77ea951b59000000010002000000
target -> PC: 0384788e
4: PC -> target: 1378fdff040f77ea951b59000000010002000000
target -> PC: 0384788e
5: PC -> target: 1378fdff040f77ea951b59000000010002000000
target -> PC: 0384788e
6: PC -> target: 1378fdff040f77ea951b59000000010002000000
target -> PC: 0384788e
7: PC -> target: 1378fdff040f77ea951b59000000010002000000
target -> PC: 0384788e
8: PC -> target: 1378fdff040f77ea951b59000000010002000000
target -> PC: 0384788e
9: PC -> target: 1378fdff040f77ea951b59000000010002000000
target -> PC: 0384788e
10: PC -> target: 1378fdff040f77ea951b59000000010002000000
target -> PC: 0384788e

Failed to upgrade target. Error is: Device returned an unknown status code (142) on a DFU state beacon 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...

In case you can't see after line 31 again, It says:

"Failed to upgrade target. Error is: Device returned an unknown status code (142) on a DFU state beacon packet."

The guide told me to generate my own keypair, concatenate them, and place the result in bootloader_config_default.json.
Would that also apply to my project? Is that the correct way to set up the keys? There is no mention of this file or encryption keys in SES.  

Also, this is the output in debug:

[Edvin]

Did you do any modifications to the examples\dfu example, or are you trying to implement this into your own application? 

Do you call nrf_mesh_dfu_init()? 

I see that the "No CMD handler!" message is printed if there is no callback handler, which is being set in nrf_mesh_dfu_init(). By default, in the dfu example, this will be called from main() -> mesh_init() -> mesh_stack_init() -> nrf_mesh_init() -> nrf_mesh_dfu_init()

Can you make sure that is being called when you start up your application? 

Also, can you share the steps that you did when you followed the guide. Did you follow steps 1 to 6? And did you encounter any issues along the way?

BR,

Edvin

[lidorelias3]

I copied the main parts that connected to the DFU process to my own application.

Yes. The nrf_mesh_dfu_init() is being called but returns with NRF_ERROR_NOT_SUPPORTED.

The steps I did using the guide are:

nrfjprog --program bin/softdevice/s132_nrf52_7.2.0_softdevice.hex --chiperase

nrfjprog --program bin/bootloader/gccarmemb/mesh_bootloader_serial_gccarmemb_nrf52832_xxAA.hex

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

nrfjprog --program tools/dfu/bin/device_page_nrf52832_xxAA_s132_7.2.0.hex

nrfjprog --reset

Is there a way to include those commands using Segger? 

Then I used Segger to attach a debugger and reboot the device. I saw that now I get something else on the console when I try to mesh-dfu. I hope that we get closer:

<t: 459057>, nrf_mesh_dfu.c, 421, New firmware!
<t: 525396>, nrf_mesh_dfu.c, 421, New firmware!
<t: 591620>, serial.c, 226, Error type data: : 0B
<t: 608136>, serial.c, 226, Error type data: : 0B
<t: 624934>, serial.c, 226, Error type data: : 0B
<t: 641662>, serial.c, 226, Error type data: : 0B
<t: 658498>, serial.c, 226, Error type data: : 0B
<t: 674908>, serial.c, 226, Error type data: : 0B
<t: 691812>, serial.c, 226, Error type data: : 0B
<t: 708616>, serial.c, 226, Error type data: : 0B
<t: 725453>, serial.c, 226, Error type data: : 0B
<t: 742297>, serial.c, 226, Error type data: : 0B

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