1 of 1 people found this helpful
You can consider implementing a Fail-safe boot; details of which are given below:
- SPI Flash will have 2 firmware images along with the second stage bootloader code, for implementing fail safe mechanism.
- 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:
- 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.
- Upon power on, FX3 will boot from SPI Flash, the second stage bootloader code.
- 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)
Please refer to BootAppGcc firmware which is present in FX3 SDK examples to understand
- 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:
- The firmware upgrade can be done using a Vendor interface/ other based on the application.
- Once the firmware upgrade command is received by the application firmware, the application firmware will program the SPI flash with the new firmware.
- 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)
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.