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]

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?