TPS65987D: PP_HV switches not closing

Hi,

Could you please attach the PD log file here as the image is a little small and harder to read? Also, do you have the analog scope captures of VBUS, PPHV, etc?

Thank you,

Hari

Sure thing.

Here is the dump from the Cypress protocol analyser:
PDlog.csv

And here are the scope outputs

CH1: VBUS CH2: PP_HV, 10ms/div


CH1: VBUS CH2: PP_HV, 200ms/div


Also, here is the first burst of CC activity after connection in context of VBUS.

The source currently supplying this board is the source half of the PD Duo EVK.

Hello Arda, 
Will look into this and get back to you. 

-Deepak

Thanks Deepak. Just some more information in the event it's useful. I just received a standalone FT4232H module today so I can program my board without involving the EVK. I can confirm I am able to read the I2C 0x03 and 0x0F registers and the values match that of the Duo EVK sink. This again, strongly suggests the controller is active and responsive.

Hey Arda, 

Thanks for that test, that is awesome to know the controller is active. Currently on a debug, will get back to you early next week on this. 

- Deepak 

Hello Arda, 

Sorry for the delay in reply. I had been addressing another high priority debug. 
I would be needing the following:
1) Can you send me the CC activity of your board and the EVM duo board as separate file.
2) Can you send me the binary and the project file. 

-Deepak


 

Hi Deepak,

No worries.

1) Sure. The custom board's one is the same as what I attached above. Attached again here.

PDlog_DuoSink.csvPDlog_CustomBoard.csv

If you install the EZ-PD analyser utility, you can import these CSVs and have it decode them for you.



2) I'm not using a bespoke binary/project just yet. It's the demo EVK binary that's supplied with the TPS6598x configuration utility in the recovery folder.

tps65987_power_duo_mode_SINK_evm_flash_image.zip

Hi Arda, 

Can perform a test on your custom board:
1) Use a default configuration and populate a value of your choice in register Customer Use (0x6). 
2) Load the firmware
3) Once firmware has been loaded, enter debug mode and check if the values you set in register 0x6. 

Let me know if it reflects what you set during programming. 

Regards, 
Deepak

Hi Deepak,

So I'll lay out what I did here.

1) Project -> New Project
2) TPS65987DDH
3) Standard
4) UFP Only
5) Set customer use 1 to 0x6


6) Save binary (Full Flash image) with the following offsets:


7) Connect FT4232H to SPI and I2C2 headers.
8) Binary -> Flash from binary file
8) Unplug/replug PD 
9) Debug -> Debug Mode


10) Customer word 1 returns 0x06 as expected.

EDIT: I also tested on I2C1. Customer word 1 readback is the same.

Hi Arda, 

Thanks for the details on what you have done. It rules out some issue. Also, it proves that the firmware is loaded on the custom board and we can read back values in debug mode. 

Can you try the following configuration: 
New project - 987DDH -> Standard -> DRP prefers power source 

Could you use this configuration and check if PP_HV switch closes. 

-Deepak 

Hi Deepak,

With DRP, it does close successfully. So what does this mean? Why does it not close with the Duo Sink's binary, but it does close with a DRP project config? Could this have something to do with my VIN_3V3 pin being connected to a (currently) unpowered LDO? I wouldn't think this would make a difference as there's no voltage being delivered to VIN_3V3 in either case of the LDO being powered, or in the Duo's case, the pin being floating. However if there's undocumented current sensing on the VIN_3V3 which might be seeing the unpowered LDO as a 'load', that might explain things, especially considering that I imagine the Duo's firmware wouldn't have the 'externally powered' option set.

I'll flash back the Duo's firmware and unstuff the unpowered LDO and see what happens. Ultimately I will need it to work in cases where the LDO isn't powered though, as that would correspond to a dead battery condition. Functionally, this product is essentially a power bank. It's very similar architecture-wise to your discontinued TIDA-01515, but uses a bq25792 instead.

EDIT: Removing the LDO has not changed the behaviour of PP_HV not closing with the Duo Sink's firmware.

I mean, sure don't misunderstand me - I wasn't planning on using that binary for production purposes. I already have my own project file that configures the system as a DRP. But it is a little concerning why the demo binary doesn't work on my board, but does on the Duo, despite there being seemingly no difference in configuration. As you can imagine, the potential for other skeletons in this proverbial closet, is quite high.

You mentioned GPIOs - of course you're right that there are GPIOs specific to my application on this board. However I have also broken out the unused ones on this prototype 'just in case' (you can see them in the board render around the perimeter of the TPS). Some of these GPIOs (for example GPIO13/14/15 which are currently floating) correspond to push button inputs on the Duo. Is it possible these aren't pulled up internally (even they can be configured to do so) in the demo firmware, and the fact that they are floating on my board are triggering some sort of erratic behaviour causing multiple GPIO events to fire? The only thing that makes me doubt this is that the Duo source which is supplying my board, has its 5V LED on solid. If the floating pins on my board were causing erratic switching between 5/9/15/20V, I would expect this to show up on the Duo source board's LEDs. Instead, the 5V from the source is stable - my board will simply not close PP_HV.

If possible I'd like to understand why there is this discrepancy. Because unexplained differences like this are where future gremlins love to hide.

EDIT: Another thought - perhaps it has something to do with the chip silicon revision? I had to get my chips from a chinese supplier as I don't need to say, stocking is currently an issue. However I don't see anything on the my chip that would suggest they're experimental chips that leaked out somehow. I had this issue a few years ago with your old Luminary Micro acquired parts. Perhaps that's a factor?

EDIT 2: I just tried grounding GPIO 13, 14, 15 so they're not floating (they're functionally grounded through 100k resistors on the Duo) and there's no difference. I also tried removing all the unused pullups for I2C interrupts and I2C3 (R11, R12, R13, R14, R15 in my schematic) and the 1M pulldown (R17) recommended in the datasheet in order to make my board look even more like the Duo sink. Still no change - PP_HV is not switched. If I have to proceed by ignoring this problem and just hope that there isn't some bigger one lurking beneath this one, then so be it. However I would consider it very troubling if the manufacturer of this part, TI, is unable to tell me why it is that two (now) seemingly identical configurations of the part have vastly difference performance.

Hello Arda, 

I do totally agree with you on the not knowing the differences. And why it is working when using the default project configurations. 
I will check with the larger team sometime next week on their thoughts on why they see such differences. I believe it could be the project configurations themselves that is making all the differences you see. Reason being the code on PD controller cannot be changed. There is only one version of code available. The only variable that can change is the App configuration, which is strictly related to configuration. 

That said, let me mail you if I get word from the larger team. 

-Deepak 

Thanks Deepak. If it makes things easier, I've exported a simplified version of my schematic that shows how my board is currently configured (DNFs etc).  I also included a summary of the outcomes of this thread.
5657.USB PD prototype.pdf

Thanks Arda, Appreciate it.