TPS65982: Stuck in boot

Schematic 

Another snapshot using advanced template to get at boot flags.
AdvancedPDWorking_A.zipAdvancedPDNonWorking_B.zip

Hi Igor,

Thanks for reaching out to E2E.

1. Could you provide the .bin file you are using.
2. Which application GUI are you using?
3. If I understand correctly, both designs (old and new) use the TPS65982, and there are possible changes to the board but you are not sure.
   • Which design(old/new) is pictured in the schematic above
   • If you are comfortable sharing it in a public forum, could you provide the schematic for the other design if you have it
     • We can also switch to private messages or email if you are concerned about sharing on a public forum
4. Could you provide PD logs of both cases (old design and new design)
5. Are you planning on using the Device as source only?
6. I would like to confirm that when you are testing the old design and new design, the only thing changing is the board with the design? Whatever cable and device that is receiving the 5V or 20V stays constant between the tests?

Thanks and Regards,

Chris

1. I only have hex files (both read out from the flash chips on the two revs of boards). At the moment I am running Rev A hex on both to try to eliminate that variable

2. TPS65981_2_7_8 Application Customization Tool GUI Version : 6.1.3

3. Correct we have two revs, with a gap in documentation. Rev A works, Rev B does not. Schematic for rev B is attached in the thread above. No Rev A schematic is available

4. No idea how to get PD logs

5. Device appears to have been DRP, but it really just needs to be a sink and take 20V 3A power from USBC input

6. Correct, two boards side by side, same Lenovo 65W laptop USBC supply and Aardvark adapter/TI GUI. I just move USBC and I2C wires

Also, not sure it matters but metal and mask revs seems to be going backwards:

older board reports

Revision ID Metal 0x1 (0x1)
Revision ID Base 0x1 (0x1)

Chip marking is TPS65982  83A5T0W AB G1 10

while newer board has:

Revision ID Metal 0x0 (0x0)
Revision ID Base 0x0 (0x0)

Chip marking is TPS65982  93CKK2W AB G1 120

FlashImages.ziphex files as read out from Flash on both boards

another bit of data- here are the nets with differing voltages between two boards in steady state: 

Hi Igor, 

Thanks for the update.

There are PD analyzer devices that you can put in series with the USB C cable and connector that allows us to read the PD communication on the CC lines. This is very useful in seeing what state and what messages they system is in and is sending.

I'll see if I can decode the hex files and will get back to you latest next week.

Thanks and Regards,
Chris

do you see anything strange with parts markings/datecodes/mask ID or voltages?

Hi Igor,

I'll have to check with another team member about the part markings, I'm not sure myself.

I'm a little concerned about the 5V voltage dipping lower on Rev B. The devices are sinking 5V from the same external supply so I would not expect too much of a difference there.

Also the lack of voltage on LDO_BMC is concerning. This indicates power on the CC line driver, which is what would be sending PD traffic from the 982 device. 

You mentioned earlier that: 

Igor Orlovich said:

I do see PD traffic on CC line for about 7 seconds.

Would it be possible to get a scope trace of what you are seeing? Also, could you explain what you are doing/what state the system is in when you are measuring this? Are you plugging in the cable, is this steady state, what VBUS voltage are you seeing?

Thanks and Regards,

Chris

Hi Chris,

1. 5V dipping to 4.6V is due to the the system 5V supply being powered by VBUS after external switches. So on the working board that sends 20V to DCDC and produces clean 5V. On nonworking board the switcher only gets 5V and enters passthrough mode with associated dropout. So I think that one is OK
2. I also see voltage drop on SPI bus pullups indicating we are pulling 50uA or so into TPS65982, but that is likely due to LDO_3V3 running a bit above the main 3.3V (3.4V vs 3.3V). That would indicate at least that the SPI lines get from flash to the PD chip. I definitely do not see SPI traffic. SPI MISO line comes up together with LDO_3V3, so it'd appear the chip should try to read flash but t does not.
3. Agree on lack of LDO_BMC. It's not clear to me when this gets enabled in boot sequence and whether it's dependent on something else
4. Scope plots- SPI MOSI vs VBUS  on cable insertion, Rev A talks to flash, Rev B does nothing :
   
5. Scope plots: CC vs VBUS. 
   
6. What is the function of config pins GPIO1/Debug3/Debug4/GPIO5? I see nothing in documentation of what they do besides being configurable GPIO. Are they just used by an EVK firmware to load particular app profiles and don't do anything otherwise?

One more - flash chip select vs VBUS

Hi Igor,

Chris is currently out of office, he'll return by 10/31.

Thanks and Regards,

Raymond Lin

Hi Chris,
any updates on why this chip is not trying to load flash?
Meanwhile I went ahead and created a new clean project for UFP device with just basic 20V 3A sink and tried applying settings via I2C, but the chip stayed in boot
I also tried flashing it and restarting but once again nothing changed
So it looks like getting it out of boot mode is the key.
Checked several boards and they all behave the same.
LDO_BMC staying low appears to be the result of not booting, not the cause as it seems to come up on a working one after flash load:

Hi Igor, 

No updates yet. I'm still working on it and will give you some feedback latest this Friday.

Thanks and Regards,

Chris 

Thanks and let me know if you need more info. 

Yes, will do.

Hi Igor,

Thanks for your patience.

I've been looking at the information you provided and still need to look into more on my end.

Igor Orlovich said:

What is the function of config pins GPIO1/Debug3/Debug4/GPIO5? I see nothing in documentation of what they do besides being configurable GPIO. Are they just used by an EVK firmware to load particular app profiles and don't do anything otherwise?

If you check the EVM page, you can find the altium files for the 982EVM and the EVM guide. It looks like those pins choose displayport and PD settings. If your schematic is correct, you have 1100 which would allow for a 20V sink.

https://www.ti.com/tool/TPS65982-EVM

Igor Orlovich said:

If I try changing configuration inside application GUI, everything gets set right back to where it was. I also am not able to read any ADC channels as it keeps defaulting to temperature.

How are you flashing the hex files to the device? Do you convert them to binary and flash them over Aardvark using the GUI?

Igor Orlovich said:

Meanwhile I went ahead and created a new clean project for UFP device with just basic 20V 3A sink and tried applying settings via I2C, but the chip stayed in boot

The fact that a clean project is not working properly may indicate schematic issues. Has the latest board worked properly before? I compared our EVM layout to the schematic image you sent but did not see anything obvious.

Just making sure, but you select "flash from current project" here?

Apologies for the delays.

Thanks and Regards,

Chris

Hi Chris,

this revision has not worked at all. And the problem is repeatable across the whole build.

We are chasing supply chain just to make sure parts are good to begin with.

1. it seems GPIO pins are used by a special firmware version that uses that to load various profiles?

2. When I created clean new project, I used GUI to create files and aardwark to flash using Flash from current project indeed.

The issue is we don't even get to loading flash, the part is stuck in boot and all I can tell from the documentation is that it powers up, checks MISO pin being high  and then is supposed to try loading, but  does not. Any way to get more details on  the necessary conditions for the chip to get there?

Hi Igor,

I'm not sure if there are more ways to get details outside of looking to state machines for the firmware. I can try reaching out to a team member.

Thanks and Regards,

Chris