PTN5110 sinking high voltage

cancel
Showing results for 
Search instead for 
Did you mean: 

PTN5110 sinking high voltage

Jump to solution
317 Views
marcoventurini
Contributor I

Hello,

I'm usign the PTN5110 connected to an MCU to create a USBPD sink

I'm are verifying the output of out device against the output of other compliant PD chips and standard PCs.

The only one that is not working is the PTN5110.

I configure the device as an UFP by following the steps below

set ROLE_CONTROL 0x0A

then the following commands

COMMAND 0x55 (sink vbus)

COMMAND 0x33 (enable vbus detection)

I plug the battery changer cable and, based on the reading of CC_STATUS I write the orientation in TCPC_CONTROL

right after I enable the automated answer (based on my experience, i could not find any decent information about it, neither in the datasheet or the programming guide)

RECEIVE_DETECT 0x21

What happens at this point is that a GOOD_CRC is replied to a SOURCE_CAP packet, but few us after an Hard Reset happens.

marcoventurini_0-1628777841153.png

If we use another device instead of the PTN5110 everything goes smooth

marcoventurini_1-1628777923415.png

Since the Hard Reset happens right after the good crc, and since a good request in a working example is sent more than 100 us after, I'm assuming that is either the PTN5110 to trigger it, or is causing the power supply to send it.

What can be the cause of this behavior? This has been observed with two different PD chargers already.

Thanks

 

 

Tags (3)
0 Kudos
1 Solution
303 Views
TomasVaverka
NXP TechSupport
NXP TechSupport

Hello Marco,

I think we need additional debug information to figure out why there is a hard reset after PTN5110 sent GoodCRC. The hard reset normally means that there is something seriously wrong such as power related issue or protocol violation…

1. We need the I2C trace from the time the charger is plugged into the board with the PTN5110. This will allow us to see what is going on between the PD controller and the PTN5110.

2. We also need the trace of CC1 and CC2 lines, VBUS, EN_SNK, nALERT. You seem to have a PD protocol analyzer connected. What PD protocol analyzer is this? Can this protocol analyze display waveforms of CC1 and CC2 lines, VBUS, EN_SNK, nALERT signals? Please capture these signals from the time the charger plugged in until after the hard reset occurrence.

3. What happened after the hard reset? Did the connection re establish and hard reset repeated?

4. Was PTN5110 in the dead battery condition when the charger is plugged in?

5. Did the board get power and then lost power after the hard reset?

6. Can you send the schematic of the circuitries around the PTN5110? Is this a PTN5110 or the PTN5110N? Which version of the PTN5110 you are using? The correct device for a dead battery condition is PTN5110DHQ, PTN5110NDHQ, PTN5110HQ or PTN5110NHQ. Do not use PTN5110THQ or PTN5110NTHQ since these are DFP devices.

Table 1.jpg

Best regards,

Tomas

View solution in original post

0 Kudos
3 Replies
259 Views
marcoventurini
Contributor I

Hello Thomas,

I made it by implementing the same procedure on an MCU.

The pitfall is that the PD protocol has a lot of unneeded complexity, and the timeouts are very tight.

Basically the procedure is the one described above, but as soon as the goodcrc message is replied to the source capabilities, the power supply will allow a request only within 30 ms, before sending and Hard Reset and rebooting the PD state machine.

Another pitfall is that, if you reply as soon as the message is read from the RX buffer, even if you set the retries to 3, the TX message will clash with the RX message (why??? may it be the goodCrc that it's using the line?) and it will trigger the TRANSMIT_SOP_MESSAGE_DISCARDED interrupt... if you hook a resent to this event, you will finally manage to send a message to the source.

Thanks for your support,

Marco

 

 

 

 

 

 

0 Kudos
245 Views
TomasVaverka
NXP TechSupport
NXP TechSupport

Hello Marco,

I hope you fixed the issue successfully.

Those timings are defined by the spec and the firmware must adhere to spec requirement to meet these timings.

The RX message takes precedence over the TX message as defined by the spec. When there is a collision, the host will get TRANSMIT_SOP_MESSAGE_DISCARDED interrupt. The host must resent the message.

Best regards,

Tomas

0 Kudos
304 Views
TomasVaverka
NXP TechSupport
NXP TechSupport

Hello Marco,

I think we need additional debug information to figure out why there is a hard reset after PTN5110 sent GoodCRC. The hard reset normally means that there is something seriously wrong such as power related issue or protocol violation…

1. We need the I2C trace from the time the charger is plugged into the board with the PTN5110. This will allow us to see what is going on between the PD controller and the PTN5110.

2. We also need the trace of CC1 and CC2 lines, VBUS, EN_SNK, nALERT. You seem to have a PD protocol analyzer connected. What PD protocol analyzer is this? Can this protocol analyze display waveforms of CC1 and CC2 lines, VBUS, EN_SNK, nALERT signals? Please capture these signals from the time the charger plugged in until after the hard reset occurrence.

3. What happened after the hard reset? Did the connection re establish and hard reset repeated?

4. Was PTN5110 in the dead battery condition when the charger is plugged in?

5. Did the board get power and then lost power after the hard reset?

6. Can you send the schematic of the circuitries around the PTN5110? Is this a PTN5110 or the PTN5110N? Which version of the PTN5110 you are using? The correct device for a dead battery condition is PTN5110DHQ, PTN5110NDHQ, PTN5110HQ or PTN5110NHQ. Do not use PTN5110THQ or PTN5110NTHQ since these are DFP devices.

Table 1.jpg

Best regards,

Tomas

View solution in original post

0 Kudos