Experimental Buttonless DFU - SDK13 - Package creation?

[matterama]

Hi all,

Could you please point me at the tutorial I missed... I am looking to adapt the title project to a custom project. I've run the sample and it advertises and shows the DFU service, all seems good. However, i realized that while I've built packages for secure DFU using nrfutil, this example doesn't seem to have a bootloader set of files per what I am used to.

Typically I would have a bootloader project and an application project, with keys, etc. shared between them. This example doesn't have a bootloader per se it seems.

Can anyone describe the method for creating a zip file that can be uploaded to the board running the ble_app_buttonless_dfu example? Is this secure or not? Any other usage information available?

Thank you...

[cedric]

Hello Matterama, the simplest way to to this is to firsrt programm the softdevice, then the bootloader with a SWD tool, like Jlink. If you have an eval board, it's embedded.

Then using nrfutils, you create your ZIP package, at first try, just make a package with a simple firmware, no SD nor bootloader.

Once the bootloader and the softdevice is programmed, you should see a device named "dfutarg".

Connect to it with nrfconnect or nrftoolbox. Upload the ZIP file after clicking "DFU" button (it's sometimes not clear that it actually is a button). That should be a start. The process is secured by keys, so it is secured. If you work on windows, I suggest you to create a .BAT file in the same folder than nrfutil (the easiest way) with :

• a line to copy the .hex file from the developping folder to the production folder

• a line like this one "nrfutil pkg generate --hw-version 52 --sd-req 0x98 --application-version 1 --application myApp.hex --key-file myKey.pem myApp_pkg.zip"

• a line with merge hex for the day you want to create a complete package with SD, boot and you firmware, don't forget to generate settings with nrfutil

[matterama]

Thank you Cedric, but your description sounds more like the use for a generic bootloader/zip tool (correct me if I'm wrong). The buttonless_DFU app advertises a DFU capability already, and the nRF connect sees this, and allows you go choose a zip file to create and upload. But what I am trying to do is:

1. determine if the buttonless DFU needs a separate bootloader program/project to go with it
2. determine how to create a zip file that the buttonless DFU app will accept
3. ultimately modify the buttonless DFU to perform application tasks so when i upload a new app, i am uploading a new app based on the buttonless DFU app so it looks seamless w/r/t over the air updates

I feel like I'm missing something fundamentally (probably my understanding)! Thanks

[cedric]

You should think of the bootloader as a separate programm that stays somewhere in the ROM. In other words, there are two programm in the memory, the bootloader and the firmware (which in your case is buttonless_dfu). So, the bootlader as no link with the firmware, except that the firmware and the bootloader know how to switch to the other programm. The Zip package should only be compatible with the bootloader which will check it before dwonloading the new firmware. So, to answer your quesion, yes the DFU app needs a separate bootloader to reprogramm the firmware, the ZIP file is created with nrfutil (generate the key before and compile the bootloader with the generated key placed in dfu_public_key.c, there are lots of things to download to compile the micro-ecc library. Generate you package with nrfutil and you hex code (whatever the firmware is). The buttonless_dfu is just an example of a programm that know how to switch to bootloader. If you add the service to an other example, it will be able to switch to bootloader too.

[matterama]

Thank you Cedric, I was letting my 'wish' for what the example could do cloud the obvious reality :)