STUSB4500 - PDO works at first try (9v) but will not enumerate above 5V after

[Richcj10]

Using a STUSB4500. I am attempting to request 9V @1A from a USBC wall wart. The wall wart is capable of delivering 9V @3A. 

If the device cold boots,(remove all power from the system) the request is a success and stays fixed at 9V. 

If I remove the USBC connector and plug it back in it will not go back to 9V, It sticks to 5V. It will not go back to 9V unless I remove power and cold boot again.

Here is the I2C traffic to the device:

 write to 0x2B ack data: 0x2F 
read to 0x2B ack data: 0x25
write to 0x2B ack data: 0x89 
read to 0x2B ack data: 0x4B 0x00 0x00 0x00
write to 0x2B ack data: 0x89 0x4B 0xD0 0x02 0x00 
write to 0x2B ack data: 0x89 
read to 0x2B ack data: 0x4B 0xD0 0x02 0x00
write to 0x2B ack data: 0x89 0x64 0xD0 0x02 0x00 
write to 0x2B ack data: 0x8D 
read to 0x2B ack data: 0x00 0x01 0x00 0x00
write to 0x2B ack data: 0x8D 0x00 0xD1 0x02 0x00 
write to 0x2B ack data: 0x8D 
read to 0x2B ack data: 0x00 0xD1 0x02 0x00
write to 0x2B ack data: 0x8D 0x64 0xD0 0x02 0x00 
write to 0x2B ack data: 0x70 0x03 
write to 0x2B ack data: 0x89 
read to 0x2B ack data: 0x64 0xD0 0x02 0x00
write to 0x2B ack data: 0x89 
read to 0x2B ack data: 0x64 0xD0 0x02 0x00
write to 0x2B ack data: 0x70 0x02 
write to 0x2B ack data: 0x89 
read to 0x2B ack data: 0x64 0xD0 0x02 0x00
write to 0x2B ack data: 0x89 0x64 0xD0 0x02 0x00 
write to 0x2B ack data: 0x89 
read to 0x2B ack data: 0x64 0xD0 0x02 0x00
write to 0x2B ack data: 0x89 0x64 0xD0 0x02 0x00 
write to 0x2B ack data: 0x51 0x0D 
write to 0x2B ack data: 0x1A 0x26 
write to 0x2B ack data: 0x89 
read to 0x2B ack data: 0x64 0xD0 0x02 0x00
write to 0x2B ack data: 0x89 
read to 0x2B ack data: 0x64 0xD0 0x02 0x00
write to 0x2B ack data: 0x70 0x02 
write to 0x2B ack data: 0x89 
read to 0x2B ack data: 0x64 0xD0 0x02 0x00
write to 0x2B ack data: 0x89 0x64 0xD0 0x02 0x00 
write to 0x2B ack data: 0x89 
read to 0x2B ack data: 0x64 0xD0 0x02 0x00
write to 0x2B ack data: 0x89 0x64 0xD0 0x02 0x00 
write to 0x2B ack data: 0x51 0x0D 
write to 0x2B ack data: 0x1A 0x26 
write to 0x2B ack data: 0x89 
read to 0x2B ack data: 0x64 0xD0 0x02 0x00
write to 0x2B ack data: 0x89 
read to 0x2B ack data: 0x64 0xD0 0x02 0x00
write to 0x2B ack data: 0x70 0x02 
write to 0x2B ack data: 0x89 
read to 0x2B ack data: 0x64 0xD0 0x02 0x00
write to 0x2B ack data: 0x89 0x64 0xD0 0x02 0x00 
write to 0x2B ack data: 0x89 
read to 0x2B ack data: 0x64 0xD0 0x02 0x00
write to 0x2B ack data: 0x89 0x64 0xD0 0x02 0x00 
write to 0x2B ack data: 0x51 0x0D 
write to 0x2B ack data: 0x1A 0x26 
write to 0x2B ack data: 0x89 
read to 0x2B ack data: 0x64 0xD0 0x02 0x00
write to 0x2B ack data: 0x89 
read to 0x2B ack data: 0x64 0xD0 0x02 0x00
write to 0x2B ack data: 0x70 0x02 
write to 0x2B ack data: 0x89 
read to 0x2B ack data: 0x64 0xD0 0x02 0x00
write to 0x2B ack data: 0x89 0x64 0xD0 0x02 0x00 
write to 0x2B ack data: 0x89 
read to 0x2B ack data: 0x64 0xD0 0x02 0x00
write to 0x2B ack data: 0x89 0x64 0xD0 0x02 0x00 
write to 0x2B ack data: 0x51 0x0D 
write to 0x2B ack data: 0x1A 0x26 

 Attached is the schematic for the design. 

The power supply is a official R-Pi4 USBC adapter. 

Any hints why this is the case?  

[Didier HERROUIN]

Dear Richcj10,

When you unplug the charger, you observe that it comes back only to 5V when you re-plug.

It behaves as if the negotiation between the charger and the SINK fails.
Could you record the traffic on I2C and on CC lines after the unplugging ? 

Then, what is the role of D10 ? I am afraid that there could be retrofit between 2.7V and 3.3V.
Where does 3.3V come from ? Is it supplied by another part of your circuit ? Does it switch off when you remove the charger ?

You can try to remove D10 and connect VSYS to GND. 
A 1µF capacitor is also missing on VDD.

[Richcj10]

I added the 1uF cap. No change. 

- I tried the code with a sparkfun dev board: https://www.sparkfun.com/sparkfun-power-delivery-board-usb-c-qwiic.html 

It worked fine with VCC = 3.3V and worked in the "dead battery mode" (VCC = 0V)  (9V showed up just fine any way I tested) 

When you unplug the charger, you observe that it comes back only to 5V when you re-plug. - Yes

Could you record the traffic on I2C and on CC lines after the unplugging ? - Nothing happens on I2C, I will record CC. 

Then, what is the role of D10 ? I am afraid that there could be retrofit between 2.7V and 3.3V.
Where does 3.3V come from ? Is it supplied by another part of your circuit ? Does it switch off when you remove the charger ? - Supply VSYS when VSUS is 0V. I tried removing the diode and no change. The 3.3V stays consistent. It is from a internal battery. In the dev board linked above removing the diode prevented dead battery mode from working.

You can try to remove D10 and connect VSYS to GND. - Can you explain this mode? 

[Didier HERROUIN]

Dear Richcj10,

In most of the cases, VSYS is connected to GND. It can be connected to 3.3V when you want to save some power (the system supplied by 3.3V will consume less compared to VDD power supply).

In your case, you have connected CC1DB/CC2DB for dead battery compatibility so the STSUB4500 does not expect any power supply when no charger is connected (VSYS and VDD should be 0V).

Let me know your tests results.

[Richcj10]

In dead battery mode vsys would be 0v. I tested that, no difference. 

[Richcj10]

Any other ideas I should look for? 

[Didier HERROUIN]

You should connect a USB spy between the Source and the Sink to analyze the communication on the CC lines when you re-plug the charger. First, the SOURCE should start sending its capabilities and the SINK should acknowledge. Then, the negotiation for the PDO selection should take place.

Initially, you provide the I2C communication messages: what is the target of these messages (I assume they come from your MCU) ? Indeed, STUSB4500 is a standalone product, it can be used without a MCU. Can you disconnect the MCU and try again ?

[Richcj10]

I switched boards and uploaded PD0s using the Sparfun example code. Just to test the hardware. 

It seems to just work. I wonder if my code (I did find out my code was not writing correctly to all regs) had damaged some internal register in the internal storage. 
But the good news is the hardware works. Yea! 

Did you ever find out how this device should work in dead battery mode? (without the diode) I have not been able to make that work w/o the diode. The board ( in dead battery mode ) will not work w/o it.
I did note that with my current circuit design, when in dead battery mode, the diode allowed VCC (3.3V in my design) to be back feed to the rest of the circuit from the 2.7V rail. This caused the IC to not run properly. In the future I will prevent 3,3V from getting back fed in this state. I need the VSYS to be present to allow I2C traffic work in absence of USB. 

[Didier HERROUIN]

Dear Richcj10,

The dead battery mode means that the STUSB4500 is not supplied when no charger is present (this mode can be used also without any battery, if the system is directly supplied from the VBUS). 
In your case, as you need to constantly supply VSYS, you do not use the dead battery mode. So you can connect CC1DC/CC2DB to GND (see§2.2.2 in the datasheet).