We have problems with the restart which the application does after receiving the DFU attribute is written.
Startup should work like this as I understand it: the reset vector resides at addr 4, and points to 0x8e9 in MBR. MBR checks if there is any copy command (for activating a new SD and/or bootloader). If not it jumps to the bootloader. The bootloader checks if the application has requested DFU entry, if not and crc is ok then it jumps to the application (using the vector at 0x26004).
Our problem is that MBR never jumps to the bootloader, it jumps to 0x24D39 in the SD which starts the application (via vector at 0x26004). This means that when I write the enter-DFU attribute in the application the bootloader is not started, it just restarts the application.
We use nRF52832, IAR 8.40 and Nordic SDK 15.3. We have removed compiler optimization from the bootlader and relocated it to 0x70000.
Notes:
1. IAR places the vector 0x0007E000 at address 0xFFC, which cause it to erase the rest of the MBR, which cause the CPU to load FFFFFFFF to SP and PC. I dont understand what this vector is for. To remedy this I added option "download extra image" with a hex file containing the MBR and this mystery vector. MBR was extracted from the SD hex file.
2. When starting the debugger with the bootloader IAR loads the vector base to 0x70000 skipping MBR. This is not a problem for now. Setting --drv_vector_table_base=0 forces start via MBR.