You have developed your program to run on RuuviTag and want to share it with the world. However, not everyone has access to Ruuvi Developer shield, and therefore you’ll need to create a DFU packet for users to install. Also, you might want to create a “full package” which contains softdevice, bootloader and your application.
To create the full hex package, you’ll need to merge softdevice, bootloader and application into one. However, the bootloader needs additional adjustment: The bootloader will check CRC of the application, and application will be booted only if the CRC matches. Therefore you need to calculate the CRC of the application and merge proper CRC into the bootloader. Fortunately, Nordic Semi provides nRFutil which does most of the heavy lifting.
To generate the settings for your application, run nrfutil settings generate — family NRF52 — application test_drivers.hex — application-version 1 — bootloader-version 1 — bl-settings-version 1 settings.hex. Replace the application hex as necessary. Versioning of the application and bootloader can be anything if you’re running on default RuuviTag, as it skips checking those versions. However, bl-settings-version has to be correct. If you’re going to develop end-user application and want to have control over the firmware which gets uploaded to your tags, you’ll want to generate your own keypair, compile your own bootloader with the keys and enforce version checks. However preparing for mass production is a subject for another Dev Diary entry.
Softdevice we’re using is s132 3.1.0. Now you have the hexes ready, merge them into one package with mergehex included in nRF5x tools. mergehex -m ruuvitag_b3_bootloader.hex settings.hex -o configured_bootloader.hex and mergehex -m s132_nrf52_3.1.0_softdevice.hex configured_bootloader.hex test_drivers.hex -o test_drivers_full.hex
Then, it’s time to create the DFU package with nRFutil: nrfutil pkg generate — key-file ruuvitag_fw/keys/ruuvi_open_private.pem — application test_drivers.hex — debug-mode test_drivers_dfu.zip
It’s always a good idea to cycle the a few DFU packages to your tag after uploading your package for the first time. It’s possible to craft DFU packets with invalid settings which will lock down the bootloader making rescuing the Tag quite an operation which involves making, testing and flashing a special rescue bootloader just to be able to restore the tag.
Also you should always check the power consumption of your tag before releasing the binaries to the wild. We’ll cover power profiling in a future Dev Diary entry.
