This blog post documents the method to read out the firmware version from a CCG3PA chip.
The firmware version information can be retrieved in the for...
This blog post documents the method to read out the firmware version from a CCG3PA chip.
The firmware version information can be retrieved in the form of VDMs. This handling is taken care in the uvdm.c file in the Power SDK:
Since CCG3PA supports only single firmware image, the bootloader version and the firmware version of image 1 are read from the metadata by the system functions. The firmware and the bootloader version are given out in hex format.
The above implementation is with respect to the op-code present in the VDM sent by a Cypress board. In case if custom standard testers are employed in production environment for reading out the firmware version that is programmed into the PD controller, the customers can form their custom VDM command in the tester and can customize the SDK accordingly to form the custom UVDM response.
Below is a sample code snippet in which CCG3PA gives out the firmware version information if it is connected to a BCR device. CCG3PA first sends Discover Identity VDM command after the completion of PD negotiation between source and sink. If the VID and PID of sink matches with the VID and PID of EZ PD BCR device (i.e. VID= 0X4B4 and PID=0x3177), CCG3PA will respond by sending a UVDM command which contains the firmware version.
As per USB-PD spec,
The unstructured vendor defined message is sent with the vendor ID set to appropriate value (0x4B4), VDM type set to 0 (unstructured vdm) and rest fields were set to 0 (which can be customized as per requirement).
The UVDM is sent after detection of EZ PD BCR through a timer callback. The function cc_device_version() is used to send the UVDM.
App event APP_EVT_PD_CONTRACT_NEGOTIATION_COMPLETE is triggered in app_event_handler() function once the PD negotiation is complete. Discover Identity message is sent after negotiation complete event through a timer callback.
The above image presents the code being used to extract the firmware version information from the metadata using the system functions once EZ PD BCR device is detected.
Following is the detail of the UVDM from CC logs captured using CY4500 EZ PD Protocol Analyzer.
DATA OBJECT 4 and DATA OBJECT 5 contain the firmware version.
USB Power Delivery (USB PD) along with Type-C specification aims at providing Universal Charger functionality where multiple different devices requiri...
USB Power Delivery (USB PD) along with Type-C specification aims at providing Universal Charger functionality where multiple different devices requiring different voltages and currents can be charged using a single USB PD charger. Even though universality is a key feature of USB PD Chargers, some charger designs requires recognition of a particular sink connected to it.
Any USB PD capable device is recognized through the combination of its VID and PID. VID refers to Vendor ID, which is allotted by USB-IF. PID refers to Product ID which is fixed by vendor for a particular product. This VID and PID information can be obtained from the sink by sending “Discover Identity VDM” message. Sink in response to this VDM message sends Acknowledgement which includes VID and PID of the sink device.
Following is the code snippet to send Discover Identity VDM message after the completion of PD negotiation between source and sink. The PD port is disabled if VID and PID of sink doesn’t match the expected values (expected sink device).
CYPD3171-24LQXQ_CLA project from CCGx Power SDK is used to test the code functionality.
bool send_discover_id(uint8_t port)
/* Format the command parameters.
Single DO with standard Discover_ID command to SOP controller.
Timeout is set to 100 ms.
cmd_buf.cmd_sop = SOP;
cmd_buf.cmd_do.val = 0xFF008001;
cmd_buf.no_of_cmd_do = 1;
cmd_buf.timeout = 100u;
/* Initiate the command. Keep trying until accepted. */
while ((stat = dpm_pd_command(port, DPM_CMD_SEND_VDM,
&cmd_buf, pd_command_cb)) != CCG_STAT_SUCCESS)
/* Can implement a timeout/abort here. */
/* Command has been queued. We cannot block for callback here. */
App event APP_EVT_PD_CONTRACT_NEGOTIATION_COMPLETE is triggered in app_event_handler function once the PD negotiation is complete. Discover Identity message is sent after negotiation complete event through a timer callback.
Attached to this post is the project which recognizes Ez-PD BCR as valid sink and turns the provider FET off when sinks other than BCR are connected. All changes to project are made in app.c file.
BJT Base drive MOSFET gate driveCurrent driven deviceVoltage driven de...
BJT Base drive
MOSFET gate drive
Current driven device
Voltage driven device
Current must be applied between the base and emitter terminals to produce a flow of current in the collector
MOSFET produces a flow of current in the drain when a voltage is applied between the gate and source terminals
The gate of a MOSFET can be considered to be a capacitance.
The gate voltage of a MOSFET does not increase unless its gate input capacitance is charged, and the MOSFET does not turn on until its gate voltage reaches the gate threshold voltage Vth.
The gate threshold voltage Vth of a MOSFET is defined as the minimum gate bias required for creating a conduction channel between its source and drain regions.
Input capacitance Ciss = Cgd + Cgs (gate to drain capacitance + gate to source capacitance)
Output capacitance Coss = Cds + Cgd (drain to source capacitance + gate to drain capacitance)
Reverse transfer capacitance Crss = Cgd (gate to drain capacitance)
Calculating Gate drive resistance and Power consumed by the gate drive circuit:
Gate drive resistance:
Find out the total charge Qtotal (Gate to source and Gate to drain) and Gate driver voltage (Vg) from the datasheet of the MOSFET.
Total current through the gate path (coulomb/second) = Qtotal*Switching frequency
Gate driver resistance = Vg / (total current).
But to reduce gate loss we consider R = T/C, where T = Rise time (from datasheet).
P = Ciss*(Vg)^2*fsw,
Where, Ciss = input capacitance.
Vg = gate drive supply voltage.
fsw = switching frequency.
Different gate driving circuits:
1. Basic circuit:
Gate resistor R1: An appropriate resistor value should be selected because it affects the switching speed and therefore the switching loss of a MOSFET.
PWM: It should be able to meet the following, A gate voltage sufficiently higher than Vth to turn on the MOSFET, voltage sufficiently lower than Vth to turn it off and a drive capability to sufficiently charge the input capacitance.
Gate resistor R2: This resistor R2 is used to reduce the gate-source voltage to 0V when the input signal is open-circuited.
2. Push Pull circuit:
When the parasitic of MOSFET is relatively large and the PWM driving ability is no enough to drive MOSFET normally the below gate driving circuit is used.
It consists of Q2, Q3, VCC is used commonly to improve the driving ability.
This circuit acts as a replacement to the digital logic circuit where the gate voltage is boosted.
Boosting the logic gate voltage increases the power consumption of the circuit. Hence, we can use this circuit as a replacement.
3. Accelerating Turn off time (Toff) of the MOSFET:
During Ton, the gate current flows through R9 which is a high resistance path.
Resistor R8 and diode D1 offer as low impedance path as possible to discharge the Cgs (gate to source capacitance) quickly when the MOSFET is transition to off state. This can reduce the turn off power loss of the MOSFET.
Reducing R9 causes voltage spike and ringing effect. Hence a separate discharge path is designed with low impedance.
There is one more circuit which is used to accelerate the discharge time of the MOSFET. It is as shown below,
When the PWM signal has enough driving ability, Q7 is also used to discharge the Cgs (gate to source capacitance) quickly.
D2 is used to prevent the discharge current flow back to PWM IC and damaging the IC.
5. Pulse Transformer drive:
By using a pulse transformer, the need for a separate drive power supply can be eliminated.
It has a drawback in terms of the power consumption of a drive circuit.
A pulse transformer is sometimes used to isolate a MOSFET from its driver in order to protect the drive circuit from the MOSFET’s fault.
A Zener diode is added to quickly reset the transformer.
The attached document consists of an offline guide to Cypress EZ-PD Type C USB Products. This document can also be used as an offline guide for c...
The attached document consists of an offline guide to Cypress EZ-PD Type C USB Products. This document can also be used as an offline guide for customers by onsite sales and field application engineers.
The CCGx Host SDK and Power SDK contains a noboot project along with the main firmware project for each firmware example to allow debugging. This is d...
The CCGx Host SDK and Power SDK contains a noboot project along with the main firmware project for each firmware example to allow debugging. This is done using the Debug option on PSoC Creator through a SWD debugger such as MiniProg3 or MiniProg4. However, we cant use debug mode for the main firmware project directly since it contains the bootloader that doesnt allow the debugging the application.
To debug the main firmware project with the bootloader, follow the steps below. The CCG3 (CYPD3125-40LQXIT) notebook project from the Host SDK is used as an example here.
1. Go to the Design Wide Resources file and assign the Debug Select to SWD. Make sure that the SWD pins for the device are not assigned to anything else and are free for debug.
2. Build and program the .hex file onto the device. You can use the Program option on PSoC Creator for programming it as well.
If the device is not acquired, configure the port settings as shown below.
3. With the same setup connected, use the Attach to Running Target option to acquire the device.
4. Since the firmware is already running on the device, the debugger will access it from the point it was attached. The Reset option can be used to issue a Soft Reset to the device and bring the firmware execution to main() again.
Version: *RWest Bridge®: Astoria™ USB and Mass Storage Peripheral ControllerFeaturesMultimedia device supportSupports Microsoft® Media Transfer Protoc...
West Bridge®: Astoria™ USB and Mass Storage Peripheral Controller
Multimedia device support
Supports Microsoft® Media Transfer Protocol (MTP) with optimized data throughput
Simultaneous Link to Independent Multimedia (SLIM®) architecture, enabling simultaneous and independent data paths between the processor and USB, and between the USB and mass storage
High-speed USB at 480 Mbps
USB 2.0 compliant
Integrated USB switch
Integrated USB 2.0 transceiver, smart serial interface engine
16 programmable endpoints
GPIF (General Programmable Interface)
For more, see pdf
Turbo-MTP is an implementation of Microsoft’s MTP enabled by West Bridge. In the current generation of MTP-enabled mobile phones, all protocol packets needs to be handled by the main processor. West Bridge Turbo-MTP switches these packet types and sends only control packets to the processor, while data payloads are written directly to mass storage, thereby bringing the high performance of West Bridge to MTP.
CYPD3177(BCR) has provided four sets of resistor divider networks are used to determine the voltage and current range that the EZ-PD BCR device will n...
CYPD3177(BCR) has providedfour sets of resistor divider networks are used to determine the voltage and current range that the EZ-PD BCR device will negotiate
with the USB Type-C power adapter. However, if it still cannot meet your requirement, you can change the PDO through its I2C register.
This blog gives a breif introduction on how to change the BCR register based on BCR HPI Spec.
1. Hardware Connection
Connect SCLK and SDAT of MiniProg to CY4533 as is shown in Figure 1. Set the rotary switch (SW1) to position 1 so CY4533 support 5V/0.9A by default. Use a CY4500 EZ-PD Protocol Analyzer to capture the cc communication between CY4533 and the power adapter.
As is shown in Figure 2, CY4533 request 5V/0.9A due to the max requesting VBUS set by rotary switch is 5V/0.9A.
2. Send I2C command in Bridge Control Panel to control BCR
Check the PD_STATUS register first. The value of PD_STATUS register is 00 A4 05 00. It means the explicit contract has been established between BCR and the charger. BCR is acting as a power sink and the two device both supports PD 3.0. To replace the default sink PDO, write the corresponding packet into the data memory start from 0x1800. For Byte 0-3, ASCII string “SNKP” (i.e 0x50 0x4B 0x4E 0x53) must be sent to make BCR update its sink PDO list. In this example, PDO 0 is set to 5V/0.9A and PDO 1 is set to 15V/1.75A. The remaining bytes are set to 0 because not all 7 PDOs are used. Refer to Section 6.4 of Universal Serial Bus Power Delivery Specification for the description of Fixed Supply PDO. Figure 3 is the I2C commands sent and response from BCR.
After enabling the PDO0 and PDO1 mask by sending command to SELECT_SINK_PDO register, BCR will re-negotiate the PD contract with the power adapter. PD_RESPONSE register should be checked after sending command on command registers. 0x02 is the code for successful operation.CC communication is captured by CY4500 in Figure 4.