MBR after DFU not working

[amarin]

Hi,

I am currently working on an internal dfu modeled after the secure_bootloader_uart/ example in SDK 15.3.0. I have gotten the dfu to perform a successful dfu with the blinky example, but the application does not start. I have compared the output to the output of the secure_bootloader_uart_debug/ example and I find no unexpected differences. What I ended up doing to make sure that the blinky example is correct is using nrfjprog --sectorerase --program mbr_nrf52_2.4.1_mbr.hex and press the reset button and it works. This leads me to believe that some how the MBR is being disabled or needs to be reenabled, but I do not know how to do this or if this is actually the case. I checked to see if the MBR was being overwritten and that is not the case. If anyone has any ideas as to how I should go about fixing this, please let me know!

[ovrebekk]

Hi 

Are you using one of the standard Nordic development kits?
If so, which one?

When the DFU operation works with the blinky example, how do you send the update to the board?

Best regards
Torbjørn

[amarin]

I am using the nrf52840 dk with the 15.3.0 SDK. The way I am currently doing it is storing the update in the external memory. When the bootloader goes into dfu mode, it will check specific addresses in external memory for the init packet and the firmware packet. When they are found, the dfu will do the same protocol as it would in the secure_bootloader_uart/ example, but instead it will copy from external and write to flash memory. Sending the update to the external memory is done in the application, which I will be working on after I can get the dfu to work with the external memory. So far, I am only focusing on getting the dfu to work.

[ovrebekk]

Hi 

The MBR is stored in the first 4k of the flash. Have you tried to read out the content of this region after running your custom bootloader, and see if it changes once you run 'nrfjprog --sectorerase --program mbr_nrf52_2.4.1_mbr.hex' ?

If there is no change I don't understand how programming the MBR would fix the issue. 

Also, are you able to debug your bootloader application?

Then you can check if something goes wrong when the bootloader tries to load the application, and you can also verify that the start address of the application is correct (0x1000 I assume, if the application starts just after the MBR region).  

Best regards
Torbjørn

[amarin]

Hi, 

I did as you said and see that there is one line of code that is different between my internal dfu program and when I manually reprogram the MBR after it. I am attaching a picture of the hex file compare result I used to compare the content.

 

On the left is the code after I reprogram the MBR and is working while on the left is the code read after the internal dfu is performed. I do not know where the first line of code is coming from since nowhere in my external memory does that line of code exist as seen in the mem.hex file attached. 

 8664.mem.hex

[ovrebekk]

Hi

Then I assume it must be the internal DFU that is somehow writing to address 0xFF8, inside the MBR region?

Do you have a check in the code to verify that you are not writing outside the application area? 

Maybe you could try to debug the bootloader when it is running to verify if or when it tries to write to this region?

Best regards
Torbjørn