PTN5110 sourcing high voltage

[ayaka_ohira]

Hi there,

We have PTN5110 and would like to know how to source high voltage (more than 5V). 

From the datasheet. it seems that if you want to support higher voltage, you need to use the EN_SNK1 pin to enable this. This means we need two separate power source, one or 5V and the other for anything above 5V. Is this the only way (ie 2-rail power system) or can we have 1 rail power source and use EN_SRC to supply 5V to 20V output?

Thanks,

Ayaka

[TomasVaverka]

Hi Ayaka,

You can use one FET control, EN_SRC, to switch other power rails into VBUS. As default, after the attachment you would adjust the power supply to output 5V then turn on the load switch to source VBUS with 5V. After the sink negotiated a higher power contract, you would then adjust the power supply to the requested voltage by the sink. Make sure the power supply switching time, output voltage overshoot, output voltage undershoot, voltage tolerant meet the PD spec. requirement.

Best regards,

Tomas

[ayaka_ohira]

Hi Tomas,

Thank you for your reply.

So in order to use one FET (EN_SRC) to control the VBUS voltage of range 5V to 20V, what registers do I need to setup? I don't want to use the EN_SNK1 pin to turn on the higher voltage after negotiation as that's done by a gpio from the main MCU.

Currently what I see is that, as soon as I send out a command "SourceVbusHighVoltage", EN_SRC pin goes low and EN_SNK1 pin goes high for around 5ms. How can I change this so EN_SRC will stay high even after I send the command to source high voltage? Is that possible?

Thanks,

Ayaka

[TomasVaverka]

Hi Ayaka,

You are using EN_SRC to source 5V as well as higher voltage, so after a successful higher voltage contract you just jack up the supply to the negotiated supply and then send PS_RDY message to the sink. Do not issue SourceVbusHighVoltage command since PTN5110N will disable EN_SRC and assert EN_SNK (as the FET enable to source high voltage). The reason the PTN5110N does that is because it only has two FET controls – one to source and one to sink, and it does not an extra pin to control the FET to source high voltage. So, we designed the PTN5110N in such that it will assert EN_SNK when command sink VBUS or source high voltage is sent by the host. The host is in source mode, it uses EN_SNK to source high voltage, and when the host is in sink mode it uses EN_SNK to sink from VBUS.

Best regards,

Tomas

[ayaka_ohira]

Hi Tomas,

Thank you again for your reply.

It's good to clarify that sending SourceVbusHighVoltage command was the reason EN_SNK pin was asserted.

Now we have just tried what you suggested; send normal source command (SourceVbusDefaultVoltage) and just bump up the voltage from 5V to 9V but as soon as the voltage goes up, EN_SRC pin is pulled low. Therefore VBUS disappears and we cannot source high voltage.

I've attached files that describes our problem. It contains 1) a rough HW block diagram of our circuit around PTN chip, 2) scope image of EN_SRC pin and when we try to feed in 9V to VBUS, 3) a log from our MCU. Please have a look. 

Questions:

1. Why does the EN_SRC pin go low as soon as we try to feed higher voltage than 5V?
2. Is there some registers that we need to set in order to tell the PTN that we want VBUS to have higher voltage than 9V?
3. After we feed in 9V, we notice the Alert bit "VBUS Voltage alarm Lo" and "VBUS voltage alarm High" are both set. But our alert mask does not have those pins set. Would PTN turn EN_SRC off automatically because it detected the Vbus alarm? It does not make sense that it detected Voltage alarm high in the first place though (the threshold is set at 21V).

Thanks,

Ayaka

[TomasVaverka]

Hi Ayaka,

Not sure why EN_SRC goes off when you tried to source more than 5V. Might be just some setting so I need a full I2C trace to figure this out. 

1. EN_SRC should not automatically goes low when you source more that 5V. If Voltage alarm is enabled then there will be an interrupt to TCPM. Not sure why EN_SRC goes off when higher voltage is sourced through the same FET. Do you have an I2C for this? Does PTN5110 reports any fault? What is the OVP of the 5090 set to? Can you capture an I2C trace that includes PTN5110N initialization, successful contract and VBUS go off due to EN_SRC being disabled?

2. There is no such register.

3. It does not make sense if both alarm low and alarm high are triggered.

Best regards,

Tomas

[ayaka_ohira]

Hi Tomas,

Please have a look at the attached raw I2C trace to PTN chip from the initialisation until we get a 9V explicit contract.

Thanks,

Ayaka

[TomasVaverka]

Hi Ayaka,

1. For the 8-bit registers, you cannot write/read two consecutive registers in the same I2C operation. If you want to write/read to two consecutive registers you must break the I2C operation to two 8-bit write/read operations. For transmit and receive buffers, you can do the whole message in one I2C operation.

2. To send a PD  message, you must first write the message to register 0x51 with a byte count, then the message to TX_BUF_BYTE register. All must be done in one I2C transaction. The you write to register 0x50 to send the message.

3. I do not see a successful 5V contract for the following reasons:

A.The PD message is written to TRANSMIT register first and not to TRANSMIT_BYTE_COUNT first. I do not know what PTN5110 sent onto the CC1 pin.

B. I do not see the other device sent ‘request’ message because I don’t see the I2C for reading the receive buffer event there was an RX interrupt.

C. In the 9V contract, I do not see any receive interrupt and the request 9V message is missing.

Please make sure that there is a 5V contract successfully negotiated, and there is a 9V contract request by the other port. It is an arduous process to decode the I2C trace. If you can show that both 5V and 9V contracts are successful and EN_SNK is loss when the 5V source is being ramped up to 9V, then we can take a look into this again. 

Best regards,

Tomas

[ayaka_ohira]

Hi Tomas,

Thanks for your reply.

I did not include the PD message exchange in the previous log so here's the updated one.

I understand that decoding this log is very tedious but we are struggling to trace I2C coms and have the PD coms behave the same way, that's why we ended up with a very basic log.

Please have a look at this log and let me know if it's useful to you. If not, what other information I could provide more.

Appreciate your help.

Ayaka

[TomasVaverka]

Hi Ayaka,

OK, we will take a look at this new log file, but it may take some time. Meanwhile, would you be willing to send us your board and all the necessary power supply, cable … so that we can duplicate the issue in our lab? We have all the debug tools available which would allow us to debug it much faster. If you are willing to ship us your board, please create a standard support ticket so that I could send you our shipping address and further instruction.

Best regards,

Tomas

[ayaka_ohira]

Hi Tomas,

It is probably difficult to send through the board to you so we might have to think of other ways to get through this problem.

What could really be useful for us is a flow chart or set of instructions that shows exactly how we should transition from 5V to higher voltage. I've attached a flow diagram from another TCPC chip for reference. That will provide us with the guideline of how we should transition from one voltage to the other.

Also could you provide a System Use Case block diagram (just like section 8 of PTN5110 datasheet) for sourcing 5V to 20V using EN_SRC? EN_SNK1 should be only used to enable sinking.

[TomasVaverka]

Hi Ayaka,

There is no special sequence to source 9V. For a DRP role device we just follow the flowchart (DRP initialization and Connection Detection) from the TCPC spec. Attached is the I2C trace from our board which the code was modified to source 9V about 30mS after sourcing 5V the TCPC command 0x77 (sourceVbusDefaultVoltage). The trace was captured using the logic analyzer from Saleae. You can download the software from Saleae and load up the trace to see what is going on. The trace include the I2C initialization of the PTN5110N, as well as the I2C during connection, sourcing 5V and then 9V. On the trace you can see CC signals as well as VBUS switching from 5V to 9V. EN_SRC remains at logic high and did not drop.

The source FET is not NX20P5090, but it is the NX20P3483. The code sends an I2C command to the NX20P3483 to switch from 5V source to 9V source. The PTN5110N is not involved in the switching of the power rail process, and the process is transparent to PTN5110N. The 9V is connected to the High Voltage switch of this device.

You can use this as an example to compare your code against.

Saleae software can be downloaded from here. The analyzer does come with an I2C decoder and you can see the decoded I2C trace on the lower right hand side of the screen.

Best regards,

Tomas

[ayaka_ohira]

Hi Tomas,

Thanks for your trace information etc. It was very useful to see the whole I2C trace that way.

We finally figured out what was causing the VBUS to not go up to 9V.

It was the VBUS_VOLTAGE_ALARM_HI_CFG register, where this value was somehow reset to ~6.5V.

There are things that I thought differently:

• I thought VBUS_VOLTAGE_ALARM_HI_CFG/VBUS_VOLTAGE_ALARM_Lo_CFG were only for alarm notification only. Nowhere in the datasheet it says that if these alarms are triggered, it makes a decision to turns off the EN_SRC by itself.
• We set the High Alarm to 21V at initialisation of the PTN chip. However when we read the value written in VBUS_VOLTAGE_ALARM_HI_CFG register, it is somehow set at 6.5V. We are not sure how this register contains a different value but we noticed every time we turn 9V on, this register contains 6.5V.

My question to you is:

1. Does the PTN chip re-write the VBUS_VOLTAGE_ALARM_HI_CFG register at any point by itself, say triggered by a command?
2. If not, the only way to modify the value in VBUS_VOLTAGE_ALARM_HI_CFG register is through I2C command?
3. I noticed in your I2C trace that you do set the VBUS_VOLTAGE_ALARM_HI_CFG and VBUS_VOLTAGE_ALARM_LO_CFG registers after you send SourceVbusDefaultVoltage command. What happens if you set those registers before you send the source command?

Thanks,

Ayaka

[TomasVaverka]

Hi Ayaka,

Glad to hear you figured it out!

Answers to your questions:

1. No, the chip does not write to the VBUS_VOLTAGE_ALARM_HI_CFG by itself.

2. Yes, you need to go through I2C to modify this register.

3. Does not matter if you set the alarm register before or after you send SourceVbusDefaultVoltage.

Best regards,

Tomas

[ayaka_ohira]

Hi Tomas,

Here are some answers to your questions:

- There's no fault reported by PTN when this happens. 

- OVLO pin on the 5090 is left unconnected

- I will get back to you with a full I2C trace tomorrow.

Thanks,

Ayaka