How to use DFU OTA with custom FW

RE: How to use DFU OTA with custom FW

rmarques — Wed, 07 Aug 2019 13:18:24 GMT

[quote userid="2121" url="~/f/nordic-q-a/50680/how-to-use-dfu-ota-with-custom-fw/202831"]You are correct. After you has updated your application to the blinky example it won't be able to be updated (without manually switching it to bootloader mode). [/quote]

Thank you! After reading the documentation (for 3.1.0 at least), I was unsure if the bootloader handled background updating of the application or if that was only possible if a DFU compatible application took care of that. If I understood correctly, if the application does not have the DFU feature it cannot be updated in background, only in bootloader mode, is that right?

[quote userid="2121" url="~/f/nordic-q-a/50680/how-to-use-dfu-ota-with-custom-fw/202831"]You need to integrate DFU feature into your application to do mesh DFU (without manually put it to bootloader mode). To do that you would need to follow this guide. [/quote]

Ah! That guide wasn't present in 3.1.0! :) That is exactly what I was looking for.

RE: How to use DFU OTA with custom FW

Hung Bui — Wed, 07 Aug 2019 12:38:43 GMT

Hi Rmarques,

You are correct. After you has updated your application to the blinky example it won't be able to be updated (without manually switching it to bootloader mode).

You need to integrate DFU feature into your application to do mesh DFU (without manually put it to bootloader mode). To do that you would need to follow this guide.

The dfu project is a good source for reference.

RE: How to use DFU OTA with custom FW

rmarques — Tue, 06 Aug 2019 17:43:24 GMT

I think I figured it out.

Firstly, I had some problems in my script. I am still not 100% sure it was from that, but I can now use any one of the 3 boards to initiate the DFU transfer reliably, I tried each once and every time it worked.

Secondly, after moving to Mesh SDK v3.2 and Nordic SDK 15.3 AND discarding signature verification (can't tell what caused the following result), nRFConnect now shows me this

The third block from the bottom is the example blinky application in meshsdk/bin/blinky and the forth block in black/dark grey is the rest of the dfu example application that the documentation advises to program into the board the first time.

What I THINK is happening is that after programming the blinky application once, the boards cannot be reprogrammed anymore over the air since the application that took care of that does not exist anymore. That forth block from the bottom is just junk. Am I right? Is the application responsible for handling the DFU packets? Or is the mbr/bootloader/softdevice the only parts taking care of that?

Answering this would answer my original question, I would need to include in my applications the code that is part of the DFU example.

RE: How to use DFU OTA with custom FW

rmarques — Tue, 06 Aug 2019 16:58:57 GMT

Also, removing the signature verification does nothing regarding the start of DFU transfer. Quote from the documentation:

"As the entire firmware data is required for the hash, the signature is not checked until after the entire transfer is complete."

RE: How to use DFU OTA with custom FW

rmarques — Tue, 06 Aug 2019 16:35:17 GMT

Did not work. I am now using Mesh SDK v3.2 and Nordic SDK 15.3.

In fact, now the LEDs start blinking but that might be just because I stopped using signature verification, after removing the public_key attribute from nrf5SDKforMeshv320src/tools/dfu/bootloader_config_default.json and removing the --key-file private_key.txt option from nrfutil dfu genpkg when generating the firmware archive.

The behaviour of the boards is not predictable either since after reprogramming everything from step 4, I was using /dev/ttyACM0 to test the DFUOTA in step 5 and it never worked. Tried using /dev/ttyACM1 and it worked... ONCE!

That time all 3 boards started blinking the 4 LEDs. I could not repeat the experiment though, despite having step 4 scripted to run over the 3 boards automatically, including generating the device page from the bootloader_config_default.json using the device_page_generator.py.

Is it possible I have a problem with the serial driver or some library misconfigured? I can always program step 4 but sometimes step 5 fails (most of the times) and sometimes it doesn't...

RE: How to use DFU OTA with custom FW

Hung Bui — Tue, 06 Aug 2019 13:05:03 GMT

Hi Rmarques,

Most likely it was the bug in our SDK v3.1 causing the issue.

You can have a look here : https://devzone.nordicsemi.com/f/nordic-q-a/46950/problem-with-mesh-dfu

Especially the fix with optimal_bank_address()

However the bug should be solved in SDK v3.2. Could you give it a try ?

RE: How to use DFU OTA with custom FW

rmarques — Tue, 06 Aug 2019 11:56:10 GMT

So I discovered that if I power cycle the boards after steps 2, 3 and 4 described above, when I try step 5 it fails immediately. Is this normal, or do you guys think I may have configured something wrong?

RE: How to use DFU OTA with custom FW

rmarques — Tue, 06 Aug 2019 11:31:00 GMT

If I try to reprogram with a higher version right after programming with the blinky example I get this message:

Failed to upgrade target. Error is: Device returned status code ERROR_DEVICE_STATE_INVALID (131) on a DFU state beacon packet.

If I power cycle the 3 boards and retry, I get

Failed to upgrade target. Error is: Failed to establish connection

RE: How to use DFU OTA with custom FW

rmarques — Tue, 06 Aug 2019 11:16:58 GMT

I thought it might be easy if I just put the LED's blinking on the DFU example, but when I generated the DFU archive of the DFU example, I noticed the transfer took much longer than the blinky example inside meshsdk/bin/blinky, and of course that is because the DFU archive for the DFU example is much larger than the DFU archive for the blinky example, 120KB as oposed to 3KB for the blinky DFU archive.

So it is possible to have a smaller DFU archive passed to the boards. But what I ALSO noticed is that after passing the blinky DFU archive once, the boards stopped receiving DFU archives, regardless of the app version I set on the DFU archive (I understand it has to be always higher than the last DFU archive transfered). I suspected it might be because the whole application area of 120KB was being replaced by the 3KB application of the blinky DFU archive, but to my surprise, using nRFConnect I saw it is still 120KB, albeit some odd bytes larger.

This doesn't make sense to me...

RE: How to use DFU OTA with custom FW

rmarques — Tue, 06 Aug 2019 09:51:14 GMT

I found this tutorial that might at least help understanding how memory setup works. Reading...