Hard coded DFU zip file

[Albin]

I'm currently woking on doing my own DFU system, the system should work this way : the central gets a new version of the app via the internet network and it should update the peripheral via the secure DFU. 

So far the network part hasn't been done yet and in order to make some test i want to have the entire zip file in the central (hard coded) at the begining to test is the whole implemented system is working.

Do you know how i can write the zip file in a byte array that i can put in the software ? or if there is a better way.

[Bjørn Kvaale]

Would it be a possibility to do a dfu of the peripheral with a smartphone as the central device? If yes, you could take a look at the nrf toolbox github code for Android & iOS. Both apps can also be found on their respective app stores. In addition, this link will probably be very helpful.

[Albin]

we're trying to have the least human interventions on this, i've found this on the infocenter DFU process and i don't realy understand what is the init packet i have to send before the new firmware and if the my_app.bin generated via nrfutil is the only file i have to send for the DFU

[Bjørn Kvaale]

This devzone case could be quite useful. In addition, here is more information regarding the Bootloader & DFU modules for the latest sdk. The init packet contains FW image information & must be signed to be trusted by the device that is having it's FW upgraded. You can see in the second link that if the prevalidation phase fails in the flow chart, the DFU is stopped & the DFU target goes back to advertising as "DFUTarg". 

This link could be useful regarding the first question you posted. It shows how the Android DFU process works with the Android device as the DFU initiator (i.e. central device). 

Update: The manifest.json file does not get sent to the dfu target. It is used by the DFU controller to see what type of packet it is. The first file that is sent from the controller to the target is the my_app.dat file (the init file) & the second one is the my_app.bin file. This makes sense, as the my_app.dat file is used to double check that the DFU is legitimate & the my_app.bin file contains the FW code to be updated.