bootloader with 2 or 3 applications

[Michal]

Hi,

I am trying to get bootloader to jump to either application 1 or 2 base on button states when booting. I am not sure how do it properly. One of the applications is using softdevice while the other is not (zigbee). I know that for ble application I need to jump to mbr which then will jump to end of softdevice (that is where ble application is placed). For zigbee application I am trying to jump directly to it but that sometimes fail. In linker script I set beginning of flash for zigbee application to page after last page from ble application. Right now looks like bootloader jumps to the application only on the first boot and on next boot it always gets stuck in bootloader. Is there something I am doing wrong that you can immediately notice? I can share more details if needed.

IN future we will be adding 3rd application also ble, what should I do in that case?

Best regards,
Michał

[Einar Thorsrud]

Hi Michał,

In principle there is nothing preventing you from having an arbitrary numbers of applications at different addresses, but you need your own bootloader or to modify the SDK bootloader. I understand that you have this basically working, as you write it works on the first boot. There is one pitfall though which I want to mention, and that is important when booting an application that is not residing immediately after the SoftDevice.

There was a change in SDK 15.0.0, where the bootloader no longer had dependencies on the SoftDevice (except for when BLE is needed). In SDK >= 15.0.0, the boot process consists of forwarding interrupts to the SoftDevice using SD_MBR_COMMAND_IRQ_FORWARD_ADDRESS_SET (nrf_dfu_mbr_irq_forward_address_set()), and then always jumping to address 0x1000 (SoftDevice start) instead of the application start address. An interesting point here is that SoftDevice reset function is not run by SD_MBR_COMMAND_IRQ_FORWARD_ADDRESS_SET, so a magic word indicating that the SoftDevice is enabled would not be reset, and the SoftDevice would still be enabled if it was enabled at some point before, even before a reset.
 
Another approach, which was used up to and including SDK 14.2 was to use the SD_MBR_COMMAND_INIT_SD and SD_MBR_COMMAND_VECTOR_TABLE_BASE_SET command, and start the application at a specific address. This is what you should use for a dual boot scenario when the application is not always immediately after the bootloader. Interestingly in this case is that SD_MBR_COMMAND_INIT_SD runs the SD reset function, which clears the magic word that indicates that the SD has been enabled. You can compare components\libraries\bootloader\nrf_bootloader_app_start.c in SDK 14.2 and a newer SDK to see both approaches.

If the above is not the problem we need to go deeper into your bootloader. Can you share you bootloader code (being your own or a modified SDK bootloader)? What is the difference in flash between the first and second boot if you dump the entire flash using e.g. nrfjprog --memrd and diff it? Has it changed, and can that explain the difference? If not, there must be something else (change in a retention register, GPIO or similar that causes the bootloader to act differently the second time.

Einar