README: document PDtrace project
This commit is contained in:
parent
67623b91ed
commit
7b1a22061f
128
README.md
128
README.md
|
@ -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
|
||||
-------
|
||||
|
||||
|
|
Loading…
Reference in New Issue