What you are asking to do should be possible.(?)
The issue you are going to face is that your Bootloadable component needs to have the Bootloader in it as a separate element. If you don't, the standard Bootloader is expected to enter execution from a reset which violates your requirements.
Are you using FreeRTOS (or other RTOS) on your project? If not you might consider it. You can allocate a Task called "Bootload" that only runs when a Firmware update is requested. It can handle the comm to update the other image of the Application. If the download of the new code is successful, you can force update all the needed pointers to start the new App image. It will be very tricky but it is possible.
Check out the DFU functions of the PSoC6 ecosystem. It is intended to support core OTA (Over-the-Air) firmware updates features. I can't speak as to whether a reset occurs in the DFU or not.
Here's some links to the DFU:
Thanks for the links. It seems I will need these modifications:
1) the base bootloader configures all hardware identically to the bootloadables (so that bootloadables can leave hardware unmolested at boot)
2) bootloader needs to jump to main() of bootloadables, which then need to avoid re-initializing peripherals
3) bootloadables MAY need their own copy of bootloader to avoid Soft Reset, or
3b) bootloadable must reconfigure interrupt vector and possibly stack before executing code of alternate image.
Does that sound right?
This code does use FreeRTOS, but I'm not convinced a dedicated Bootload task solves any problems - we already have the code to download/update the standby image, and once we decide to load it we can consider this a single thread. Since a new image will likely have a different RAM map, I will have to store state variables in EEPROM or flash anyway, and the tasks need to be updated to restore themselves rather than initialize. So it's mostly an exercise in careful memory management.