bootloader config missing from ble_app_uart_c example

[gdutk001]

Hello, 

 I am working on an application on a nrf52840 using soft-device 140 and SDK 15.3. I have written 90% of the application using the ble_app_uart_c as a template for my project and haven't run into any issues until trying to add a boot-loader.

I'd like to add secure serial DFU capabilities to the project however I just realized that the config file for my current project is completely different from the serial_DFUs provided in the example projects section of the SDK. After adding all the bootloader/DFU source files into my project the compiler throws a "#error Configuration file is missing flags. Update sdk_config.h." complaint. 

After looking at both Config files I'm not sure how to proceed. Should I just copy and paste the config file part which has all the necessary bootloader/DFU macros? Or is there a custom sdk_config file which I can be provided with? Or will I need to migrate my project to a DFU example and add all my source in there?

thanks 

[bjorn-spockeli]

Hi Gianfranco,

Our serial bootloader is a stand alone project that you compile and flash to the nRF52840 alongside your application. The only thing you should have to add in the application is a routine that resets the device to bootloader mode. Or are you implementing background DFU, i.e. that the new firmware is received by the application and the bootloader only performs the switch? 

Best regards

Bjørn

[gdutk001]

The second option is what I'd like to implement. I need an application that will receive the firmware update via UART, de-crypt the hex file and then burn it into memory. I might be mistaken but I thought that was what the secure serial DFUs example in the SDKs were doing? If there is an alternative I can consider it, but the route I was taking considered merging parts of the secure_bootloader_uart_mbr example into my project(this what I have been having issues with).   

thanks, Gian

[bjorn-spockeli]

Hi Gianfranco, 

In our SDK the application transfers execution to the bootloader and then our bootloaders handle the transfer of the image over a selected transport layer( BLE/UART/USB). We do not do any decryption of the firmware image, we verify that the firmware image was signed using a public key in the bootloader that is derived from the private key used to sign the new firmware image. The firmware image it self is not encrypted. 

A colleague of mine has modified the bootloader to support background DFU, you can find the code here. Just scroll down to the answer that has been marked as accepted/verified. There should also be a readme file in the .zip as well. 

Best regards

BJørn