0
\$\begingroup\$

I'm trying to design a USB-PD equipped board, and currently evaluating this Maxim eval board. I'm plugging in an USB-PD Charger and unable to see any PD activity when measuring with this sparkfun logic analyzer. I've attached a screenshot of what I'm seeing in PulseView.

enter image description here

The first 3.5 seconds or so is with nothing plugged into the eval board, and CC1 and CC2 attached to the logic analyzer. At around 3.5 seconds I plug in the USB-PD charger. Obviously something is happening, but the usb-pd protocol decoder doesn't show anything. My first guess was the clock signal used for the PD communications is greater than 24MHz (the limit of the Sparkfun logic analyzer). I didn't see anything in the USB-PD standard about a specific clock frequency, but can anyone confirm this is above 24MHz or reasons why I wouldn't be seeing anything here?

I see this working with a different analyzer here but this uses a rather expensive piece of hardware. As I'm new to developing anything with USB and am only using this in a one-off job, I'm looking for help finding what specs are relevant that makes this analyzer work compared to my setup. Is this a hardware limitation or firmware/software limitation?

I'm attaching the version info for PulseView below, but rather than track a specific bug, I'm more wondering if what I'm doing should even be possible or if I'm overlooking a huge reason why this shouldn't work in the first place:

Versions, libraries and features:
PulseView
0.5.0-git-7e5c839
Qt
5.7.1
glibmm
2.42.0
Boost
1_60
exprtk
20200101
libsigrok
0.6.0-git-6dc55e4/4:0:0 (rt: 0.6.0-git-6dc55e4/4:0:0)
- glib
2.44.1 (rt: 2.44.1/4401:1)
- zlib
1.2.11
- libzip
1.5.2
- minilzo
2.10
- libserialport
0.1.1/1:0:1 (rt: 0.1.1/1:0:1)
- libusb-1.0
1.0.20.11003-rc3 API 0x01000104
- hidapi
0.8.0-rc1
- libftdi
1.4
- Host
x86_64-w64-mingw32.static.posix, little-endian
- SCPI backends
TCP, serial, USBTMC
libsigrokdecode
0.6.0-git-24ba9e1/4:0:0 (rt: 0.6.0-git-24ba9e1/4:0:0)
- glib
2.44.1 (rt: 2.44.1/4401:1)
- Python
3.4.4 / 0x30404f0 (API 1013, ABI 3)
- Host
x86_64-w64-mingw32.static.posix, little-endian

After receiving an answer, I verified with a scope that the logic levels for the USB-PD negotiations over the CC1 line (CC2 is apparently only a reference for CC1 or vice versa when the plug is swapped) are around 1.0V. It was a little tricky to trigger this as the CC1 and CC2 lines are normally oscillating between 0 and 5V so using a "less than pulse width" of 10 microseconds on the CC1 line with pulse level above 500 mV was what I ended up using. Although the pk-2-pk is likely around 1.2V I will try to use a level shifter/translator that can handle levels down to 1.0V just in case. I also noted the sampling frequency required was > 500 Hz without risking missing samples, so I will likely use a sampling rate of 1 MHz or higher to be sure I catch everything.

enter image description here enter image description here

\$\endgroup\$
3
  • 1
    \$\begingroup\$ I see you got one downvote, and one close vote for "opinion'based question". I think the problem in your question is the "I see a bunch of super expensive PD specific analyzers out there, but can someone tell me why these would be necessary compared to any ol' logic analyzer monitoring CC1 and CC2 channels and the Pulseview usb-pd decoder?" part. That is subjective, and it is tengential to your actual problem, which is "why doesn't it work", as I understand. Focus on this, or your question might get closed. \$\endgroup\$
    – dim
    Jul 8, 2022 at 8:49
  • \$\begingroup\$ Thanks for your comment. I've updated as best I could think of to be less subjective, but if you have any further suggestions to make it better, I'm happy to work them in. \$\endgroup\$
    – topher217
    Jul 10, 2022 at 4:19
  • 1
    \$\begingroup\$ USB Type-C and power delivery 101 – Power delivery protocol says that "All PD messages are transmitted at 300 kHz +/- 10% over the CC line." \$\endgroup\$ Jul 10, 2022 at 7:52

1 Answer 1

2
\$\begingroup\$

Connecting the logic analyzer directly to monitor USB PD communication should not work in the first place.

Your logic analyzer works with TTL logic voltage levels. It's not compatible with USB PD logic voltage levels which are much lower.

Analyzer needs 2.0V or more for logic 1 and 0.8V or less for logic 0.

USB PD communications happen at about 0V to 1.2V logic levels so the logic analyzer only sees it's low all the time.

At minimum, you need something to level translate the USB PD communication to 3.3V levels and then you can use the logic analyzer.

\$\endgroup\$
2
  • \$\begingroup\$ That would be exactly the information I was looking for. Do you happen to know the standard/reference for defining this 1.2V logic level? Is this in the PD standard or some more general USB standard? \$\endgroup\$
    – topher217
    Jul 10, 2022 at 4:07
  • \$\begingroup\$ I verified your claim with a scope (see edits above). Though this led to another issue that the Maxim board pulses a 4.4V (Vsys?) square wave with positive width around 37ms. If I unplug the FTDI usb interface, this disappears and I have a flat voltage of around 150mV on both CC1 and CC2. So if I were to use a voltage level translator, it would have to handle both these 4.4V input and the lower 1.0V inputs without blowing the logic analyzer max of 5V on the output. Is this normal behavior for the CC lines to pulse like this? \$\endgroup\$
    – topher217
    Jul 11, 2022 at 4:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.