209 lines
7.8 KiB
Markdown
209 lines
7.8 KiB
Markdown
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](chromium.org/chromium-os/twinkie) allows to analyze the CC communication on the electrical level.
|
|
it uses comparators to get the bits, and provides the raw traffic to [sigrok](https://www.sigrok.org/) 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](https://www.infineon.com/cms/en/product/evaluation-boards/cy4500/) 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](https://github.com/tejv/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](http://qeda.org/): to generate footprints for the parts
|
|
- [Lepton EDA](https://github.com/lepton-eda/lepton-eda): for the schematic capture
|
|
- [pcb-rnd](http://repo.hu/projects/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](http://qeda.org/) 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](http://wiki.geda-project.org/geda:gaf)/[Lepton EDA](https://github.com/lepton-eda/lepton-eda) symbols (.sym files) in the `geda/symbols` folder, and [coralEDA pcb-rnd](http://repo.hu/projects/pcb-rnd/) footprints (.lht files) in the `coraleda/subc` folder.
|
|
|
|
only the QEDA parts in subfolders within `library` come from the [QEDA library](https://doc.qeda.org/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](https://github.com/lepton-eda/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](http://repo.hu/projects/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
|
|
~~~
|