Buttonless DFU - Transfer Succeeds, but no BLE device available after

[TFETT]

I'm working the the NRf52 dev board and SDK12.2. I was able to successfully load the standard DFU example and then use the NRF Toolbox on an android to load the example HR zip file to the device. Then verify it worked using the HR portion of the app.

Using nrfutil I created a private and public key. Then used the nrfutil to create a zip file of the application hex file. I again flash the dev board with the DFU example (updated key) on to the NRF52 dev board. Then using NRF Toolbox on android I transfer the buttonless DFU example(updated key) and the phone shows it loading and returns successful. However instead of entering into BSP_INDICATE_ADVERTISING it appears to enter into BSP_INDICATE_ALERT_2(LED 3 blinking ~3 times per second). Additionally when I search for any ble device I don't see anything.

I can use the buttons to trigger the device back into DFU mode. I also tried to load the Experimental BLE Blinky app and this succeeds and then the device behaves as expected. Any help would be greatly appreciated.

[Hung Bui]

Hi,

Have you updated the bootloader with your generated public key ?

[TFETT]

No I haven't. When I flash the board I simply issue a nrfjprog --eraseall -f nrf52. I then flash it with a softdevice from a different project. And lastly flash it with the secure DFU application. Should I be specifically flashing a bootloader. The odd thing is the BLE Blinky example works.

[Hung Bui]

When you generate a .zip file for DFU updating, you embedded it with the signature from a private key that you generated. So you need to update the bootloader with the public key that you get from that private key. Then recompile the bootloader and flash the new bootloader.

Otherwise the bootloader will reject your image. It's described at step 5 here. To generate the public key file from the private key, you can have a look here.

The code should be

nrfutil keys display --key pk --format code c:\vault\priv.pem --out_file public_key.c

Then you replace the default public key file in the DFU bootloader code with the one you create, recompile.

[TFETT]

If that were the case I would expect it to fail when I load BLE Blinky which I also signed with the private key I generated (which it doesn't). At a higher level I'm a bit confused as to how to "compile a bootloader" I see the info about creating a bootloader settings file and merging it with the tools, but I'm not sure even how to generate the .hex file for a bootloader. Is bootloader and DFU interchangeable?

[Hung Bui]

Hi TFETT,

Sorry I was assuming you was testing with the provided pre-made .zip that works with the default DFU bootloader (the default key).

We call the program that handle the DFU task (and start first) is bootloader, as the name of the DFU bootloader project is bootloader_secure.

There could be an issue with the DFU buttonless example that you were testing with. My suggestion is to test with another BLE example, such as the ble_app_hrs. Next step is test with just the buttonless DFU example without flashing the bootloader (simply flash softdevice then the buttonless DFU example). Just to make sure it can advertise something.

Note that you can debug an application after it's flashed on the device via DFU as normal application. You may need to set optimization level to 0 to step in the code.