FX3 Boot / Firmware Update Best Practices

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Hi there,

We're getting oriented building a device using the FX3 USB controller, and are wondering what the best practices are for boot, firmware update, and flash layout.

  • What is the preferred method to implement firmware updates: in our firmware, or by falling back to the bootloader?
  • If it's using the bootloader, what's the best way for the firmware to trigger a reboot into the bootloader / USB fallback?  Can it be done via CPU registers or similar technique?
  • For using the bootloader for firmware updates, we want to use our own VID/PID.  We see you can override those with a dummy boot image containing the VID/PID. Can you store both the VID/PID override, and a full firmware image on the same SPI flash device?  We don't quite see how to have a regular firmware image and the fallback VID/PID stored on the same flash chip. 
  • What's the best way to handle failed firmware updates?   We would ideally like to keep the previous image operational until the new firmware image is completely flashed - is there an easy method to support A / B firmware images with the FX3, so that the A firmware image keeps working until a B firmware is fully loaded?

Any suggestions here are appreciated!

pv

0 Likes
1 Solution
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi,

You can consider implementing a Fail-safe boot; details of which are given below:

  1. SPI Flash will have 2 firmware images along with the second stage bootloader code, for implementing fail safe mechanism.
  2. When firmware upgrade will be done, the older version among the 2 images will be upgraded so that even if the upgrade corrupts the image, the other image will act as a backup. Second stage bootloader should boot always the latest good image, among the 2 images.

Second Stage Bootloader firmware logic:

  1. The image in the SPI Flash will be stored/ is expected by the second stage bootloader to be saved in the format as shown in the below figure.
  2. Upon power on, FX3 will boot from SPI Flash, the second stage bootloader code.
  3. Second stage bootloader code will check the validity of the firmware Image1 and Image 2. If both are valid the second stage bootloader will find the most recent one by comparing the FW headers read from the SPI flash and boots the image whose firmware version is greater. If both firmware versions are equal, it will go for Image 1.

If the booting of the selected image failed, then the second stage bootloader will boot the other image. If both fails, FX3 will fall back to USB boot.

2nd stage bootloader (Base: 0x00000000)

Image 1 (Base: 0xZZZZZZZZ)

Image 2 (Base: 0xZZZZZZZZ)

Note:

Please refer to BootAppGcc firmware which is present in FX3 SDK examples to understand

  1. How second stage bootloader loads a firmware image from SPI Flash/I2C EEPROM

               (The Base address mentioned in the above figure is used in this step)

    ii. How the control is passed from second stage bootloader to the firmware loaded in the above step.

               (The entry point of a firmware image can be obtained using elf2img.exe present in the following path:

                 Install Path\EZ-USB FX3 SDK\1.3\util\elf2img)

Firmware example path: Install Path\EZ-USB FX3 SDK\1.3\firmware\boot_fw\src

Firmware Upgrade logic:

  1. The firmware upgrade can be done using a Vendor interface/ other based on the application.
  2. Once the firmware upgrade command is received by the application firmware, the application firmware will program the SPI flash with the new firmware.
  3. The application image which is active will update the inactive image. For example, if Image 1 is running on the chip and the firmware upgrade command is received, then image 1 will update the Image 2 location of the SPI flash and vice versa.

Once the firmware update is done, the application firmware will initiate a device reset to boot with the new firmware.

For your question regarding how to jump to second stage bootloader:

Refer to CyU3PUsbJumpBackToBooter() call in USBBulkSrcSink firmware present in the following path:

(Install Path\EZ-USB FX3 SDK\1.3\firmware\basic_examples\cyfxbulksrcsink)

Regarding the VID/PID:

1. As per the above implementation, when either of/both of the firmware Image1/ Image2 is valid then the valid/latest one is loaded and starts executing. So, in this case the device comes up with the PID which is present in your descriptor file of your firmware.

2. When both the images are invalid, then the second stage bootloader falls back to USB Boot. In this case, you can have a different PID combination so that your device comes up in the Host as a Bootloader device.

This PID would be present in the descriptor file of your second stage bootloader firmware.

So, I hope you have two PID combinations available associated with your company's VID.

(Note that if you are using cypress's cyusb3.sys driver with your own VID and PID, then,

you will have to remove all the Cypress's VID/PID entries from your driver inf file when you go for Driver certification)

Regards,

Hemanth

Hemanth

View solution in original post

3 Replies
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi,

You can consider implementing a Fail-safe boot; details of which are given below:

  1. SPI Flash will have 2 firmware images along with the second stage bootloader code, for implementing fail safe mechanism.
  2. When firmware upgrade will be done, the older version among the 2 images will be upgraded so that even if the upgrade corrupts the image, the other image will act as a backup. Second stage bootloader should boot always the latest good image, among the 2 images.

Second Stage Bootloader firmware logic:

  1. The image in the SPI Flash will be stored/ is expected by the second stage bootloader to be saved in the format as shown in the below figure.
  2. Upon power on, FX3 will boot from SPI Flash, the second stage bootloader code.
  3. Second stage bootloader code will check the validity of the firmware Image1 and Image 2. If both are valid the second stage bootloader will find the most recent one by comparing the FW headers read from the SPI flash and boots the image whose firmware version is greater. If both firmware versions are equal, it will go for Image 1.

If the booting of the selected image failed, then the second stage bootloader will boot the other image. If both fails, FX3 will fall back to USB boot.

2nd stage bootloader (Base: 0x00000000)

Image 1 (Base: 0xZZZZZZZZ)

Image 2 (Base: 0xZZZZZZZZ)

Note:

Please refer to BootAppGcc firmware which is present in FX3 SDK examples to understand

  1. How second stage bootloader loads a firmware image from SPI Flash/I2C EEPROM

               (The Base address mentioned in the above figure is used in this step)

    ii. How the control is passed from second stage bootloader to the firmware loaded in the above step.

               (The entry point of a firmware image can be obtained using elf2img.exe present in the following path:

                 Install Path\EZ-USB FX3 SDK\1.3\util\elf2img)

Firmware example path: Install Path\EZ-USB FX3 SDK\1.3\firmware\boot_fw\src

Firmware Upgrade logic:

  1. The firmware upgrade can be done using a Vendor interface/ other based on the application.
  2. Once the firmware upgrade command is received by the application firmware, the application firmware will program the SPI flash with the new firmware.
  3. The application image which is active will update the inactive image. For example, if Image 1 is running on the chip and the firmware upgrade command is received, then image 1 will update the Image 2 location of the SPI flash and vice versa.

Once the firmware update is done, the application firmware will initiate a device reset to boot with the new firmware.

For your question regarding how to jump to second stage bootloader:

Refer to CyU3PUsbJumpBackToBooter() call in USBBulkSrcSink firmware present in the following path:

(Install Path\EZ-USB FX3 SDK\1.3\firmware\basic_examples\cyfxbulksrcsink)

Regarding the VID/PID:

1. As per the above implementation, when either of/both of the firmware Image1/ Image2 is valid then the valid/latest one is loaded and starts executing. So, in this case the device comes up with the PID which is present in your descriptor file of your firmware.

2. When both the images are invalid, then the second stage bootloader falls back to USB Boot. In this case, you can have a different PID combination so that your device comes up in the Host as a Bootloader device.

This PID would be present in the descriptor file of your second stage bootloader firmware.

So, I hope you have two PID combinations available associated with your company's VID.

(Note that if you are using cypress's cyusb3.sys driver with your own VID and PID, then,

you will have to remove all the Cypress's VID/PID entries from your driver inf file when you go for Driver certification)

Regards,

Hemanth

Hemanth
Anonymous
Not applicable

Perfect - that's super helpful!  Thank you for the detailed writeup.

As a followup: what's the typical usage of the built-in bootloader in conjunction with the VID/PID override boot image (empty firmware image with 0xB2 header ID)?   I noticed that wasn't among your suggestions.  We're wondering how other customers usually incorporate that technique.

Many thanks,

pv

0 Likes

Hi Paul,

Please refer to the following thread

FX3 ROM Bootloader VID / PID Override Usage

Thanks & Regards
Abhinav

0 Likes