PDtrace is a USB type-C Power Delivery protocol analyzer.

purpose

it allows to monitor the Power Delivery (PD) communication over a USB type-C (USB-C) connection. it uses dedicated chips to decode the PD communication on the protocol level. because of that, this analyzer does not allow to debug on the electrical level. it can also be used to send PD messages, and act as sink or source.

usage

the devices comes as two parts:

• the USB-C CC breakout board: this needs to be inserted between the cable and device to be monitored. the 4 relevant signals (GND, VBUS, CC1, and CC2) are broken out on a header pins (100 mil pitch).
• the PDtrace: it does the actual protocol analysis. you just need to connect it to the USB-C CC breakout board using the header pins. connector the PDtrace to the computer using its USB-C port.

design choice

PD decoder

the FUSB302 is used to decode the PD communication. other projects already decode the raw traffic on the electrical level using software. I want to used dedicated hardware certified for this task instead. this should prevent any decoding issue, and removes any software limitation (e.g. bandwidth, ...) it also allows to send any PD messages the right way.

MCU

the ESP32-S2 is used and the main micro-controller to communicate with the FUSB302 and computer. this is one of the few devices still available during this silicon shortage. it also provides a native USB interface, and support USB DFU. it WiFi capabilities are not used at all.

USB-C CC breakout board

it is kept small to not be in the way of possible other nearby USB ports. it uses impedance controlled 4-layer board to still forward all the other high speed signals passing through the USB-C connection.

the main board is simple enough to be on a regular 2-layer board.

CC detection

the PD communication is half duplex, on the single Configuration Channels (CC) line. on the USB-C port there are two possible CCs: CC1 (on A5) and CC2 (on B5). only one is used though for the CC line. the other is just to allows the connector to be reversibly (flip-ability), and actually figure out the position. the cable only has CC line connection A5 on both ends. the CC connection on B5 is used for Vconn.

source

to figure out if CC is connected to CC1 or CC2 on the source side:

• pull up CC1 and CC2 using Rp (or providing a current source)
• when the sink is connected on the other side of the cable, CC will be pulled low using Rd
• the source can detect which CC1/CC2 is connected to CC my monitor the voltage on CC1 and CC2: if it lowers (by Rd), it's CC
• the other CC1/CC2 connection will either remain high (because left floating by the cable), or pulled low (using Ra from powered cable), this will because Vconn (to power the cable)

sink

to figure out if CC is connected to CC1 or CC2 on the sink side:

• pull down CC1 and CC2 using Rd
• when the source is connected on the other side of the cable, CC will be pulled high using Rp
• the sink can detect which CC1/CC2 is connected to CC my monitor the voltage on CC1 and CC2: if it goes high (by Rp), it's CC
• the other CC1/CC2 connection will either remain low (because left floating by the cable, or pulled low using Ra from powered cable)

trace

when tracing, it's not allowed to interfere with the CC1/CC2 lines. we can't pull high or low the lines. this would mess with the CC detection when the second side is connected. we also don't know if the source or sink is connected first. we also don't know which side will be connected using a cable.

we can monitor Vbus. this should only be high when the source detects the device. we could then check the voltage on both CC lines:

• if the voltage corresponds to Rp/Rd, this is the CC line
• if the voltage is high to Rp, it is directly connected to the source
• if the voltage is low to Rd, it is directly connected to the sink
• we could wait for PD communication on any line (multiple 0-1.2V edges) to confirm

but this only works if Vbus is provided.

the easier solution would be to use two FUSB302. each one continuously decodes the traffic on CC1/CC2 independently. there is no need for CC detection. the FUSB302 is cheap. because it has a fixed I²C address, they can not be on the same I²C bus.

unknown

the FUSB302 can connect the DAC to both CC1 and CC2 at the same time. what happens when this is done? are CC1 and CC2 shorted?

the FUSB302 can connect the BMC to both CC1 and CC2 at the same time. what happens when this is done? are CC1 and CC2 shorted?

alternatives

the Google Twinkle allows to analyze the CC communication on the electrical level. it uses comparators to get the bits, and provides the raw traffic to sigrok for software decoding on the computer (using the Twinkle as a logic analyzer). it is also able to send a limited numbers of messages (this is just an implementation limitation). sadly there is not commercial availability.

the CY4500 EZ-PD Protocol Analyzer is a professional solution. it also allows to analyze the communication on the electrical level. it provides rather complete software for decoding all messages, which is even available for linux. but it can't send messages, and is not open source. there is the open source software alternative USBCx though. these are the hardware design files for insert project name here.

requirements

to be able to generate the outputs you need following software:

• rake: the central script taking care of generating the output files (Makefile is too cumbersome to parse files)
• QEDA: to generate footprints for the parts
• Lepton EDA: for the schematic capture
• pcb-rnd: for the board layout the output generation is automatized.

library

almost all of the symbols and footprints used in the schematic and board layout are defined in the QEDA format and generated for the CAD software. the library folder contains the QEDA parts definitions.

to install QEDA using NPM from the official repository:

sudo npm install -g qeda

to install QEDA from the sources:

git clone https://github.com/qeda/qeda
cd qeda
npm install
sudo npm install --global

to generate the parts:

rake library

this will use the parts definition (.yaml files) in the library to generate gEDA gschem/Lepton EDA symbols (.sym files) in the geda/symbols folder, and coralEDA pcb-rnd footprints (.lht files) in the coraleda/subc folder.

only the QEDA parts in subfolders within library come from the QEDA library, but the files are included in this project for simplicity and archiving purposes. all other parts are custom and written for this project.

schematic

the .sch file is the schematic source file. it has been drawn using Lepton EDA.

it uses standard symbols, and the ones in the geda/symbols/ folder. most symbols are generated by QEDA as described above.

to export as pdf:

rake print

BOM

to export the bill of material (as CSV):

rake bom

board

the .lht file is the board layout source file. it has been drawn using coralEDA pcb-rnd.

it uses the symbols from the coraleda/subc/ folder. most symbols are generated by QEDA as described above. oshw_logo.lht is just the Open Source Hardware Logo. it been generated from https://oshwlogo.cuvoodoo.info/.

to export gerber files for PCB manufacturer (and photo preview + overview document):

rake fabrication