Secure DFU bootloader problem nRF52832

Question

I have a strange problem with the secure bootloader. 
 After a succsessful DFU update of firmware, the firmware starts, but resets after a short while (about a second). 
 Using RTT log, I can't see any reason for the reset (with no calls to APP_ERROR_HANDLER).
When I reprogram the firmware (with same firmware) with the IAR Embedded Workbench IDE, the firmware runs fine. 
 I have performed a readback of the entire memory after DFU, and after programmed with IAR, and the only difference in flash is at address 0x0007E000 - 0x0007E07, as I understand is in the MBR segment.
Before and after a DFU, these locations are blank (0xff).
After programmed with IAR, these locations are set to something. As I understand, these data tells where the the bootloader starts. I have tried setting these locations manually, but it does not make any diffence. The reset behaviour is the same with and without data in these locations. 
 The device I am using on my board is NRF52832. 
 What I have done: 
 
 Implemented buttonless DFU in the firmware using the "ble_app_buttonless_dfu" example project from SDK12.2.0 as template 
 Modified the bootloader_secure example project in SDK12.2.0, basically removed the button and LED handling, as my board does not have any buttons. 
 Generated new public key and replaced "dfu_public_key.c" (nrfutil keys display). 
 Built the bootloader_secure example project. 
 Merged the .hex file from the bootloader_secure example project with softdevice S132 ver.3.0.0 .hex file (mergehex). 
 Erased chip and programmed the resulting .hex file from the merge (nrfjprog). 
 Reset the chip (nrfjprog). 
 Generated private key. 
 Made a firmware update .zip package (nrfutil pkg generate) with correct key. 
 DFU updated the chip with firmware using nRF Connect for Android. nRF Connect reports success. 
 
 After DFU update, the device behaves as described above.
After (re)programmed with IAR, the device works fine. 
 Is there something I have forgot? 
 Regards, Jan

janR · Accepted Answer

I finally got this to work.
It turned out that it wasn't related to bootloader at all. 
 I use the FreeRTOS in my application. I have used "ble_app_hrs_freertos" example project as a starting point.
It turned out that if I built the "ble_app_hrs_freertos" project and used the bootloader to flash, this application ran just fine. 
 When I looked after differences between "ble_app_hrs_freertos" and my application, it turned out that I had added some HW init between the softdevice BLE stack init and the while() loop in ble_stack_thread that handles events from softdevice. I guess it took too long time from BLE
stack was initialised until events were handled, so the softdevice throwed an exeption. This exeption reset the processor.
I guess I have to implement some code to handle this in a better way, as I didn't catch this. 
 After I moved the HW init to another thread, the application ran fine. 
 I'm not sure why the application didn't chrash when running without bootloader, but I suspect there is timing differences involved with and without
bootloader. 
 Anyway, thanks for helping. 
 Regards, Jan