How to use DFU OTA with custom FW

[rmarques]

Hello, we are using 3 nRF52840 DKs, NSDK 15.2, Mesh SDK 3.1.0, SoftDevice 6.1.0 and Segger Embbeded Studio as my IDE.

I have followed the documentation here to program some boards over the air and had SOME success.

I understood that the process has 5 major steps

1 - Generate private and public keys

2 - Generate DFU archive using an application hex file and the private key

3 - Generate Device Page, adding the public key to the <bootloader_config_default.json> file

4 - Flash SoftDevice, Serial Bootloader, first application (examples/dfu) and Device Page in this order in every device

5 - Transfer the DFU archive over serial to one of the boards that then transmits the DFU archive in chunks to the boards in the vicinity.

I could follow the example, and we think the DFU chunks went through since we got the percentages on screen of the transfer and "Device programmed" in the end. The led's didn't start blinking though, and we would like to generate a DFU archive using the blinky example to check that.

We tried using nrfutil to generate a DFU archive like previously, but using the blinky hex file that Segger outputs, to the nRF5_SDK_15.2.0_9412b96/examples/peripheral/blinky/pca10056/blank/ses/Output/Release/Exe folder, but got an error that said ValueError: tobinarray: wrong value for size. We inspected the memory map of the DKs after programming the example DFU application using nRFConnect and in fact noticed something odd...

The Application part of the program on the DKs is huge compared to the blinky one. This leads us to think that we just cannot pick any random hex to transmit via DFUOTA.

What we would like to know is how to adapt an application to be able to be transfered using DFUOTA. We could not find anything about it in the documentation.

Also, what is included in a hex file that is compiled using segger? We normally use segger to compile and program the boards, so we didn't have to bother with that until now. Is the soft device included by default? Is it programmed separately? What about the bootloader?

[rmarques]

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

[rmarques]

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