TPS25762-Q1: TPS25762C-Q1 Issue with CC signal and temperature

Hi Pontus,

It appears your LDO_3V3 net is tied to pin 22.  It should be connected to pin 27 instead.  The device will not run hot under no-load condition.  Your input supply should show no more than a few 10s of mA.

Regards,
Eric

The label had been incorrectly placed. LDO_3V3 is on pin 27.

The board also contains a TUSB8041IPAPQ1 usb hub and a few buck converters for 1v1, 3v3 (LDO) and 5V and the entire board uses about 100mA at standby @ 18V input. I don't think that sounds to far out from what would be expected.
Thermal camera does show a hotspot on the TPS25762 IC.

Pontus,

18V is the point at which 762 will enter an over-voltage protection and shut off the internal DC/DC.  This may explain why you're not getting more than 1A - not sure how your supply is configured but it may be increasing it's output to compensate for IR drop.

I can't make much of your CC traffic - it could just be noise intepreted as high/low by Saleae.  I'd need to see the timing information and the analog waveform.

I'm confused on your buck converter comment - are you feeding the output of the bucks to the LDO pins of 762?  Only the 5V rail should be overdriven.

Regards,
Eric

The board is intended as a prototype that is to be mounted in a vehicle with 24V system. For that reason, I did have my PSU set to +24V for a while.
I have now lowered it to +15V, but still nothing. The datasheet says that it should be able to handle MAX +30V, so the 762 shouldn't have tanken any damage, right?

I will get some screenshots from my oscilloscope asap. The signal on the Saleae is only present when I plug in a sink device.

The buck converters is only connected to the TUSB8041 IC (1V1 & 3V3) and the 4xUSB-A ports (5V).
None of the LDO-pins on the 762 is externally feed, they only have decoupling capacitors connected to them (Except for the 3V3 that also has the eeprom vcc pin connect to it).
I've attached the complete schematic.

usbpd_hub_schematic.pdf

No damage at 24V - you just won't get any output from 762.  With 15V, I expect everything should work.

Have you flashed the EEPROM with firmware?

Regards,
Eric

I did get about 500mA out when supplying 24V.


Yes, i did flash a firmware. I did a read back to confirm and it matched what I has written.
I'm unable to upload the config file here, but I've uploaded it to pastebin: https://pastebin.com/F8LMmtHS

I did not manage to get the capture working on my oscilloscope. But I did confirm that Saleae as showing noise.
When connecting a Valve Steam Deck (that I have verified uses USB PD), the CC lines are at a stable 1.73V and 4.63V, no data.
My USB tester, a JOY-IT JT-UM120, does not detect any packages either. 

USB PD should not need D+ and D- connected, right?
The board i'm working on is a USB 3.0 hub with fast upstream charging, so I don't think I can utilize the D+ and D- lines for anything other than 
for the USB hub IC.

I did grab a couple of images from the thermal camera:
With the steam deck connected drawing 800mA @5V

No load temp:

Pontus Holmberg Borg said:

USB PD should not need D+ and D- connected, right?

Correct.  CC1 and CC2 are the only pins that do PD negotiation.

Unfortunately the TI network won't let me access pastebin.

There's no way we should be observing these package temps under normal operating conditions.  I advise checking the input current to the IC and the 3 LDO pins.  This IC may be damaged, since it will definitely provide PD contracts dependent on the firmware configuration.

Regards,
Eric

Changing the IC did improve it a bit. 
I can now see a package on the CC line from my Steam deck, but the 762 does not respond.
Is there anything in the configuration that would disable CC or anything like that?

Hi Pontus,

Are you able to start experimenting with a fresh board with a fresh IC while ensuring that VIN does not exceed 15V? Is the board temp still overheating, even without a Sink device connected and charging? If so, what do you think is causing the board temp to rise? How many layers is your PCB? What is the copper weight of each layer?

How are you programming the EEPROM? And can you share the JSON used to build your AppConfig or the binary itself that you are using to program your EEPROM? Is the Thermal Foldback Policy enabled? If your board is overheating and Thermal Foldback is enabled, the TPS25762-Q1 may be folding back the output power. If you read 2 bytes from register address 0x96 over I2C, what do you read?

Considering the TPS25762-Q1 land pattern, this device can be quite difficult to assemble correctly. Are you able to confirm that the device was soldered on properly perhaps with X-ray images?

What voltages do you measure on the following pins:

1. LDO_5V?
2. LDO_3V3?
3. LDO_1V5?

Are the voltages on these pins as defined in the Electrical Characteristics table in the datasheet?

I reviewed your schematic and I see that the AGND and PGND are connected to the same GND symbol. Did you follow the Layout Guidelines and ensure that AGND and PGND are connected near the AGND pin via single-point grounding and the following are connected to AGND:

1. LDO_3V3 caps
2. LDO_1V5 caps
3. TMP6131

BR,

Seong

Also, USB 3 also requires higher VCONN power for the redriver IC inside the USB cable. This means that the VCC pin must be externally driven with a 5V 300mA source.

BR,

Seong

I wound need to assemble a new board for that, I might be able to do that within the next days.

Temps are much lower after replacing the TPS25762-Q1 IC. That was the IC that was getting hot. The coil would also become warm, even under no-load situations, I've not observed this after changing the TPS25762 IC.
It's a 4 layer board with 1oz copper for the top and bottom layers and 0.5oz for the inner layers.

I programmed this EEPROM with a Atmel Atmega32u4 that had a modified version of the code found on this github:
https://github.com/thegaragelab/eeprog
I think I got an issue here, not with the software but with the EEPROM IC.

I verified the data by reading back the EEPROM after programming and comparing the content against the firmware file I tried to flash (using HxD).
The data matched, so I figured that all was well.

While debugging today,I check the I2C bus, as to check if the TPS25762 even tried to load the firmware.
It did, but it only issues 1 or 2 read commands and then stopped.

I did a read back of the EEPROM to check it against the firmware file again. This time that content of the EEPROM did not match the firmware file.
I did several test where I wrote the firmware, read back, power cycle and then read back again.
The read back would always match the firmware before power cycling, but never after.

Analyzing the traffic on the I2C showed that a lot of write (and read) are not acknowledged (gets NAK response). I tried several different Arduino libraries for handling EEPROM operations, they all showed this behavior. The EEPROM IC has been proven to work well with Arduino and the first library I used was specifically made for the 24LC-series EEPROM.
I've ordered in a propper EEPROM programmer, should arrive tomorrow.
I will also be swapping the EEPROM IC to check of that is the culprit.

I'll have to get back to you on the content of 0x96. I'm out of office at the moment.

Here are the measurements

1. LDO_5V = 5.45V
2. LDO_3V3 = 3.45V
3. LDO_1V5 = 1.53V

So they appear to be withing range.
I did not see anything in the datasheet for the TPS25762-Q1 about a single-point grounding, but yes.
LDO_3v3, LDO_1v5 and the NTC is as grounded to the same plane as AGND on the TPS25762.

I've tired several cables, both USB 2.0, USB 3.0 5Gbps and higher. All gives same result.
Right now, i'm betting that the TPS25762 is doing very little as there is a problem with the firmware on the EEPROM.

I've now flashed the EEPROM with a CH341A based device and the data is still good after several power cycles.
But still nothing nothing on the CC lines.

Check the I2C communication between the EEPROM and TPS25762, and it's not loaded the firmware.
I'm unable to attach the capture file from the Saleae Logic 2 software, but here is a screenshot.
 

There is 2 package before, where It's checking address 0x74 and 0x75. These get NAK and then it moves on to what you see in the screenshot.
There is no more traffic on the I2C after this.
This is with a new TPS25762 and a new 24CL256 EEPROM IC

Hi Pontus,

Are you programming the EEPROM with a full flash binary? Which base FW image are you using? If you are testing with the TPS25762CQRQLRQ1 (as shown in your schematic), the latest base FW version to use is F311.03.11.0001. If you are testing with the TPS25762DQRQLRQ1, the latest base FW version to use is F411.04.01.0005.

I downloaded the JSON you uploaded to your Pastebin link and generated a full flash binary using FW vF311.03.11.0001. Please try programming your EEPROM with the binary attached below.

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/196/base_5F00_lowregion_5F00_F311_5F00_guiCfg_5F00_2_2D00_11_2D00_15_2D00_39_5F00_full_5F00_flash.bin

FYI - the checking of the 0x74 and 0x75 is expected behavior after POR. 

Please note that the TPS25762C-Q1 variant will not have USB PD 3.2 support. USB PD 3.2 support will be available for the new TPS25762D-Q1 variant 1Q2025. If USB PD 3.2 is required, please consider using the latest variant, TPS25762D-Q1. 

BR,

Seong

Yes, I'm using the full flash binary.
Yes, my order from Mouser contains TPS25762CQRQLRQ1, no D-variant. 
I am using F311.03.11.0001.

USB PD 3.2 is not required as of now.

I flashed your firmware file, but no change.
Still only sends the same requests to the EEPROM as in the screenshot in my previous post.
So there is no way it's reading the firmware of the EEPROM.

I'm don't have much experience with decoding I2C, but this is what I make out of the traffic I'm seeing.

So, the first command is a write command.
They should consist of: deviceaddress + ACK, memory address + ACK and then the data to be written + ACK on each byte.
Where, we are seeing the first part is correct. Then it suggests it want to write to address 0x00. This get ACK by the EEPROM.
All good so far.

But then there is a dead period, that does not look right, and then it sends 0x00 again. It also get ACK by the EEPROM.
So, it's written 0 to the first byte in the EEPROM.

Then it tries to read.
The request are similar. device address + ACK, memory address + ACK, and then the master should just toggle the clock line for each byte it wants to read and the slave will put that data on the data line.

The first 2 parts looks correct, but then the clock line is just pulled low for 52uS and then there is nothing more after that.
3.3k pull-up should be fine, and any capacitance caused by the logic analyzer shouldn't cause an issue for these kind of signals because then it should have had an effect on all traffic. It should not start having an effect after a few packages, right?

UPDATE: I just noticed. The I2C clock frequency is 888Khz. I guess it's trying to run the bus at 1Mhz. 
The 24LC256 is only rated for 400Khz. That is the IC that the datasheet recommended.
The 24FC256 is rated for 1Mhz.

Hi Pontus,

Please try using 400kHZ clock speed and let me know the results.

Do you have TPS25762-Q1 EVM? If so, you can monitor the I2C bus from the on-board Tiva TM4C MCU to the on-board EEPROM when programming the FW patch bundle using the TPS257xx-Q1-GUI and compare with the Saleae capture you have today. 

BR,

Seong

How do I set the clock speed of the I2C?

I cannot find anything about it in the datasheet for the tps25762.

I don't have a evaluation board, unfortunately.

Hey Pontus,

Sorry, I misunderstood what you said and thought your I2C programmer was writing to the EEPROM at 1MHz.

I am actually seeing the same thing on the TPS25762D-Q1 EVM:

1. After addressing 0x74 and 0x75, the TPS25762-Q1 addresses 0x50 and reads from different registers See capture below. It then reads the FW patch bundle data for roughly 250ms afterwards. 
2. My Saleae capture also shows that the frequency is 1MHz (757kHz to be exact) during the FW boot process as well. We also have the 24LC256-I/ST EEPROM on our EVM, so I suppose there is some tolerance to the max clock frequency spec. 

As you already mentioned, the EEPROM seems to be the culprit if it is unable to retain the programmed data after POR. However, the TPS25762-Q1 not driving the clock line for the EEPROM to respond is also something to look into. Can you share oscilloscope captures of the I2C data and clock to confirm signal integrity? Considering the 1MHz clock frequency, you may want to decrease the I2C pull up resistor values to 1k ~ 2.2k ohm. 

BR,

Seong

The eeprom seems to retain the data after POR now.
Here are some captures from my oscilloscope. Note that the timebase is not accurate. There is some bug in my oscilloscope that causes it to 
change timebase when I press the print-button.


Here we can see that the request to address 0x74 and 0x75 is at a slower speed.
We can also see that there is some strange behavior of the clock signal after the last transmission, there is a slower rise time above a certain point.
This is not seen on the other packages. Strange.

Close up on the strange rise time behavior.

The signal integrity of the ~800Khz clock looks fine to me.

Hi Pontus,

One quick note regarding the TPS25762-Q1 FW. During boot from EEPROM, the FW starts with using 1MHz I2C clock rate. If the communication fails, it reduce to 400KHz and retries, then 100KHz before it reports EEPROM load failure. So although we've both observed that the 24LC256-I/ST EEPROM works despite the max clock frequency defined as 400kHz in its datasheet, there is a fail-safe mechanism in place.

Thank you for providing the scope captures. The I2C signal integrity looks fine to me as well. One thing I noticed though is that there is a ground offset. Are there any AC signals around the I2C bus? What is the highest voltage level when the I2C lines are pulled low? 

The rise time you pointed out is indeed strange as the rise time looks considerably long. 

Can you please confirm if the what is highlighted in red in the image below are I2C clock pulses? Can you zoom into this one? It would also help see the signals' voltage levels if you could set the 0V reference on a y-axis partition line. 

Have you tried changing the pull up resistor values to 2.2k? The EEPROM's datasheet also recommends 2k ohm for pull up resistor values.

Your schematic did not show anything, but are there any other devices on the same I2C bus that are perhaps hidden from the PDF?

Can you also share your PCB design files or gerbers?

BR,

Seong

Hi Seong

Thanks for that note. I was wondering about that. Then that shouldn't be cause of the issue.

I don't think there is any AC signals on the board.
I think that the offset was the one I had set so that the channels would be separated. But there seems to be some offset building up on the data line at the end.
Here is a screenshot with the voltage offset reset to 0 on the scope


As you can see, the data line does not go down to 0v at the end.
According to the cursor, there is a ~240mV offset for both lines. But I think it's an issue with the scope.
My other scope and my multimeter does not show any voltage after the trafic has stopped, but this scope does still show the same 240mV offset.
Here is a close up-


Here is a close up that you requested, at the end with the strange rise time.
It is indeed a clock signal. I cannot get a higher sampled capture as the scope is buggy and wont trigger correctly when I lower the timebase.


I've not had the had the chance to change the pull-up resistors yet. I will see if I have any 1K or 2K on hand.
I've attacked the gerbers

usbhub_usb_pd_2024-12-12.zip

Hey Pontus,

Your schematic did not show anything, but are there any other devices on the same I2C bus that are perhaps hidden from the PDF?

Have you calculated the total max system power consumption of your board and ensured you are using a power supply that can accommodate with margin?

You are no longer observing the high board temp, correct?

Sounds good on trying lower resistor values. While you do that, I will review the gerbers.

BR,

Seong

Hi.

There is no other i2c devices on this board.

I currently have a bench PSU that can deliver up to 5A, but I've never seen it pull more than 600-700mA @ 15V.

So there shouldn't be a problem there.

Correct, the temp have gone down, it's now around 40c @ 20c room temp, no load. Goes up a bit when load is applied.

I'll find resistors tomorrow (it's midnight here in Sweden) and update you with the results.

Br

Pontus

Hi Pontus,

Okay - Have a good one!

I just opened your gerbers and I see that the board does not have solid GND planes under the TPS25762-Q1 on layer 2 and layer 3. Having solid GND planes here as well as all other areas of the inner layers would have helped with thermal dissipation. 

Other byproducts of not having a solid GND plane under AC signals, such as I2C, are signal integrity issues, increased noise, and data corruption. This is because AC signals, or digital clock signals, 30kHz and above require a ground reference plane to provide a low-impedance return path. Without proper grounding, the electromagnetic waves from the I2C paths are not controlled. This explains why the TPS25762-Q1 is having issues communicating with the EEPROM.

I recommended doing some research on PCB thermal management techniques, high speed PCB layout, and proper grounding. 

Leverage E2E again and share your updated design files so we can review it before you start a new build. I will close this thread. Please start a new one for any other queries.

BR,

Seong