ZY12PDN Reverse Engineering Part 1

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.

ZY12PDN PD trigger image

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

  1. How is it wired up?
  2. 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.

FUSB302 signal arrangement

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:

Part 2: Looking at the Firmware (coming soon)

7 Comments

  1. Timothy
    July 6, 2020

    I’ve got a project I’m working on with these and your stuff is very helpful. Look forward to the next one. I’m using one to power a 12v dc heater and trying to make a nice solution that’s always 12V and has a dial control. Nothing revolutionary but thought these boards would be nice for having other functions.

    Thanks again

  2. Nanda
    July 12, 2020

    Have you verified that it works in reverse as a source (up to 100W?)

  3. July 12, 2020

    @nanda: out of the box, it definitely does not. With slight hardware modification and a new firmware, I think it COULD, but I haven’t tried yet.

  4. Ben
    September 11, 2020

    Any idea if the firmware includes a “power down capability” – essentially, i’d very much like to utilise the passthrough charging capability of my power bank. This won’t work with the usb C connected to anything. I can run my robots computer system from the 5V USBA on the power bank without too much modification, but the pass through functionality wont work with a device plugged in to USB C. I’m thinking if this can be reset, it will work. I’m not sure what the 4 pads on the bottom of the PCB are for – perhaps a UART?

  5. Ben
    September 11, 2020

    Nevermind, i missed that on the schematic you provided. SWD…

  6. September 11, 2020

    Interesting – this is a complete guess, but: I’d imagine the bank doesn’t support passthrough with something plugged into USB-C on the basis that it can intelligently handle 5v in/5v out/excess power to battery charging, where that balance gets much more difficult or impossible with >5V/>10W out. The topology to support supplementing shore power with battery power for loads >> shore power looks a lot different from the topology that supports shore power>output, excess>battery.
    I wonder, does passthrough work with a “legacy sink” device plugged into USB-C? Like a USB-C>A dongle, then a>phone plugged into that?

    Anyway it seems to me like it’s probably not supported for architectural reasons to support passthrough for high voltage/power USB-C loads.

  7. September 14, 2020

    Hey Alex,

    Some people on my discord have been looking at reverse engineering this module too, I think it would make a great board with custom firmware!

    We still think it’s the fusb302 though.

    Regarding Vbus: according to the data sheet, it’s an input for detecting if usb is connected or disconnected. Seeing as it’s being powered by this source, if doesn’t really matter too much if it can detect it or not. So while it is strange to ground a pin labeled Vbus, we think it could be ok.

    Regarding i2c pins, one of the guys found evidence in the code that they are using a software i2c solution for some reason. He did some logic captures that confirms gpio10 is being used as the clock.

    If you want to compare notes or discuss anymore about it , you are more than welcome to join in! blough.ie/discord

    Brian

Leave a Reply

Your email address will not be published. Required fields are marked *