TCPP01-M12 appears to not be connecting CCx to CCxc

[RHinm.1]

I am prototyping a new board upgrade to USB-C by connecting an X-Nucleo-SNK1M1 board containing the TCPP01-M12 to our existing USB device board that uses a STM32L476. The device is battery powered and will only need default 5V power. All that works fine with the VCC and DB/ pins grounded for dead battery operation and the USB2.0 data lines passed through the dev board to our board.

In some cases in our application, it would be nice for the device/UFP to force a power cycle and disconnect from the host without a person physically pulling the plug. It is my understanding that if the USB-C CC wires are open circuited, the DFP's pull ups should pull them up to > 1.65V and the DFP interpret that as a disconnect. My interpretation of the TCPP01-M12 data sheet (Section 6.4) is that when both VCC and DB/ are raised, the DB clamps are removed from the CCxc pins and CCxc are connected to CCx internally. If CCx are open circuit (no micro, no 5.1k resistor), one of the CC lines should be pulled up by the DFP's pull up and the DFP should disconnect.

That is not happening in our circuit, and I'm hoping someone can help me understand why or set me straight if my interpretation of expected behavior is wrong. Attached is a scope plot of the operation. Channel 1 is VCC and DB/, connected together and initially pulled low. Channel 2 can be disregarded for now (more details below), it is the microcontroller's PC09 pin that gets pulled up on USB connect. Channel 3 is VDDUSB at the microcontroller; you can see it rises to ~3.3V when USB is plugged in. Channel 4 is CC1c, it also gets pulled up to the dead battery clamp voltage, and then the PC tries to negotiate USBPD (but nothing is listening).

At the center of the plot, we raise VCC and DB/, and note that nothing changes on CC1c. I would expect that since the CC1 pin of the TCPP01-M12 is open circuit, CC1c should be pulled up. We also tried grounding CC1, expecting to see that CC1c gets pulled to ground, but the scope plot looks identical. What am I missing?

More detail: the X-Nucleo board is configured in the following way:

1. Voltage protection: Unsolder SH5 and solder SH1 to set 6V overvoltage protection.
2. Unsolder C1 and C2 because these are only needed for USB Power Delivery compliance, and we aren’t doing PD (and we want the configuration to be as close as possible to our final design).
3. Jumpers on J1 and J2 removed so that CC1 and CC2 are open circuit, as discussed above.
4. Jumpers on J3 and J4 also removed to isolate the voltage regulator (we have our own from VBUS)
5. Unsolder R3 to allow the microcontroller's GPIO to pull up the FLT signal (1.8V micro).
6. Connect Vbus (CN2 pin 2) to our board's USB Vbus.
7. Connect USB data lines (CN10 pins 10 and 12) to our boards USB data.
8. Connect GND between the boards, using CN2 pin 1.
9. Connect VCC_OUT (CN7 pin 1) and DB_OUT (CN10 pin 27) together and either to GND, 3.3V, or a pull-up FET controlled by the microcontroller depending on the test. The FET is needed because the microcontroller's main supply is 1.8V, but we would need to pull up to ~3.3V.
10. Connect the FLT/ signal (CN10 pin 18) to a GPIO on the microcontroller. Included for completeness, though we have not been using this signal so far.

The end result is intended to prototype the attached circuit diagram, which would be the new board assuming this all works. Note that Q? is the FET mentioned in point (9) and the signal USB.DISCONN is the microcontroller's 5V-tolerant PC09.

I'm obviously missing something, but can't figure out what it is. Any help or insights would be appreciated.

Kind regards,

Rod

[PPAIL.1]

Dear Rod,

The TCPP01 dead battery mode consists of opening the line CC1c to CC1 and placing a resistor Rd on the side CC1c, and the same for the line CC2c to CC2.

Indeed, when the MCU is off due to the dead battery, there is no more UCPD IP. So the CC1 and CC2 lines are disconnected, and placing Rd on CC1c and CC2c lines allows the sink to signal its connection to the charger.

The behavior you observe is therefore normal.

If I understand correctly, sometimes you want to cut Vbus. For this you can impose a higher voltage than normal on the VBUS_CTRL pin of the TCPP01: for example 3.3V using a GPIO of the MCU, this has the effect of opening the MOS on the VBUS path. (In normal use, leave this GPIO in open-drain mode).

Best regards

Pascal

[RHinm.1]

Dear Pascal,

Thank you for the response. I understand that the TCPP01-M12 pulls the CC1c and CC2c pins toward ground with clamps or internal resistors when in dead battery mode. I had believed from the data sheet that when VCC and DB\ are 3.3V, it connects CC1c to CC1 internally, and that if CC1 has nothing connected externally, then CC1c + CC1 would both float to the level of the pull-up voltage on the host side. We do not see that happening, which is why I asked the question.

Thanks also for the idea of imposing a voltage on VBUS_CTRL to cut Vbus; that might help us. Our goal is not necessarily to disconnect Vbus, but to signal to the host that the device has been unplugged. Our device acts as a Mass Storage Controller, and as long as the host has it enumerated, we cannot write additional data to the filesystem. There are other ways of doing this: turning off the USB peripheral, rebooting, etc. We were just looking for a way that used the USB-C machinery.

Kind regards,

Rod

[PPAIL.1]

Dear Rod,

Sorry to have misunderstood your point.

So, I am trying to reproduce your problem: using a X-Nucleo-SNK1M1 plugged into a NUCLEO-G071RB.

-      I removed JP1 and JP2 on the SNK1M1,

-      VCC and DB/ are connected together

-      Rp 12kOhms to 3.3V on each CC1c and CC2c lines at the connector.

In Yellow and Green: CC1c and CC2c, in red VCC & DB\

 

I can observe the expected behavior: when VCC & DB\ is high, CC1x and CC2c are pulled up to 3V.

-      When VCC & DB\ is driven by a GPIO in push-pull mode

-      Or when VCC & DB\ are driven by an external power supply (min 2.4V typical in my bench)

I did the same removing Rp and connecting the board to a SRC1M1 X-NUCLEO

I can observe the expected behavior: when VCC & DB\ is high, CC1x is pulled up to 3V.

I also tried with a charger and a computer:

We can observe the effect of the TCPP01.

Could you check the behavior you have with only Rp on the USB-C connector?

Also, can you check the voltage you have on pins VCC & DB\?

Best regards

Pascal

[RHinm.1]

Dear Pascal,

Thank you for the update. I will certainly test the board again in several ways as you have. It may take a few days; the engineer who did the tests is traveling, and I'll have to see if I can get someone else to do them or send the board to me (I work remotely).

Kind regards,

Rod