Hello everybody,

I'm aware of the USB fallback option when booting from SPI Flash. I have sucessfully created Firmware images with the ELFtoIMG util. I managed to programm these images into Flash width Cypress USB Control Center and boot those images.

Now I want to accomplish something "different". Imagine the following scenario:

1) I programmed 2 valid firmware images into the SPI Flash each image occupies about 4 sectors (256K).

2) The FX3 Bootloader finds the first image and boots from it.

3) The first image completely replaces itself (Code, Data, everything) with the second image at runtime.

Is that possible? What would be a suitable approach to do it?

My first idea was to reinvoke the FX3 Bootloader somehow with a modified SPI read address, so that it loads the second image and hands over control to it, maybe doing a warm boot in the process.

Or do I have to make the frist firmware overwrite itself Byte by Byte in memory and start executing from it?

Thanks in advance.

Karsten Hohmeier

Hi,

You can do the following thing:

1. You can have a single .img file where you club both the image files with some known offset.

2. Your first application firmware code should have support for loading the second image from the known address. You can refer to second stage bootloader for clarity on this.

3. Once the new image file is loaded it will just run like you downloaded the .img file when FX3 enumerates as a bootloader device.

Please let me know if you need any clarity on these steps.

Thanks,

sai krishna.

Hello,

thanks for the reply. Perhaps I should further clarify my issue:

The FX3 based application I develop has to be compatible to an existing USB Client API, which also provides API functions for firmware updates that have to be implemented on FX3. This rules out the USB Boot fallback option. The FX3 always has to boot into a state, where he can handle our API calls via USB. To achieve this we want to equip the final device with a two stage firmware. The first image is our custom bootloader that can handle firmware update requests, even if the main firmware is corrupted. If the main firmware is ok, our custom bootloader should load it and continue executing from it. Both firmwares have to exist as seperate images in the SPI flash and the custom bootloader must NEVER be flashed by the customer, only the main firmware gets flashed.

I looked at CyU3PUsbJumpBackToBooter. It does some reinitialization and continues executing from the address provided via the function parameter, right? So it requires the Code to be already present in memory when it is executed. That is why you proposed to club 2 applications into 1 image file, since the transfer into memory is done by the 1-stage bootloader from the FX3 ROM, right?

This would have 2 major drawbacks for us:

1) The image files would get very large

2) We would still have to flash the entire firmware image when updating the firmware (defeats the concept of a two stage firmware)

So I still need to know, is there a convenient way to REPLACE the entire application code present in the FX3 memory at runtime and RESET the device in a way that it continues to execute the replacement code?

If not, we probably have to break compatibility to our API and rely on the USB Boot fallback option, the FX3 provides.