DFU and Bootloader Debugging

RE: DFU and Bootloader Debugging

bjorn-spockeli — Wed, 25 Jan 2017 10:00:12 GMT

@AnnaSBX: Can you create a separate question where you describe your issue in detail?

RE: DFU and Bootloader Debugging

AnnaSBX — Mon, 23 Jan 2017 16:26:13 GMT

But how I can debug it? In my case I think that the bootloader didnt recognize the app and stay in DFU mode. I can not succses to put a breakpoint and no have an idea how to debug it :(

RE: DFU and Bootloader Debugging

bjorn-spockeli — Mon, 11 Jul 2016 09:21:17 GMT

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

RE: DFU and Bootloader Debugging

WestCoastDaz — Wed, 04 May 2016 05:42:34 GMT

Bjorn,

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

RE: DFU and Bootloader Debugging

bjorn-spockeli — Tue, 03 May 2016 11:03:31 GMT

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.
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?

RE: DFU and Bootloader Debugging

WestCoastDaz — Tue, 03 May 2016 03:30:56 GMT

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:

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?
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

RE: DFU and Bootloader Debugging

bjorn-spockeli — Mon, 02 May 2016 12:55:11 GMT

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.