DFU and Bootloader Debugging

[WestCoastDaz]

What's the best way to debug an application that is not starting after an OTA DFU update. The app said the update was successful but nothing booted and it didn't even seem like the CPU was running. The boot loader wasn't even advertising DFUTarg. I checked the boot loader settings at 0x7F000 and the app was marked valid but the CRC didn't match the one in the init file. This isn't correct right?

Also I noticed that all example DFU applications have the end of FLASH in the link scripts at 0x7FFFF not 0x79FFFF.

Thanks

[bjorn-spockeli]

I would start by debugging the bootloader and verifying that it reaches bootloader_app_start(DFU_BANK_0_REGION_START) and executes without asserting. If the bootloader_app_start() function executes without asserting, then the bootloader has successfully branched to the application, suggesting that the issue lies in the application. If this is the case, then I would start a debug session with the application and see if it ended up in the hardfault handler.

[WestCoastDaz]

Bjorn,

Thanks for the tip. It turned out that the application was hard faulting due to an extra nrf_drv_clock_init() call in our FreeRTOS implementation. During my debugging I found some strange things I am hoping you can comment on:

1. The application wouldn't produce a hardfault when the bootloader wasn't present. My guess is this is because the bootloader has set up the clock and this call was redundant when jumping from the bootloader to the application?
2. When the app was uploaded via DFU and I attached to the running target from my bootloader project I could debug both the bootloader and the application correctly. When I tried to attach to the running target from my application project with the bootloader in FLASH it's like the interrupts were still forwarded to the bootloader in the MBR. Any idea what would cause this?

Thanks

[bjorn-spockeli]

1. Yes, since the device does not reset when jumping to the application, the Clock peripheral would be initialized by the bootloader and reinitializing it in the application will lead to a Hardfault.

2. No, not really. The MBR will forward interrupts to the bootloader if a bootloader is present, the bootloader will then check if there is a SD present. If the SD is present the BL will initialize it, resulting in the MBR forwarding interrupts to the SD instead of the BL. However, the BL will also configure the SD to pass on interrupts by calling sd_softdevice_vector_table_base_set(BOOTLOADER_REGION_START). Just before the BL jumps to the application it will tell the SD to forward interrupts to the application, i.e. sd_softdevice_vector_table_base_set(CODE_REGION_1_START). After this point only the Application should receive interrupts. Does the application advertise?

[WestCoastDaz]

Bjorn,

2. No the application wasn't advertising. I think maybe the reason is the debugger was set to run to the application main after downloading to the target. Maybe it was somehow bypassing the boot loader which is why the interrupts didn't get forwarded to the application. Do you think this may have been the cause?

Thanks

[bjorn-spockeli]

Hi Darren,
I apologize for following up this late. Have you been able to solve this issue?