OTA/DFU of identical bootloader ZIP package fails to relaunch the new bootloader.

Question

I am running the boot loader with the default name 'DfuTarg' on a Nordic NRF52840 board very similar to the PA10056. I download this boot loader to the board, connect to it using NRF Connect app on my Pixel phone, and select the DFU icon. I then select the OTA DFU file that I created of the same boot loader. The file gets transferred and validation appears to pass but at the end the Segger IDE stops at a hardware breakpoint at vector 0xA60 (hardware fault?). 
 I expected the boot loader to simply disconnect, reboot and be prepared again for the next DFU but it ended up with a vector exception to 0xA60. This is a very repeatable process regardless of how many times I try it. Before each attempt, I completely erase the flash on the board and re-download the first boot loader program that starts on the board. 
 I think this is my misunderstanding of the system level workflow. Does the Nordic OTA+DFU ecosystem support a simple boot loader supporting its own update without an application? 
 Cheers RVM

Vidar Berg · Accepted Answer

I'm afraid I don't have an explanation for why you are not seeing the same with the application present. 
 RVM said: Our boot loader protects itself from modification so I do not expect the new firmware to be actually written to the device. 
 You bootloader should issue the SD_MBR_COMMAND_COPY_BL command MBR when it wants to update itself. This will trigger a reset before the copy routine starts and the flash protection will be disabled at the point.

RVM · Answer

Looks like the failures were due to a couple of issues with our firmware design. Here is the summary: 
 
 We have a small algorithm that runs when the Central device requests our device to boot into DFU mode. This algorithm checks the current boot loader to determine if it has the correct values at specific flash memory locations (known a priori from an offline analysis of the boot loader program). One such address was invalid and the memory read generated a hardware fault. As a result, the application would reboot from the hard fault handler -- but in NORMAL BOOT mode and NOT in DFU mode. 
 The address trap values written to the FPB register was wrong. Consequently the 'flash patch' was never being triggered and applied when the boot loader was executing. 
 
 Addressing and fixing the above two bugs allowed me to update the boot loader with OTA DFU from a BLE Central device. 
 
 Cheers 
 RVM

OTA/DFU of identical bootloader ZIP package fails to relaunch the new bootloader.

Top Replies