CCG2 Power Adapter Reference Design and API Guide. Doc. No Rev.**

CCG2 Power Adapter Reference Design and API Guide Doc. No. 002-10677 Rev.** Cypress Semiconductor 198 Champion Court San Jose, CA 95134-1709 Phone (USA): 800.858.1810 Phone (Intnl): +1 408.943.2600 www.cypress.com

Copyrights Cypress Semiconductor Corporation, 2016. This document is the property of Cypress Semiconductor Corporation and its subsidiaries, including Spansion LLC ( Cypress ). This document, including any software or firmware included or referenced in this document ( Software ), is owned by Cypress under the intellectual property laws and treaties of the United States and other countries worldwide. Cypress reserves all rights under such laws and treaties and does not, except as specifically stated in this paragraph, grant any license under its patents, copyrights, trademarks, or other intellectual property rights. If the Software is not accompanied by a license agreement and you do not otherwise have a written agreement with Cypress governing the use of the Software, then Cypress hereby grants you a personal, nonexclusive, nontransferable license (without the right to sublicense) (1) under its copyright rights in the Software (a) for Software provided in source code form, to modify and reproduce the Software solely for use with Cypress hardware products, only internally within your organization, and (b) to distribute the Software in binary code form externally to end users (either directly or indirectly through resellers and distributors), solely for use on Cypress hardware product units, and (2) under those claims of Cypress s patents that are infringed by the Software (as provided by Cypress, unmodified) to make, use, distribute, and import the Software solely for use with Cypress hardware products. Any other use, reproduction, modification, translation, or compilation of the Software is prohibited. TO THE EXTENT PERMITTED BY APPLICABLE LAW, CYPRESS MAKES NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS DOCUMENT OR ANY SOFTWARE OR ACCOMPANYING HARDWARE, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. To the extent permitted by applicable law, Cypress reserves the right to make changes to this document without further notice. Cypress does not assume any liability arising out of the application or use of any product or circuit described in this document. Any information provided in this document, including any sample design information or programming code, is provided only for reference purposes. It is the responsibility of the user of this document to properly design, program, and test the functionality and safety of any application made of this information and any resulting product. Cypress products are not designed, intended, or authorized for use as critical components in systems designed or intended for the operation of weapons, weapons systems, nuclear installations, life-support devices or systems, other medical devices or systems (including resuscitation equipment and surgical implants), pollution control or hazardous substances management, or other uses where the failure of the device or system could cause personal injury, death, or property damage ( Unintended Uses ). A critical component is any component of a device or system whose failure to perform can be reasonably expected to cause the failure of the device or system, or to affect its safety or effectiveness. Cypress is not liable, in whole or in part, and you shall and hereby do release Cypress from any claim, damage, or other liability arising from or related to all Unintended Uses of Cypress products. You shall indemnify and hold Cypress harmless from and against all claims, costs, damages, and other liabilities, including claims for personal injury or death, arising from or related to any Unintended Uses of Cypress products. Cypress, the Cypress logo, Spansion, the Spansion logo, and combinations thereof, PSoC, CapSense, EZ-USB, F-RAM, and Traveo are trademarks or registered trademarks of Cypress in the United States and other countries. For a more complete list of Cypress trademarks, visit cypress.com. Other names and brands may be claimed as property of their respective owners. CCG2 Power Adapter Reference Design and API Guide, Doc. No. 002-10677 Rev.** 2

Contents 1 Introduction... 4 2 Toolchain and Build System... 5 2.1 Build Environment... 5 2.2 Source Structure... 5 2.3 PSoC Creator Workspace File Structure... 5 2.4 Build Output... 7 2.5 SDK Usage Model... 7 2.6 Firmware Versioning... 8 2.7 Supported Compile Time Configurations... 10 2.8 Supported Post-Compile Configurations... 10 2.9 EZ-PD Configuration Utility Overview... 10 3 Firmware Architecture... 12 3.1 Bootloader... 13 3.2 Firmware Operation... 14 4 Firmware APIs... 15 4.1 Device Policy Manager Program interface... 15 4.2 Policy Engine APIs... 15 4.3 Hardware Abstraction Layer... 15 4.4 User (Solution) Layer API... 17 Revision History... 19 Document Revision History... 19 CCG2 Power Adapter Reference Design and API Guide, Doc. No. 002-10677 Rev.** 3

1 Introduction CCG2 devices target power adapter application by integrating all termination resistors and using GPIOs to program the power regulator to supply the appropriate VBUS based on the UFP s requirement. In this application, CCG2 is used as source (power provider) only. The CCG2 Power Adapter SDK Consists of several basic components: Figure 1. Power Adapter SDK Structure Source Code API Source Code Reference Application Pre-Compiled PD stack Documentation API User Guide EZ-PD Configuration Utility Guide Release Notes Firmware Binaries HEX and CYACD files for Standard Application CCG2 Power Adapter Reference Design and API Guide, Doc. No. 002-10677 Rev.** 4

2 Toolchain and Build System 2.1 Build Environment CCG2 power adapter project is developed using Cypress PSoC Creator 3.2. Contact Cypress for getting access to CCG2 devices and the specified Creator installer. The compiler tool chain is ARM GCC (build 484 provided along with PSoC Creator build). PSoC Creator IDE provides an integrated environment to edit, compile, download and debug. 2.2 Source Structure The firmware source consists of two categories: Application source and stack source. Each contain sub-directories based on functionality. [projects [CYPD2134-24LQXI] folder with power adapter workspace including bootloader [power_adapter.cydsn] PSoC Creator project folder [power_adapter.cywrk] workspace file to open by PSoC Creator [power_adapter_boot.cydsn] bootloader PSoC Creator project folder Other PSoC creator related files [src] - folder with USB PD stack and system level routines [flashss] flash write and flashing command implementation (source code) [pd_common] USB-PD and Type-C stack headers [system] system level components and drivers in source form 2.3 PSoC Creator Workspace File Structure Once workspace opened in Creator, it is represented by two project. One for power Adapter and one for CC Bootloader. Both projects have similar file structure. CCG2 Power Adapter Reference Design and API Guide, Doc. No. 002-10677 Rev.** 5

Figure 2. Power Adapter Workspace Structure Toolchain and Build System Solution configuration header file Handlers for USB Type-C PD system. These files likely to be modified for final product File with configuration table This file is part of bootloader CCG2 Power Adapter Reference Design and API Guide, Doc. No. 002-10677 Rev.** 6

2.4 Build Output Toolchain and Build System The Application consists of two separate projects. The first is the bootloader and the second is the firmware application. Both projects generate an ARM ELF firmware binary as well as Cypress Hex file. The Cypress Hex file can be used to download the firmware image using MiniProg3 and PSoC Programmer Utility. 2.5 SDK Usage Model Users of the CCG2 power adapter solution will follow the below steps to make use of the SDK components: Figure 3. SDK Usage Flow START USE CCGx SOLUTION MATRIX TO IDENTIFY APPROPRIATE REFERENCE WORKSPACE USE EZ-PD CONFIG UTILITY TO CONFIGURE PARAMETERS GENERATE CONFIGURATION IN C SOURCE FORM IMPORT C SOURCE INTO SOLUTION WORKSPACE OPEN SELECTED WORKSPACE IN CREATOR OPEN <SOLUTION>_CONFIG.H HEADER FILE SELECT OPTIONS FOR SOLUTION LEVEL FUNCTIONS UPDATE VDO, PDO RESPONSE DATA BUILD PROJECTS (BOOTLOADER AND APPLICATION) SELECT Vbus / Vconn FET CONTROLS SELECT OVP / OCP DETECT METHOD SELECT DATA MUX CONTROL METHOD SELECT VDM HANDLING OPTION SELECT PD ROLE SWITCH HANDLERS PROGRAM CCG2 DEVICE (SWD OR CONFIG UTILITY) STOP 1. Load the solution workspace (notebook.cywrk or mobile.cywrk) using PSoC Creator. 2. Edit the solution configuration header file if needed. CCG2 Power Adapter Reference Design and API Guide, Doc. No. 002-10677 Rev.** 7

Toolchain and Build System 3. Use the EZ-PD Configuration Utility to build the configuration table, and copy the generated C source file into the Creator project if necessary. The configuration table can also be updated by editing the usbpd_config.c file in PSoC Creator Source Editor. 3.1. The configuration table is part of bootloader project. Build bootloader project using the PSoC Creator. 3.2. Compiled bootloader HEX and ELF that includes new configuration table is be located in CYPD2134-24LQXI\power_adapter.cydsn\power_adapter_boot.cydsn\CortexM0\ARM_GCC_493\ Debug\ power_adapter _boot.hex CYPD2134-24LQXI\ power_adapter.cydsn\power_adapter_boot.cydsn\cortexm0\arm_gcc_493\ Debug\ power_adapter _boot.elf or CYPD2134-24LQXI\ power_adapter.cydsn\ power_adapter_boot.cydsn\cortexm0\arm_gcc_493\ Release\ power_adapter _boot.hex CYPD2134-24LQXI\ power_adapter.cydsn\ power_adapter_boot.cydsn\cortexm0\arm_gcc_493\ Release\ power_adapter _boot.elf depending on selected Debug/Release configuration option. Files mentioned above should be renamed and copied into: CYPD2134-24LQXI\power_adapter.cydsn\power_adapter _boot.hex CYPD2134-24LQXI\power_adapter.cydsn\power_adapter _boot.elf 4. Build the application projects using the PSoC Creator. The firmware binaries will be generated in ELF, HEX and CYACD formats suitable for SWD programming or loading through JTAG, Miniprog and the EZ-PD configuration utility. 5. Load the firmware binary onto the target hardware for evaluation and testing. This usage flow is illustrated in Figure 3. Many of these steps such as changing the compile time configurations and using the EZ-PD Configuration Utility to change the configuration table are only required if the customer wants to make any changes to the way the application works. Note: Default PDOs in the config table are set with following source voltages: 5V, 12V, 13V and 20V. PDO source values must be changed to be compliant with USB-PD 2.0 v1.2 power rules section. Source voltages should be a subset of 5V, 9V, 15V and 20V PDOs with compliant current values as specified in above spec. The USB-PD specification has specific VBUS output voltage requirements dependent on the amount of power provided by a USB TypeC Source port. See the "Power Rules" section of the latest USB-PD specification for these requirements. USB TypeC product developers must ensure their VBUS Source hardware complies with USB-PD requirements. This SDK allows the user to customize the firmware to match the hardware design with respect to advertised Source Capabilities and VBUS output control circuitry. Ensure that all firmware settings and functionality is properly customized to the specific VBUS Source hardware design of the target application. 2.6 Firmware Versioning Each project has a firmware version (base version) and an application version number. The firmware version number shall consist of major number, minor number and patch number. The build machine updates the build number. This information is stored in a header file under the specified directories. The base firmware version shall be common for all base application solutions provided by the base firmware team. This information shall be stored in fw/src/system/ccg2_version.h. The application version shall be modified for individual customers based on requirements. This shall have a major version, minor version, external circuit specification, and application name. Each application (firmware + boot-loader) shall have a common application version information header file fw/projects/<workspace_dir>/common/app_version.h where <workspace_dir> is the MPN for the application. The version number information for each firmware shall be stored in an eight-byte data field and shall be retrieved over CC or I2C interface based on the usage model. The following table denotes the version structure and format. CCG2 Power Adapter Reference Design and API Guide, Doc. No. 002-10677 Rev.** 8

Toolchain and Build System Bit Field Name Description [15:0] Base FW Build number This field corresponds to base firmware version and shall be automatically incremented during nightly build. This field should not be manually edited. This field is expected to be reset on every SNPP release cycle and not modified throughout the release. [23:16] Base FW Patch version number This field corresponds to base firmware patch version number. This field shall be updated manually by the core PD team for base firmware releases. This field shall be incremented for every intermediate release done to customer or an actual patch release performed for a previous full release. [27:24] Base FW Minor version number This field corresponds to base firmware minor version number. This field shall be updated manually by the core PD team for base firmware releases. This field is generally updated once for every SNPP release cycle at ES100 RC build. The exception is when an intermediate customer release which breaks compatibility. [31:28] Base FW Major version number This field corresponds to base firmware major version number. This field shall be updated manually by the core PD team for base firmware releases. The major number is generally updated on a major project level change or when we have cycled through all minor numbers. The number shall be determined at the beginning of every SNPP release cycle. [47:32] Application Name / number This field is left for any application / customer specific changes to be done by applications team. By default, this field shall be released by the base firmware version team will have the following values: Notebook EMCA Power Adapter Tablet Monitor Video Dongle nb ca pa tb md do [55:48] External circuit number This field is left for any application / customer specific changes to be done by applications team. By default, this field shall be released by the base firmware team as 0. The circuit number values from 0x00 to 0x1F are reserved for base firmware team. This is because base firmware team may have to support same application on multiple platforms in the future. [59:56] Application minor version number This field is left for any application / customer specific changes to be done by applications team. By default, this field shall be released by the base firmware team as 0 [63:60] Application major version number This field is left for any application / customer specific changes to be done by applications team. By default, this field shall be released by the base firmware team as 0 CCG2 Power Adapter Reference Design and API Guide, Doc. No. 002-10677 Rev.** 9

Toolchain and Build System 2.7 Supported Compile Time Configurations All pre-processor definitions shall be maintained in a usbpd_config.h file as part of the firmware project. Every source file is expected to include the usbpd_config.h header file. There shall be only one usbpd_config.h header file per project. The following are the available pre-processor definitions available for the power adapter application. Feature Options Support VIA Adapter Connection Over Voltage Protection Captive cable OR Type C receptacle Polled OVP OR Custom Pre-processor Flag (usbpd_config.h) /* Adapter Configuration CAPTIVE_CABLE TYPE_C_RECEPTACLE */ #define ADAPTER_CONFIGURATION (TYPE_C_RECEPTACLE) Pre-processor Flag (usbpd_config.h) /* Over/Under Voltage Protection Configuration OVP_UVP_SUPPORTED OVP_UVP_NOT_SUPPORTED */ #define OVP_UVP_CONFIGURATION (OVP_UVP_SUPPORTED) 2.8 Supported Post-Compile Configurations The firmware allows changing certain features after image has been compiled. This is done via the configuration table located at a fixed flash location. EZ_PD utility can overwrite values in configuration table. Feature Options Support VIA PDO, PDO Mask Selection Update values Configuration Table Min/Max current in PDO Update values Configuration Table EZ-PD Configuration Utility is a Windows based GUI application which allows users to perform firmware and configuration updates on CCGx devices. This memorandum documents the design of the EZ-PD Configuration Utility. Please use EZ-PD guide for more information. 2.9 EZ-PD Configuration Utility Overview The EZ-PD Configuration Utility is a Microsoft Windows Application that guides CCGx user through the process of configuring and programming the chip. The utility works in tandem with Cypress supplied hardware which hosts the CCGx controllers along with a USB interface. EZ-PD Configuration Utility Guide is provided as separate document. Please refer for more information about Configuration Utility. CCG2 Power Adapter Reference Design and API Guide, Doc. No. 002-10677 Rev.** 10

Toolchain and Build System Figure 4. CCG2 Configuration Block Diagram Figure 4 shows the block diagram of the hardware setup used for programming the CCGx devices using the Configuration Utility. The target device to be programmed can be any one of the Type-C DFP Controller, Type-C UFP Controller and Type-C EMCA Controller. 2.9.1 EZ-PD Software Dependencies The EZ-PD Configuration Utility is a.net framework based Windows application and has the following software dependencies. # Software Version 1 Operating System Microsoft Windows 7 or later 2.NET Framework.NET Framework 2.0 or later 3 Visual Studio Runtime Libraries VC++ 2013 runtime re-distributable 4 USB Driver and APIs CyUsb3.sys driver and CyApi library CCG2 Power Adapter Reference Design and API Guide, Doc. No. 002-10677 Rev.** 11

3 Firmware Architecture CCG2 has 32KB flash memory that is designated to store a bootloader, configuration table, and firmware image Figure 5. Power Adapter Workspace Structure FW Metadata Reserved area 32kB CCG2 Power Adapter Firmware Configuration Table CC Bootloader 0 The bootloader is used for firmware upgrade of the CCG application. It is allocated a fixed area. This memory area can only be written to from the SWD interface. CCG2 Power adapter supports CC bootloader only. The configuration table holds the default PD configuration for the CCG application, and is located immediately after the bootloader. The configuration table can be updated through the bootloader, and has a fixed size of 512 bytes. CCG firmware area is used for the main CCG firmware application. In the case of CCG2 power adapter the main firmware spans the free area of flash left after storing the bootloader and configuration table. The main image area can be updated through SWD for manufacturing, and through the bootloader for field upgrades. The metadata area holds metadata about the firmware binaries. The firmware metadata follows the definition provided by the PSoC creator bootloader component; and includes firmware checksum, size and start address. CCG2 Power Adapter Reference Design and API Guide, Doc. No. 002-10677 Rev.** 12

3.1 Bootloader Firmware Architecture The FLASH based bootloader mainly functions as a boot-strap and is the starting point for firmware execution. It validates the firmware based on checksum stored in FLASH. The boot-strap also includes the flashing module. Figure 6. Bootloader Flow Diagram SROM FLASH START NO YES FW BOOT MODE RQT? VALID METADATA? VALID MAIN IMAGE? YES NO NO YES NO VALID FAIL-SAFE IMAGE? JUMP TO MAIN IMAGE INITIALIZE BOOT INTERFACE YES JUMP TO FAIL-SAFE IMAGE WAIT FOR FLASHING REQUESTS YES RESET REQUEST? NO The bootloader first checks whether the application firmware has issued a BOOT_MODE request. This is done based on data signature at a fixed location in SRAM. When the application firmware wants to jump to boot-loader for flashing, it shall write a fixed signature pattern CYBL to location 0x200000C4 and then jump to the boot-loader. The boot-loader shall verify the content of this location and shall always load 0x00000000 at this location after the check to prevent any false entry. If the signature is present, then it shall stay in the boot mode and await flashing instructions. If no signature is seen, it shall proceed to validate the metadata area in the FLASH. If the metadata signature fields are corrupt, it shall wait in the boot mode. If not it shall first check for a valid main firmware image in the metadata table. If a valid image is detected, it shall jump to the main firmware image. The main firmware image is expected to be the latest image. The fail-safe image is not expected to be upgraded in field and is expected to be a fallback image. If no main firmware image is detected, it stays in the boot-mode wait for flashing instructions. CCG2 Power Adapter Reference Design and API Guide, Doc. No. 002-10677 Rev.** 13

3.2 Firmware Operation Firmware Architecture The following flow diagram indicates the firmware initialization and operation sequence. Figure 7. Firmware Flow Diagram FW ENTRY BOOT ENTRY INITIALIZATION MAIN TASK LOOP LOW POWER MODE NO VALID CONFIGURATION TABLE TYPE-C / PD STATE MACHINE TASKS CONFIGURE WAKEUP SOURCES YES CONFIGURE PERIPHERAL BLOCKS DEBUG / TEST TASK ENTER LOW POWER MODE LOAD FLASH CONFIG INFO BOOT ENTRY RQT? YES WAIT FOR INTERRUPT (SLEEP MODE) NO INITIALIZE THE PD MODULE PD IDLE TIMEOUT? YES EXIT LOW POWER MODE NO INTIALIZE INTERRUPTS DISABLE WAKEUP SOURCES The following defines the simplified main loop for the power adapter application. It is intended to document major tasks called from main.c init(); // perform all required initializations timer_start(); // start timers while (1) { type_c_state_machine(); // handle type-c protocol pe_state_machine(); // handle PD protocol handle_deepsleep(); // handle deep sleep } CCG2 Power Adapter Reference Design and API Guide, Doc. No. 002-10677 Rev.** 14

4 Firmware APIs 4.1 Device Policy Manager Program interface 4.1.1 Type-C Manager APIs Function Description Parameters Return type_c_init get_typec_polarity get_typec_state type_c_state_machine Initialize the Type-C state machine Find whether the CC1 or CC2 should be used for the USB-PD transfers. Get the current state of the Type-C state machine. Returns Run the Type-C state machine task. uint32 event mask assert_rp Assert Rp on the specified channel uint8 channel Returns 0 for CC1 and 1 for CC2. (ttype_c_state) current type c state assert_rd Assert Rd on the specified channel uint8 channel remove_rp_rd De-assert Rp and Rd on the specified channel uint8 channel 4.2 Policy Engine APIs Function Description Parameters Return pe_init_policy pe_state_machine pe_cbl_discovery Initialize the policy engine and PD protocol modules Perform one iteration of the policy engine state machine. Check for EMCA controller and discover its capabilities 4.3 Hardware Abstraction Layer 4.3.1 Flashing Module API Description Parameters Return Value get_device_mode get_version The function returns the firmware mode of operation. The function returns whether the device is functioning in boot-loader mode or in application mode. The function returns the firmware version. The function returns the eight byte version information. uint32_t * buffer_p: Pointer to the buffer to return the version information uint8_t: 0 Boot-loader mode, 1 Fail-safe / IMAGE1 firmware mode, 2 main / IMAGE2 firmware mode. CCG2 Power Adapter Reference Design and API Guide, Doc. No. 002-10677 Rev.** 15

Firmware APIs API Description Parameters Return Value jump_to_boot device_reset flash_row_read flash_row_write The function disables all peripheral blocks and interrupts, indicate a boot mode request using SRAM signature and jumps back to the bootloader. The boot-loader entry shall be identified based on the FLASH reset vector address. The function disables all peripheral blocks and interrupts and issues a soft reset using CM0 registers. The function reads from the specified FLASH row ID and returns the full row data into the RAM buffer specified. The caller is expected to allocate the required buffering before invoking the call. The function writes the row data provided to the specified row ID. The FLASH writes are always expected to be full row writes. uint8 * buffer: The RAM buffer address to copy FLASH data uint16 row_id: The FLASH row to read from. uint8 *buffer: The RAM buffer address containing FLASH data uint16 row_id: The FLASH row to write to 4.3.2 Timer Module The timer module provides a WDT / SYS_TICK based soft timer implementation. This allows different modules to create millisecond level timers without additional hardware support. API Description Parameters Return Value timer_init Timer module initialization function. The function calibrates and configures the WDT timer. timer_start The function starts the selected timer with the requested interval. uint8_t timer_id: Unique ID allocated for the timer instance by the stack / application bool: true timer started successfully false timer failed to start uint16_t timeout: Timeout value in milliseconds timer_cb_t: Timer callback function pointer. Callback function is invoked by the timer module on timer expiry. NULL pointer to be passed in for no callback. timer_stop The function stops a previously started timer based on the timer ID specified. uint8_t timer_id: Unique ID allocated for the timer instance by the stack / application CCG2 Power Adapter Reference Design and API Guide, Doc. No. 002-10677 Rev.** 16

API Description Parameters Return Value Firmware APIs timer_is_running The function returns the running status of the timer based on the timer ID specified. uint8_t timer_id: Unique ID allocated for the timer instance by the stack / application bool: true Timer is running false Timer is not running 4.4 User (Solution) Layer API These APIs exist in user space and contain code provided for reference functionality. With change of HW and requirements, these routines are likely subject for modifications. 4.4.1 pd_psource.c (VBus Manager) get_psource_ops get_psrc_info set_psrc_voltage set_psrc_current set_psrc_pwr psrc_enable psrc_disable API Description Parameters Returns pointer to a structure with Power source related handlers. typedef struct power_supply_ops{ tpower_supply* *get_ps_info(void); uint8 *set_voltage (uint16 uint8 *set_current(uint16 volt_50mv); cur_10ma); uint8 *set_pwr(uint16 volt_250mw); uint8 *enable(void); uint8 *disable(void); uint8 *turn_on_vconn(uint8 uint8 *turn_off_vconn(uint8 uint8 *is_sup_vcon(void); uint8 *is_sup_vbus(void); #ifdef OVP_UVP_SUPPORTED_INC uint8 *ovp_uvp_handler(uint8 channel); channel); protect_type); #endif /* OVP_UVP_SUPPORTED_INC */ }tpower_supply_ops; Handler to get the list of power source capabilities supported by the CCG application. This is called by the Policy Engine during start-up and also as part of responding to the Get_Source_Cap USB-PD request. API provided by Power Manager to set voltage. This API shall be called by the USB-PD/Type-C module after contract. API provided by Power Manager to set current. This API shall be called by the USB-PD/Type-C module after contract. API provided by Power Manager to set power. This API shall be called by the USB-PD/Type-C module after contract. API provided by Power Manager to switch on the power circuit. This API shall be called by the USB-PD/Type-C module after contract. API provided by Power Manager to switch off the power circuit. This API shall be called by the USB-PD/Type-C module after contract. uint16 voltage in 50mV units uint16 current in 10mA units uint16 power in 250mWt units turn_on_vconn API provided by Power Manager to USB-PD/Type-C module to turn on VConn uint8 channel turn_off_vconn API provided by Power Manager to USB-PD/Type-C module to turn off VConn uint8 channel is_sup_vcon is_sup_vbus pdss_phy_ovp_uvp_en API provided by Power Manager to check if power supply is VConn API provided by Power Manager to check if power supply is VBus Enables OVP/UVP detection CCG2 Power Adapter Reference Design and API Guide, Doc. No. 002-10677 Rev.** 17

Firmware APIs API Description Parameters pdss_phy_ovp_uvp_dis Disables OVP/UVP detection ovp_uvp_handler Handles the case of detected OVP/UVP uint8 protect_type is_vbus_present system_init API provided by Power Manager to check if VBus is present Initializes power manager 4.4.2 pd_vdm.c (VDM Handler APIs) discover_id discover_svid discover_modes enter_mode exit_mode Attention unstr_vdm API Description Parameters This API is called when a Discover Identity command is received and a response has to be sent. This API is called when a Discover SVID command is received and a response has to be sent. This API is called when a Discover Mode command is received and a response has to be sent. This API is called when a enter mode command is received and a response has to be sent. This API is called when an exit mode command is received and a response has to be sent. This API is called when an attention command is received and a response has to be sent. This handler is called when an unstructured VDM is received by CCGx and needs to be handled. This method can be used to implement extensions where custom commands are implemented at the solution level. Pointer to VDO Pointer to VDO Pointer to VDO Pointer to VDO Pointer to VDO Pointer to VDO Pointer to VDO hard_reset This handler is called when a hard reset request is received by CCGx. Pointer to VDO 4.4.3 pd_swap.c (PD Role Manager) API Description Parameters get_pd_ops eval_dr_swap eval_pr_swap eval_vcon_swap get_dpm_resp Returns pointer of tpd_ops type to a structure with Power delivery handlers. typedef struct pd_ops{ void *eval_dr_swap(void); void *eval_pr_swap(void); void *eval_vcon_swap(void); tdpm_resp* *get_dpm_resp (void); }tpd_ops; This handler is called when a DR_SWAP control message is received by the CCG. The implementation is expected to accept, reject or delay the DR_SWAP operation as appropriate. This handler is called when a PR_SWAP control message is received by the CCG. The implementation is expected to accept, reject or delay the PR_SWAP operation as appropriate. This handler is called when a VCONN_SWAP control message is received by the CCG. The implementation is expected to accept, reject or delay the VCONN_SWAP operation as appropriate. This handler is called to get the response of the solution level PD role manager to a role change request that was previously evaluated. As the CCG2 controller have only one comparator available for these checks, a device level implementation will need to keep alternating between OVP and OCP checks that can cause significant time between polling. The common alternative would be to implement the OVP and OCP checks using external components and then notify CCG2. CCG2 Power Adapter Reference Design and API Guide, Doc. No. 002-10677 Rev.** 18

Revision History Document Revision History Document Title: CCG2 Power Adapter Reference Design and API Guide Document Number: 002-10677 Revision Issue Date Origin of Change Description of Change ** 04/05/2016 SVYP Initial release CCG2 Power Adapter Reference Design and API Guide, Doc. No. 002-10677 Rev.** 19