DFU via own protocol

Question

Hi, 
 we are developing a device with 2 µC one being the nRF52832 for BLE connectivity. We want to do DFU via BLE with our own protocol. From what I've read, in this case some sort of Background DFU is the way to go. So far I've saved the new firmware to the flash but I'm not sure what to do with the init file. Where do I need to save it to? Or are there other things I need to do first with this file? I'm using SDK14.2.0 with Softdevice 132 Version 5.0.0 and the IoT Bootloader. 
 Thank you in advance.

Edvin · Accepted Answer

I was thinking about the message sequence chart. I'm sorry. I forgot the link in the previous reply. Do you intend to use the serial bootloader as a starting point? In that case, I would check out this one: 
 https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.sdk5.v14.2.0/lib_dfu_transport_serial.html?cp=7_5_3_3_5_2_3_1#lib_dfu_transport_serial_msc 
 
 What the bootloader normally does after you set the gpregret register as you described here, is that it starts in DFU mode and initializes the DFU transports (serial). Then it just waits for the transfer to begin. 
 If you look at the transfer init packet sequence chart, you pretty much have already transferred this image, so find out what happens in the bootloader when you typically send the execute command. What does the bootloader do then? 
 It stores the new settings, and then gets ready to receive the rest of the image. Since this is already transferred, you need to check what the bootloader does when you send the execute command after the image is transferred. 
 
 Have you thought about what will happen if there is something wrong with the packet that you have transferred over BLE in the application? Do you intend to run a dual bank, so that you have a fallback if the CRC doesn't match for the application image?

DFU via own protocol

Top Replies