TPS65987D: PDO swap

Could you please attach the PJT you are using as well?

2425.TPS65987.pjt

I have not been able to test this file.  On a TPS65987EVM, it will act like it is sort of working, but in debug mode, sometimes registers will not remain set or produce unexpected results.  It isn’t DOA, just too flaky to be useful.  These should be the settings I'm writing over I2C on boot.

Thanks.

Thanks for the PJT. Can you help clarify a few things:

1. The PJT attached is different than the screenshot you have above. Is that a screenshot of the debug mode after rewriting the PJT config via I2C commands?
2. The PJT shows PP2 is used for both PDO1 and PDO2. The PD logs is issuing a hard reset because the PD is not ramping up the PDO2 (9V) on VBUS. Can you confirm that the PD is not getting to 9V?

1. Sorry, I missed resetting that when trying it on the EVM. Corrected .pjt attached.
  PP_HV1 = 5V = PDO0
  PP_HV2 = 12V = PDO1
2. Correct.  The output is 5V, drop, repeat.  It is not switching from PP_HV1 to PP_HV2, but dropping instead.

TPS65987b.pjt

Sam,

Check if the following are happening in the PP_HV2 path TPS65987D :

Can you rule out these issues are not happening on the PP_HV2 input?

As it is not trying to switch to PDO1, the only thing that would apply is UVP. But, there is the correct voltage on the pin.

Interestingly, I was trying the alternate approach using GPIO to adjust the supply voltage.  That approach is not switching to PDO1 either. The log shows PDO1 is advertised and selected.

I would try on the EVM, but that is not behaving as expected.

Thanks.

Every time I enter poll mode, it goes nuts.  I'm trying to reflash, without success.  What is the correct image for TPS65987EVM?
Thanks.

That looks like the correct image. Just to be sure on the EVM in order to properyl flash the device, go to Binary -> Flash from Current Project -> Ok.

Once the device is erased, rewritten, and verified unplug all power from the EVM and replug the power. It should start up.

Verify you can communicate with the device by clicking Adapter -> Configure I2C/SPI Adapter Settings -> Sweep I2C address range for device response.

The I2C address sweep should take less than 30 seconds. If it gets hung up it means the USB connection to the EVM is having issues. Restart the GUI, unplug the USB cable and retry.

Yes.  In debug mode, often I set something, then it is rewritten to the previous value.  Other times, debug just reports everything with unknown values.  Is it normally very flaky?

Thanks.

No normally it is not. When in debug mode does it show connected in green at the top right?

On screen, yes, usually green.  Board has blue and green power, and a white micro USB.

Sometimes, it cannot maintain a connection.

I just reflashed again, now when I update a box, I get:

Try restarting the GUI. Also, read register 0x3 'Mode' register.

After GUI reboot

After power/USB cycle

But still no longer accepts GUI value changes and soon returns to Mode = 0xffffffff.

I suspect there may be an issue with reading back/writing to the EVM via USB communication. I do not think the EVM is having issues.

Back to the issue for now. If the PP_HV2 is verified to always be providing 9V (or 12V?). Then please check via oscilloscope that VBUS2 output of the PD is receiving the correct voltage.

The EVM no longer has anything on VBUS.  The EVM certainly is not useful when it loses its mind in a minute.

On our board, when it attempts to switch from PDO0 on PP_HV1 to PDO1 on PP_HV2, it hard resets.  The scope does not have a transient increase in voltage before dropping.

That’s why I was trying the EVM again, which won’t stay alive long enough for anything to happen.

If there is nothing on VBUS in the EVM I would suspect a component is blown or damaged. I would recommend checking all components in the EVM schematic on the VBUS wire

slvc770

As there is issue writing/reading registers, I think the EVM is dead.

Agreed. do you happen to have another board (custom or EVM) with a TPS65987? If so, you should be able to load the image and read the registers via I2C

When configured by the Application Customization Tool - Export to Device RAM, things seem to work properly.

When configured by the host over I2C, we seem to be down to GPIOoe not being properly set. Reading back the Raw View, reg 0x5C, byte 17 appears to not be accepted. Everything else looks ok. How to debug this?

Alternatively, send the GPoe command from the Application Customization Tool, and everything works.
Read register 0x5c and it looks unchanged by the GPoe command.
I didn’t see anything in the TRM on where to set CmdX and DataX. How to do this from the host?

I’m guessing there is some subtle thing Application Customization Tool does. For this level of debug, I think it might be easier to set up a remote desktop session. I can direct email you the .pjt.

Thanks.