Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Active Probe Control/Power Prototypes #3

davidlenfesty opened this issue Dec 28, 2020 · 2 comments

Active Probe Control/Power Prototypes #3

davidlenfesty opened this issue Dec 28, 2020 · 2 comments


Copy link

davidlenfesty commented Dec 28, 2020

As discussed on IRC (I may have misinterpreted things or got something wrong):

There needs to be a standard power/control interface for active probes (that lives separately from what carries the actual signal). USB-C is a prime candidate, it's an easy cable/connector to get a hold of, has a fairly permissive spec, and is just ergonomic to use.

To do this we need to first design proof of concept prototypes of both the probe and host side, so that we can embed them into the probe/host (BLONDEL first for the host as far as I know). I am planning on implementing the host side, and

Interface requirements

  • Provides +7VDC over SSTX and -7VDC over SSRX.
  • Some interface to configure probe.
  • Doesn't break USB-C devices (more on that later)

Interface Design

  • Standard USB-C connector
  • Provides +5V Vusb power and ground to power the probe control side.
  • +-7VDC over SSTX/SSRX
  • Probe side will identify and configure over SB1/SB2 pins, via UART. probe side has fixed TX/RX pins, host side will need to auto-detect orientation and flip/not-flip TX/RX pins automatically. (easily achieved with an FPGA)
    • We are now using USB PD, with vendor-specific messages, as we need that to detect and ignore active cables anyways (and stm32g0 isn't that expensive)
  • Probe presents in Debug Accessory Mode, host will not configure for anything that is not a debug accessory.
    • This is not possible without captive cables, which defeats the whole purpose.

USB-C compatibility

We are slightly out of spec in that SSTX/SSRX aren't allowed to proved +-7VDC, but that is mitigated by gating that power behind a successful handshake. Other than that it follows the standard for a debug accessory.

I am currently unsure how to account for Source-Source connections on the host side (i.e. plugging a laptop into the host), but that should shake out in doing the full design and is fully captured by the amount of the spec we follow. Also on the host side we'll probably just use a dedicated USB C controller IC, which should handle that automagically.

EDIT: We also need to take care that we account for active cables. Apparently some of them have signal reprocessors, which means we could accidentally burn out a cable.

Prototype requirements

Host side:

  • Provides split power rail from barrel plug, but only after the probe enumerates itself to the host.
  • Provides Vusb
  • Rejects "real" USB-C devices.
  • SPI interface for communicating with main host.
  • Gates off Vbus and probe power.
  • Takes +12V from a barrel jack.

Probe side:

  • Enumerates to the host side
  • Accepts +-7VDC power
  • Has a few extra GPIO for controlling external things
Copy link

azonenberg commented Dec 29, 2020

For host-to-host handling, can we use a MOSFET based ideal diode on Vbus to prevent backfeeding from an external host?

Copy link
Contributor Author

Update on general progress (discussed in IRC but I feel should be updated here as well):

I have ordered the PCBs for the probe and host, TODO is ordering the parts and actually assembling them. My time is fairly limited so this will be a decent while still.

Host side firmware seems to be mostly done - pending some USB PD handshaking implementation, which seems simple but probably isn't, and the grunt work of creating a SPI register interface. I don't have hardware on hand to debug, so all I really know is that it compiles. Debugging will probably start when I have hardware brought up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

No branches or pull requests

2 participants