Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
I have a Dual-App Bootloader and two identical Bootloadable applications in a PSOC5LP. I have functioning code that updates one image while executing out of the other. Now I need to be able to switch from one image to the other, after updating it, WITHOUT issuing a reset ("hitless upgrade") that affects I/O pins (power supply enables, peripheral resets, etc) or SRAM (task state machine variables, register settings).
Is there a well-understood mechanism to pass control from one application image to another, or to do so via the bootloader but without service-affecting reset?
I figure it should be possible (if arduous) to ensure both images point to the same memory structures, and upon booting the image decide whether or not to initialize based on the reset source (or just a bit in memory).
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.
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.