TPS65987D: Sonosite question about programming the SPI EEPROM on TPS65987D

Hello Russel,

What is configured in this field Transmit Source capabilities (0x32) -> Sourc PDOx -> Advertised mask? if its - Advertise only if externally powered, please modify it to Always advertise and try.

Thanks
Prajith

Hi Prajith,

Thanks for your reply.

Please see the customer's response below. You can see that "Always Advertise" is set. What should the customer check next?

Thanks and regards,

Russ

I checked that part and it looks OK.

Here's a screenshot:

The following request was sent to the customer.

• Check the mode register (Register 0x3) to verify whether the boot sequence is complete or not.

The following questions were also sent to the customer regarding the customer's use case.

• Which boot mode are you using?

• • Please check against Table-5 in section 8.4.1 of the TPS65987D datasheet.

• Which supported Thunderbolt Flash Option are you using?

• • Please check against section 9.2.2.2.2.7 of the TPS65987D datasheet.

• How are you powering the Flash?

• • If using LDO3V3, then are you using BP_WaitFor3V3_Internal for boot?

  • If using external 3.3V supply, then are you using BP_WaitFor3V3_External for boot?

  • If the boot mode is set for BP_NoWait, then are you sure you are allowing enough time for the Flash to power-up and be ready before trying to load configuration data from the Flash?

• Have you tried loading the firmware configuration on an EVM for TPS65987D? If yes, do you see the same current capability issue?

The customer was not able to answer the above questions and is now asking how to determine which mode they have configured in the Mode Register. I am not familiar with the software or firmware for TPS65987D so your help is much appreciated.

The customer did provide a project setup file and a schematic and the customer is under NDA. Is there a secure way to share the customer's setup file and schematic via E2E so that only the customer and TI engineers can see the setup file and schematics?

• Which boot mode are you using?

  • Please check against Table-5 in section 8.4.1 of the TPS65987D datasheet.

• Which supported Thunderbolt Flash Option are you using?

  • Please check against section 9.2.2.2.2.7 of the TPS65987D datasheet.

• How are you powering the Flash?

  • If using LDO3V3, then are you using BP_WaitFor3V3_Internal for boot?

  • If using external 3.3V supply, then are you using BP_WaitFor3V3_External for boot?

  • If the boot mode is set for BP_NoWait, then are you sure you are allowing enough time for the Flash to power-up and be ready before trying to load configuration data from the Flash?

• Have you tried loading the firmware configuration on an EVM for TPS65987D? If yes, do you see the same current capability issue?

Hello Russel,

Is 5V available on PP_Cable pin in the failing case (3A only case)? 

You can send the schematic in the mail thread. 

Thanks

Prajith

Hello Russel, 

Any update from the customer? 

Thanks

Prajith

Hello Prajith,

I asked the customer the following questions.

1. Can you check whether 5V is available on PP_Cable pin in the case where current capability is failing?

2. Also, check whether the PP_Cable pin and other power pins have the expected DC voltages and transient behavior?

I received the following reply.

I haven't gotten the measurements that you request, but I am finding some interesting things.

I've been playing with the settings for the 3rd power source, since that is the one giving us problems.

When I set the current below 3A (tried 2.5 and 2A); the current cannot be read back.

When I set the current to 2A, the system wouldn't even boot up)

When I set the current over 3A (3.1, 3.5, 4, 5) the current read back is always 3A.

It seems that the customer has 3A current capability set but did not have the current limit of the power supply set correctly.

I will follow up with the customer today.

Regards,

Russ

Hi Russ,

See if the customer can answer the above questions posed to them. 

Regards,

Emma

Here is a little more information as I am still coming up to speed on USB PD.

If both 'ends' of the system are powered and the just the USB cable between them is installed, I can monitor the CCx lines and predict whether or not 3A for 5A is going to be recognized by examining the bit-stream pattern going across the cable.

It doesn't seem to matter which end of the cable in installed first as I can make either situation happen.

I was thinking maybe it was partly due to the emarking part installed on the cable, but that doesn't make sense either.

Hello,

Have you confirmed that you are using an active cable? Meaning a cable capable of delivering 5A?

Thanks,

Emma

I'm not sure how to 'confirm' that besides the fact that half the time it does represent the 5A.

And the only active part on the cable is the emark part, so it shouldn't be able to change things.

Hello,

You should be able to confirm with the cable manufacturer whether or not it is capable of 5A. 

Thanks,

Emma

One difference is that when the power is correctly negotiated, the CC line is pulled to ground.

When not properly negotiated, the CC line is pulled down to about 0.4V.

Hello,

Please let me know on the answer to the following questions. If you need help finding the answers, please let me know. This way we can debug more accurately.

1. Can you check whether 5V is available on PP_Cable pin in the case where current capability is failing?

2. Also, check whether the PP_Cable pin and other power pins have the expected DC voltages and transient behavior?

Also, please let me know if you are using an active cable - meant to hold 5A. 

I will be off the rest of the week on Thanksgiving holiday. I will respond to this thread on Monday. 

Thanks,

Emma

I was off last week as well.

The power supplied to both ends is correct and isn't different between the two cases.

I can see the difference between the CC line being pulled to return or to about 0.4V.

I also just discovered that we have a USB PD 'sniffer' in house and am using that.

It seems to be when the 'cable' is recognized or not.

With multiple insertions I can make the system recognize 3A or 5A and it seems rather random.

Is there a way to command the PD controller to 'look' for the cable again?

Hello,

Can you please attach scope captures of VBUS and the CC lines for the different negotiations?

Also, can you try different active cables and see if this is an issue with those cables? This could be a cable issue and trying different cables will help us determine if that is a problem.

Thanks,

Emma

The probes are attached to the CC1/2 lines at the PS side of the USB cable. The PS is always ON.

Hello,

Can you confirm this issue with different active cables from different manufacturers?

Can you confirm which scope capture matches which behavior?

Thanks,

Emma

Yes, this happens with other mfr's cables'.

The 3:43 shot is 'good' at 5A.

The 3:42 shot is defaulted to 3A.

The CC line is fully, low during 'good' negotiation.

There is a funny, 'almost low' state, when it negotiates to 3A

Hello,

I am taking a look into this issue and will update you in a few days with my findings.

Thank you,

Emma

I was experimenting with a wall-wart power supply with USB output.

This supply seems to advertise correctly *and consistently) and can supply the appropriate current.

I noticed that in our system, even if the proper current is negotiated (5A) the ability to provide that current is not there.

The on-board power supply can supply the current if I load it locally, but current cannot pass through the TPS65987 part.

Is there something else to be programmed, besides the basic current setting?

Hello,

Can you attach a scope capture of your VBUS and load current through VBUS along with the CC lines? This way we can look at if you are going into hardware or software overcurrent and if you are pulling the current too quickly through the 987D. Please also check out TPS65987DDH Power Path Performance and Protection to see if there are any other over current conditions you may be meeting.

Thanks,

Emma

Sorry, I just saw your question from last week.

I didn't get a scope picture, but I did see a brief current surge just after connection

I think this is due to the battery charger that we have on the board.

I don't think it is quite 5A, maybe 4 or so.

I'm having some technical difficulty so I can't send pics.

I did notice something as well - it seems that when it 'works' there is communication with the cable.

When it doesn't there is no cable communication.

Why would there be intermittent cable comms?

Update:

The advertisement issue is resolved (I think).

I changed the PP Cable 1 Switch Config to "PP Cable Switch as Output, Guaranteed 4.5 - 5.5V" - it used to be "2.7 - 5.5V"

I don't know why that matters, but it seems to consistently 'see' the cable now.

But, there is another issue.

Although the advertised power is 100W (20V @ 5A) the part would not allow more than 3A.

I have to change the Source PDO3 to: 

a) Fixed source (not variable)

b) Peak current to 200%

If BOTh are not done, I can't get more than 3A.

We selected variable because we may run into conditions which 20V is not sustainable.

I measured the current and do not see anything near 5A, so I don't know why the Peak Current needs more buffer.

Simply changing t he Maximum Current does not work.

Do you have any suggestions?

Hello,

Good catch, this advertisement matters because in VCONN needs 4.75-5.5V, and an active cable capable of 5A relies on VCONN for power in order to advertise its capabilities. 

You may be having inrush current issues, where the sink goes to pull 5A, and the inrush current from your power supply is tripping the PD controllers OCP. Did you check out the app note I linked above on overcurrent protection? 

Also, as a USB power source offering 100W, the PD spec requires the source to supply and advertise 5,9,15, and 20V. 

Thanks,

Emma

More mysterious information.

Most of this work was done on the V4.03 of the TI tool.

I decided to try and use V6.1.1

V6.1 would still not support the 5A contract UNTIL I changed the Firmware Base Image to match the V4.03

The one that V6.1.1 normally used was TPS65987_88_F707_10_08.bin

 The one that V4.03 used (and worked) was TPS65987_88_F707_10_08.bin

I guess I'm a little confused.

The ONLY thing I changed is the Firmware Base Image file revision.

Aren't these provided by TI?  Not generated by the user?

If I use the ...10_08.bin it doesn't provide 5A, if I use the ...10_04.bin it does provide 5A.

So I think I have something I can make work, my questions are:

a) Do I need to designate the power as 'Variable 18-20V" or can I leave it as "Fixed 20V"?

a1) I don't see any current surges, why do I need to ALSO provide current to "200%"?

b) why does the Firmware Base Image make a difference? 

b1) is it important that I need to use an 'older' base image file

Hello,

a) You can leave the source capability as fixed 20V here. 

a1) I would scope the line to see if you are missing any quick transient current spikes forcing you to need 200% peak current. Ensure that you are looking at a high enough resolution.

b) There are differences in the firmware base images, which is why they have different file names. However I would double check that your configuration settings are the same between the two GUIs. Can you both firmware base images in GUI 6.1.1 and let me know the results?

Thanks,

Emma

I'm not sure how to 'confirm the base image'.  I can explain what I did, though.

First I loaded my project. Then I loaded that project into my board.

It did not allow delivery of  current  > 3A.

When I simply changed the "FIrmware Base Image" on the General Settings page and re-flashed the entire image to my board, it was able to deliver the 5A that was advertised.

To be clear, I did not alter the project at all between attempts, just the file used for the Firmware Base Image.