Problem with bootloader and dfu

RE: Problem with bootloader and dfu

Alexc — Wed, 13 Mar 2019 14:41:11 GMT

Hi,

Apologies for the late reply, I got pulled away from this issue. However after revisiting it I have managed to sort my DFU woes.

The application skipping the bootloader and the bootloader not being recognised as a bootloader, was solved by editing the linker script to not build with the softdevice as when I built it using visual gdb it merged the file with the softdevice causing it to only be recognised as an application. By splitting the two then merging them using the mergehex command it created a hex file that worked correctly.

The issue regarding the application not being passed to through the bootloader was solved by altering the bank valid app in bootloader_settings.c as mentioned in this thread.

Many thanks for your time and help

RE: Problem with bootloader and dfu

Einar Thorsrud — Thu, 14 Feb 2019 12:18:26 GMT

I see. Can you verify that the application start address is indeed 0x23000? And just in case, can you also verify the SoftDevice is present in the flash?

RE: Problem with bootloader and dfu

Alexc — Thu, 14 Feb 2019 10:35:02 GMT

So all my application does at present is advertise and connect with a different name. I have tested this without the bootloader and it works as expected so I know its not working as when the dfu transfer finishes the device does not advertise. I have also tried a fresh OTA DFU setup with the blinky example, which also works without the bootloader, but does exactly the same thing as my application when I try using OTA DFU with the bootloader. Additionally I have tried this on multiple nrf52 DK boards, all of which show the same behaviour.

RE: Problem with bootloader and dfu

Einar Thorsrud — Thu, 14 Feb 2019 08:37:39 GMT

The RTT log shows that the bootloader starts the application (at least it branches to where the application is supposed to be located). How do you know that the application is not running? Could it be that there is some error in the application that prevents it from working as you would expect? Have you done any debugging in the application? (It could be easier to test the application first without a bootloader so that you know it works properly before you flash the bootloader.)

RE: Problem with bootloader and dfu

Alexc — Wed, 13 Feb 2019 15:16:40 GMT

Hi,

Thank you for your reply, so after testing with the RTT logs and debug bootloader I can confirm that the DFU completes fine on the nrf side. I've tested it with both my own application and the blinky example, both run fine when flashed without the bootloader, but fail to actually boot when transferred across with OTA DFU.

Regarding the UICR register I will have a more in depth dig into it now that I have a better idea of what may be causing it.

RE: Problem with bootloader and dfu

Einar Thorsrud — Wed, 13 Feb 2019 11:42:07 GMT

Hi,

1. Do you see that DFU completes from the nRF side as well? Have you tested with the debug bootloader with RTT logs?

2. The only reason I could think of for "ignoring" the bootloader is if you for some reason erased the UICR register after flashing the bootloader, or the bootloader .hex file did not contain the bootloader start address in UICR. The reason is that the MBR (residing in the first flash page, starting at address 0) will check the UICR for a bootloader start address. If it is not found (register is all FF's), it will jump directly to the application instead. This is confirmed by the fact that you see nrf_dfu_svci_vector_table_set() returning NRF_ERROR_NO_MEM, which only happens if NRF_UICR->NRFFW[0] is all FF's.