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

[RVM]

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]

Hello,

Yes, this flow is supported and 0xA60 is the address to the HardFault_Handler() in the MBR, so the question is what triggered the fault. A good start to troubleshoot this might be to read out the flash before and after performing a DFU, then compare the two using a diff. If you are uploading the same bootloader binary as the one you programmed initially, you should expect the contents of the bootloader section to remain unchanged.

(https://docs.nordicsemi.com/bundle/sdk_nrf5_v17.1.0/page/lib_bootloader.html )

Reading out flash with nrfjprog

nrfjprog --memrd 0x0 --n 0x100000 > flash_content.txt

Best regards,

Vidar

[RVM]

Hi Vidar

Thanks for your responses. This problem does NOT show up if I start my experiments with the full system application (Buttonless DFU) and then download just the boot loader update.  

NOTE: Our boot loader protects itself from modification so I do not expect the new firmware to be actually written to the device. I was simply testing that our devices resume operations with the prior boot loader itself. And that is where I ran into this issue when I used just the SD and our boot loader (without the Buttonless DFU application) on the device.

[RVM]

In any case, I think this use case does not warrant too much investigation so I am okay to close this request. 

[Vidar Berg]

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]

Following up on the previous observations, 

I am now attempting to download a newer boot loader (just the boot loader and NOT the SD+MBR and NOT the Application). 

I connect to the buttonless DFU app via the Nordic Connect application on my Android phone.
I then launch the DFU process and set the Boot loader ZIP package file generated via the usual workflow that uses the 'nrfutil pkg generate' command. 

The phone application successfully reboots the buttonless DFU app into boot loader but does not appear to stay connected long enough to perform any data transter (at least does not appear to be doing so). The remote device continuosly keeps disconnecting and the NRF Connect app on my android phone continuously attempts to connect to the DFU target device.

I got frustrated and shut down the NRF Connect application on my phone. Ten minutes later, I fire it up and scan the BLE target device and it "SHOWS THE NEW BOOTLOADER IS ACTIVE". 

This is very strange -- why does the phone app keep attempting to connecting to the BLE device even though the remote has SUCCESSFULLY UPDATED THE BOOTLOADER?

Cheers

RVM