Switch between Bootloadable images without reset

[DrLu_1518341]

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).

Any pointers are welcome! Thanks in advance.

[Alakananda_BG · Accepted solution]

Hi,

You can refer to the below thread

Re: How to jump to application from bootloader without software reset?

Regards

Alakananda

[Len_CONSULTRON]

DrLu,

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:

https://www.cypress.com/documentation/application-notes/an213924-psoc-6-mcu-device-firmware-update-s...

https://community.cypress.com/docs/DOC-18762

Len

https://www.cypress.com/documentation/application-notes/an213924-psoc-6-mcu-device-firmware-update-s...

[DrLu_1518341]

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.