some problems about Integrating 2 application firmwares on 51822

Question

Hi,
For providing OTA function , I add dfu service into my own application APP1. and create another application App2 to copy the new firmware(named APP3) and cover the flash area, where APP1 is burned. the new firmware is received, saved and verified by APP1,
maybe this is confusing. there are some details: 
 Address start/end size	name usage
0x3C800-0x3E800 8K APP2 earse APP1's flash area, cover APP1 using APP3's content
0x28400-0x3C800 81K	APP3	a new firmware is stored here, waiting for being burned
0x14000-0x28400 81K	APP1	include some gatt services and DFU service. Accept new firmware and stored into area APP3.
0x00000-0x14000 80K	softdevice ble protocol stack 
 So the normal process is like this: when APP1 received new firmware, it will stored to flash area(start from 0x28400), then jump to run APP2(started from 0x3C800). APP2 will copy content(located in 0x28400-0x3c800) into flash area(0x14000-0x28400), then jump to 0x14000.
the intent is implementing firmware update over the air. 
 Problem 1: test on my product , sometimes it will succeed，most time it will fail. test on nrfgo motherboard always fail.
take the motherboard for example, I see app1 output logs that new firmware is received, stored and vertified. But no any log from app2.
for my product, sometimes it will succeed to advertise(a device name that is set by new firmware),
sometimes it has no action and advertise the new device name after reconnecting lithium battery. and sometimes it still advertise the old device name after reconnect battery, that means fail. 
 Problem 2: is it permitted to do like this? 
 bootloader_app_start (0x00014000);
bootloader_app_start(0x0003C800);
void bootloader_app_start(uint32_t app_addr)
{
// If the applications CRC has been checked and passed, the magic number will be written and we
// can start the application safely.
interrupts_disable(); 
 uint32_t err_code = sd_softdevice_forward_to_application();
APP_ERROR_CHECK(err_code);

//bootloader_util_app_start(CODE_REGION_1_START);
bootloader_util_app_start(app_addr);
 
 } 
 and I have made a test, if
app1: printf("A"); bootloader_app_start(0x0003C800);
app2: printf("B"), bootloader_app_start(0x00014000);
output is "ABABAB..." . 
 Did I miss something like set/clear register, or calling softdevice's funcion?

Ole Morten · Accepted Answer

What you want is not easy to do, and is not directly supported by the softdevice. Getting this to work requires that you fully understand how the softdevice works, and how interrupts are forwarded. I'd therefore recommend you to read the appendix of the nRF51 Reference Manual very thoroughly, as well as the S110 SoftDevice specification. 
 Currently, the softdevice supports having one application and one bootloader. If a bootloader address is written to the address 0x10001014 in UICR, the softdevice will jump to the reset handler at this address when power is applied to the chip, and the softdevice has finished its own initialization. All interrupts will also be forwarded to the bootloader at this address. The bootloader can then determine whether there is a valid application in the flash, and if there is, call the sd_softdevice_forward_to_application() function, and then jump to the application's reset handler. After having called sd_softdevice_forward_to_application(), all interrupts will be forwarded to whatever handler is located at address 0x14000, and hence the application at this address will receive all interrupts, no matter which application's main function was called. 
 Therefore, I can't see any other way of achieving what you want than to locate your own bootloader at 0x14000, not use the softdevice bootloader API and instead do interrupt forwarding on your own. This should be perfectly possible technically, but it is not trivial to get right, and it will also introduce some additional interrupt latency. The bootloader that is public here does this, but it's written for gcc, and it also has a pretty significant bug that you need to work around or fix if you're considering using it.