Source Code: https://github.com/zhao1mh/webcamtest
This is a simple example webcam test program using SDL2. It only supports YUY2 format. The UVC device should have VID:0x04b4&PID:0x00f9. Frames per second are calculated with a timer.
It shows that USB transfer will not use too many system resources. Actually, the real reason for the low FPS is the efficiency of the Video Player.
Tested Platform: RaspberryPi 400 & Ubuntu
Author: Eddie Zhao
Version : 1.02
Date: 8/12/2021Cancel changes
sudo apt-get install libusb-1.0-0-dev libsdl2-dev
git clone http://github.com/zhao1mh/webcamtest.git
This is an example program based on libusb that automatically takes the first frame and streams data from the endpoint then calculates the FPS.
Please notice that only bulk transfer is supported in the current version. This application does not contain a decoder so RAW format is also supported.
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.
For information on CCGx firmware version structure, refer to Table-13 in the CCGx Power SDK User Guide: (https://www.cypress.com/documentation/software-and-drivers/ez-pd-ccgx-power-software-development-kit).
Attached to this post is the project which recognizes Ez-PD BCR as a sink and sends UVDM containing the firmware version information. All changes to project are made in app.c file.
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.Show Less
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
P = Ciss*(Vg)^2*fsw,
Where, Ciss = input capacitance.
Vg = gate drive supply voltage.
fsw = switching frequency.
1. Basic circuit:
2. Push Pull circuit:
3. Accelerating Turn off time (Toff) of the MOSFET:
5. Pulse Transformer drive:
CYPD3174-16SXQ is targeted at Opto Coupler Feedback applications with a Opto Coupler Feedback Bootloader. It has a reduced pin list compared to CYPD3171 and CYPD3175.
It could also be used in directed feedback application with a modified hardware and firmware.
The schematic is shown below:
The firmware is derived from the CYPD3175-24LQXQ_pa_direct_fb with minor modifications. The only things changed are the device part number of bootloader and the project.Show Less
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.
Abhilash PShow Less
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.
West Bridge®: Astoria™ USB and Mass Storage Peripheral Controller
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.Show Less
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 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.