In my last post about USB-C PD triggers, I mentioned a couple that look promising for DIY projects and experimentation, and in particular the ZY12PDN which had a full Type-C controller and no power MOSFET to stop me using it in reverse as a source. Here’s a bit of a deeper dive into that device.
A couple of key (physical) features:
- It has a main microcontroller
- It has a button
- It has a 3-color LED
- It has a discrete Type-C controller (laser marked PBAA KFH on mine)
- It doesn’t have a VBUS disconnect MOSFET, so we should be safe running this in reverse.
- The SWDIO/SWCLK pins are broken out nicely for programming access
So at this point, the next questions are
- How is it wired up?
- What is that Type-C controller, exactly?
I took a stab at drawing the schematic in hopes of determining exactly what part number the Type-C controller is, and here’s what I came up with:
Here’s a PDF version for easier viewing.
Some things are pretty straightforward. A linear regulator generates 3.3V from VBUS to power the microcontroller, the Type-C controller, and the LED. Some things are a little less clear: why put a schottky on the linear regulator input? Maybe to avoid reverse-biasing the regulator in the programming jig, when a dummy load and programmer are both attached or something? It seems like an odd choice to me. Similarly, I have no idea what’s going on with the two series 100-ohm resistors on the CC lines, or the reverse-biased diodes to ground. The FUSB302 reference schematic does call for capacitors on those nets, and the diodes would provide some capacitance – but it doesn’t make a lot of sense to do that, I think.
As far as the mystery Type-C controller itself: the footprint sure LOOKS like the FUSB302 pinout.
The first oddity is that VBUS isn’t actually attached on any pin – which actually makes it just as likely that pin 2 is supposed to be VBUS and is just grounded for some reason. The other oddity I can’t quite figure out is that SCL and SDA appear to be reversed. Pin PA9 on the microcontroller is definitely the I2C clock, but pin 7 of the FUSB302 is I2c DATA, not clock as it’s wired on this board. The routing as-is is much more convenient than as I claim it should be – you’d have to cross over the two traces and there isn’t much board area to do it. But I’m not aware of any functionality of either part to swap the two in software or something,
This discrepancy almost certainly means the controller ISN’T a FUSB302. Perhaps it’s a close third-party clone that’s almost-but-not-quite footprint compatible? There are some other possible contenders in the cheap Type-C market to look at:
- STUSB1602: package and footprint aren’t even close.
- STUSB1600: also not close
- STUSB4500: also not close
- Cypress? They have a bunch of similar products, but typically higher integration and functionality
- TI? Nothing I can find as jellybean as a barebones PD controller like this.
- FUSB301? So close, but nope!
- FUSB302B? There’s A B version?! Still has the same pinout though.
So in the end, I’m STILL not sure what PD controller is actually on this board. But after all that hunting and reading, I’m more confident that if it’s not actually a FUSB302, it’s a mostly-compatible clone attempt. So I guess either way, on to the next part: