README: document PDtrace project

This commit is contained in:
King Kévin 2021-12-18 20:41:35 +01:00
parent 67623b91ed
commit 7b1a22061f
1 changed files with 124 additions and 4 deletions

128
README.md
View File

@ -1,11 +1,134 @@
these are the hardware design files for **insert project name here**.
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
============
@ -17,9 +140,6 @@ to be able to generate the outputs you need following software:
- [pcb-rnd](http://repo.hu/projects/pcb-rnd/): for the board layout
the output generation is automatized.
compiling
=========
library
-------