The TPS25751 and TPS26750 is a highly integrated stand-alone USB Type-C® and Power Delivery (PD) controller optimized for applications supporting USB-C PD Power. The PD Controller application binary can be pushed over I2C to the PD controller using the I2Ct port, or the PD controller can read from an external EEPROM at target address 0x50 on the I2Cc port. When the host must update the Patch Bundle used for booting, the host must follow a particular process. The EEPROM-update process uses 4CC ASCII commands to enable the host to download the patch bundle onto the external EEPROM.
USB Type-C® is a registered trademark of USB Implementers Forum.
All trademarks are the property of their respective owners.
This application note details the EEPROM update process of the device by enabling external hosts to program the patch bundles onto the attached external EEPROM using the host interface of the device.
The document also details the EEPROM boot flow, how to update the EEPROM image, and an EEPROM update example through flow charts and code examples.
During the boot process, the PD controller can load the Patch Bundle from the external EEPROM connected to the I2Cc port as described in the following. After the PD controller is in the APP mode, that is MODE register reads as APP, the host can write to the EEPROM as described in the following to update the Patch Bundle used for booting the PD controller. During the process the previous Patch Bundle is kept intact so that the PD controller can boot from the Patch Bundle in case errors occur when writing the new Patch Bundle into the EEPROM.
The Patch Bundle contains a FW patch image in addition to a set of configurations that set the default value of the Host Interface (HI) registers.
The EEPROM is divided into two regions to allow for it being updated without invalidating the previous Patch Bundle until the new Patch Bundle has been verified. The active region is the one containing the latest Patch Bundle.
At boot, the PD controller can first read the Header_ID from the Low Region at the address LowRegionStart and LowAppConfigOffset. If any error occurs in reading the Low Region Header_ID, the PD controller can then read the Header_ID from the High Region at the address HighRegionStart and HighAppConfigOffset. If any error occurs in reading the High Region Header_ID, the PD controller can loop back and try the Low Region again. The PD controller can only make two attempts, after that PD controller aborts the EEPROM loading process.
If the PD controller reads the correct Header_ID (PD controller is expecting 0xACE0_0001) in the Low Region, then it can begin reading the Patch Bundle from the Low Region. If there is a CRC error while reading the Patch Bundle, the PD controller does not attempt to read from the High Region. If the PD controller reads the correct Header_ID in the High Region, then it can begin reading the Patch Bundle from the High Region. If there is a CRC error while reading the Patch Bundle, the PD controller can attempt to read from the Low Region. However, the PD controller does not make more than two attempts on any region.
Therefore, when updating one of the regions of the EEPROM it is critical to verify the new Patch Bundle in the region before pointing the Region Start to it.
If the EEPROM loading process is aborted, then the PD controller can update the BOOT_STATUS register accordingly and assert the INT_EVENTx.ReadyForPatch interrupt. the PD controller then waits indefinitely for the host to load a patch over the I2Cc port or to issue a GAID 4CC command to reboot the PD controller. This behavior also occurs when there is no EEPROM present.
Figure 2-1 shows the memory map of the EEPROM and where the pointers and offsets reside assuming that the EEPROM has initially been written with the same Patch Bundle in both regions. The PD controller looks for the Header_ID of the Low Region at address LowRegionStart and LowAppConfigOffset, and it looks for the Header_ID of the High Region at the address HighRegionStart and HighAppConfigOffset.