DFU BLE .zip Packet Generation Issues

[Andy Cruz]

Hi,

I'm planning to implement DFU for a project with buttonless BLE and I've been running into a few roadblocks along the way. My nrfutil.exe installation was missing a few commands online resources said to use and upon checking I saw it was version 0.3.0. I replaced it with a new nrfutil.exe of version 3.5.0 and I noticed doing any simple commands in it, even just asking --help to see what commands were available were taking upwards of 2 minutes to complete, although the newer commands were at least there. On further researching I saw many suggestions to use nrfutil version 2.3.0, which takes from 30 seconds to 1 minute depending on the task. I am not sure if I installed either newer nrfutil.exe version incorrectly but after long enough both are able to create package .zip files and generate private keys fine.

My install is the "nRF5_SDK_14.2.0_17b948a.zip" and I've been using the examples for DFU, making copies of the files "bootloader_secure_ble" and "secure_dfu_test_images" to see if I could create working versions of the included examples. Everything about uploading the code to the development kit I believe is correct: I am erasing the entire thing with nRFgo Studio, programming SoftDevice "etc./nRF5_SDK_14.2.0_17b948a/components/softdevice/s132/hex/s132_nrf52_5.0.0_softdevice.hex" and programming Bootloader "etc./nRF5_SDK_14.2.0_17b948a/examples/dfu/bootloader_secure_ble - Copy/pca10040/ses/Output/Release/Exe/secure_dfu_ble_s132_pca10040.hex". I have been building the code in Segger Embedded Studio to generate the .hex files for bootloader. 

Once all programmed the kit's LEDs come on showing it is in DFU mode and I can find the blutetooth device "DfuTarg" in nRF Connect for my iphone. Connecting to it gives me access to DFU through "Secure DFU Service" which functions correctly. If I load the given test image "ble_app_buttonless_dfu_without_bonds_s132.zip" it uploads correctly and the new application functions correctly. I am also able to either hold button 4 on a hardware reset or attempt to send a new DFU message from my phone to cause the development kit to reenter DFU mode fine. I have seen a number of error messages from my own .zip files when I've attempted to upload them the same.

• Any .zip created by the original nrfutil.exe version 0.3.0 gives an "Invalid Object" error on my phone. The already available .zips by default in the app also return this error, which I assumed was a mismatch from version differences as they were all appended with "...sdk_12.2.0_..." although I am not sure if this is the cause of this error.
• I created a .zip using this command: "c:\nrfdfutest\nrfutil.exe pkg generate --application ble_app_buttonless_dfu_without_bonds_s132_with_setting_page.hex --application-version 0xFFFFFFFF --sd-req 0x9D --hw-version 52 --key-file dfu_private_key.pem packagefile.zip" and got an error saying the SD did not match, even though I'm pretty sure 0xFFFE should allow for any soft device. I fixed this by checking nRFgo Studio to see the softdevice I was using, sd 132 version 5.0.0, has the FWID 0x9D.
• I created another .zip using this command: "c:\nrfdfutest\nrfutil.exe pkg generate --application ble_app_buttonless_dfu_without_bonds_s132_with_setting_page.hex --application-version 0xFFFFFFFF --sd-req 0x9D --hw-version 52 --key-file dfu_private_key.pem packagefile.zip" which resulted in an error because of a Hardware mismatch. This is probably because the default hw-version I found online was 52 and shouldn't be entered as a hex value. I believe the DFU checks the hardware version before the softdevice version so even with the incorrect softdevice this should stop the DFU from continuing before detecting a sd mismatch. 
• Lastly, I included the correct version and key information and successfully created a .zip package that looked very similar to the .zip examples included in my 14.2.0 install. The manifest.json files also looked nearly identical in a text editor besides the different file names between the example .zips and my copies of the .hex file examples. I replaced the default debug file for dfu_public_key.c in the dfu_req_handling folder with the public key generated off my of my own generated private key. The only difference between the .zips was the example packages had .bin files of 40KB whereas my generated .zips had .bin files of 369KB. Now the error I am receiving is "Insufficient Resources" because, I believe, the device needs to store a copy of the files it is uploading over BLE and 369KB is simply too large a file for the development kit to store.

Before I run into any other errors I'd like to ask some questions to see if I'm even set on the right path and if anyone else can direct me better than google:

1. I've mostly been looking at the Nordic infocenter website, the Nordic Semiconductor Github pages, and other posts made on this Nordic Devzone for guidance on how to overcome obstacles; is there anywhere else good I should be checking for information?
2. How can I decrease the size of the .bin files made by nrfutil.exe in my .zip files?
3. Why are the file names for the example .hex files and their corresponding example .zip files for the DFU examples different? The generated .bin file from my .zip was named the same as my .hex file but the corresponding example .bin file is called "nrf52832_xxaa.bin" instead of "ble_app_buttonless_dfu_without_bonds_s132_with_setting_page.hex". Is it generated from a different file I haven't found?
4. What if anything can I do to decrease the time of my nrfutil.exe to complete commands? About 1 minute for every attempt, success or failure, is taking a rather long time. I'd prefer to continue using the command prompt and an nrfutil.exe as it is what I have become accustomed to and learning a new method of doing the same will likely stretch my patience even thinner than I already have.

Thanks for any help!

[Bjørn Kvaale]

1) This blog post should also be helpful. The Nordic Infocenter is also very helpful, especially the info on buttonless dfu.

2) The zip file seems way too big. What exact command are you using to generate this zip file? In general, after --application-version, you want to just try 0 first if this is the first DFU you are doing with that application (i.e. --application-version 0). Have you tried following the blog post I mention in answer 1? What is the zip size if you follow that guide?

3) Not sure why this is the case.

4) My nrfutil commands do not take that long to complete. Are you running nrfutil on Windows? Do all the nrfutil commands take that long to run? I ran nrfutil --help & that finished in about one second. I am running version 3.4.0 on windows 10.

[Andy Cruz]

Hey, sorry for responding so late, a lot of deadlines were just around the corner when I originally asked these questions and now I have more time to go back and respond in detail. With help from my supervisor we were able to get the buttonless BLE OTA DFU working to upload programs to our NRF52 development kit. In response to your reply:

1. That blog post unfortunately takes me to this error page so I can't say if the intended page would have been helpful or not. My supervisor and I did however go over the Nordic Info Center page for Buttonless DFU ver. 14.2.0 again more in depth and at the end managed to get it functioning correctly.

2. The .zip file was definitely far too big and we found the main reason being the target files I was zipping were not the correct files to use. I was trying to essentially recreate the exact same example .zip files in the folder "C:\nRF5_SDK_14.2.0_17b948a\examples\dfu\secure_dfu_test_images\ble\nrf52832" by using nrfutil to package the .hex files in there. The fix for this was we created our own DFU buttonless App files following the guidelines on the InfoCenter for 14.2.0 Buttonless DFU App for creating our own application. We used Segger Embedded Studio to edit the given example found in "C:\nRF5_SDK_14.2.0_17b948a\examples\ble_peripheral\ble_app_buttonless_dfu\pca10040\s132\ses" (after making a copy in case we broke something) to compile the code and create .hex files of our own that are significantly smaller sizes than the example images. The resulting .zip files from our experimenting included .bin files closer to 70KB rather than the previous 300+KB from zipping the example image apps, which are much more in line with the file sizes of about 40KB found in the DFU test image .zip files. 

3 & 4. Neither am I, the computer I use runs many programs slowly and did since the day I arrived so all I know is this issue is not a problem with anything related to nrfutil. It runs much more quickly on other computers, completing tasks in a short time always.

Thank you very much for your reply, following the corresponding InfoCenter pages more closely helped us since it was the skipping ahead and trying to zip up the DFU test images to test nrfutil packaging that was the error.