Other Parts Discussed in Thread: TPD6S300
Hi,
Briefly: I am integrating USB-C for the first time in one of our products. I have chosen to use a TI solution with the TPS65987D PD controller and the TPD6S300 port protector. I have purchased one of your USB-C-PD-DUO-EVM modules for the purpose of debugging my own implementation which I am programming with the officially supported Total Phase Aardvark tool and code generated with your ‘Application Customization Tool’ GUI version 6.1.1. Unfortunately, I am having a few issues reliably programming and debugging both the evaluation module and my own solution. I therefore have a couple of questions that I would appreciate if anyone has an answer to.
My symptoms on the USB-C-PD-DUO-EVM, using the programming header and the Aardvark, are:
1) I can be in either of two states:
1) Programming succeeds and passes readback verification however the configuration does not appear to change (even after power cycling) and ‘Application Customization Tool’ -> ‘Boot Flags’ -> ‘SPI Flash Present’ -> ‘Value’ reads ‘False’.
2) Programming fails with a readback verification error however the configuration still does not change and ‘Application Customization Tool’ -> ‘Boot Flags’ -> ‘SPI Flash Present’ -> ‘Value’ reads ‘True’.
Note: The configuration appears to change if I ‘Export Settings to Device RAM’ after a successful program. In this state I can plug in a device and a voltage of around 900mA appears however negotiation / data does not appear on the on the line. If I program the same USB-C-PD-DUO-EVM through the USB micro and plug in a USB-C device I see the negotiation on the CC line and I can get 20V on the Vbus.
My observations:
Looking at the USB-C-PD-DUO-EVM User's Guide, the schematic suggests that both the TPS65987D and the SPI flash are both slave devices (‘SPI_CSZ_SOURCE’ an input), leaving the programmer as a master device when connected. This is also supported by the ‘Application Customization Tool’ debug mode with ‘GPIO11’ Direction reading back the value ‘0x0’ in the ‘GPIO Status Register’. The implications of this are that when programming it is unclear where any returning data from the MISO has come from as both chips will be selected as they share a common SS. Also, when the programmer is removed, there will be two slave configured devices with nothing initiating the communication, there does not appear to be a second SS line configurable in the ‘Configuration Registers’ -> ‘I/O Config’ that could be used as an output SS.
When considering the TPS65987D SPI as a master device it contradicts the schematic but allows the TPS65987D to request the config at boot up. When programming however there are now two Master devices controlling a single slave device. I could tristate my Aardvark programming connector to avoid conflict however the TPS65987D will be in the dark, writing without response. There is no reset line connected to the programming connector either which might be a way to resolve the conflict. Looking at the SS line with an oscilloscope when powered on, the TPS65987D SS line behaves as an output and appears to fetch the configuration from the SPI flash device.
Looking at the USB-C-PD-DUO-EVM users guide, and confirmed by a continuity test on the pins, the Programming header J203 utilizes ‘SPI_CSZ_SOURCE’ making it impossible to program the SPI flash for the SNK board without breaking the connector apart and connecting to ‘SPI CS HEADER’ J202 pin 1.
Question: Is the TPS65987D operating as an SPI master, if so, is there a suggested arrangement, perhaps used with the onboard FTDI chip that avoids conflict between two masters when the Aardvark connected? When I am using the Aardvark should the I2C1 be on a separate connector to the SPI so they are not on the programming header at the same time? To make my programming arrangement more robust for my test setup I would prefer to have all the cables feeding into a single connector, is there a known modification to get J203 to program the SNK board PD? (The layer views further down in the user guide are very difficult to use to work out which track to cut / vias to solder to without signal labeling).
2) My symptom is not being able to read the SNK board registers using the Aardvark with the ‘Application Customization Tool’.
My observations:
I can only see the I2C address of the SRC board when scanning with the Aardvark connected to either J2 or J203 of the USB-C-PD-DUO-EVM. Using the FTDI and a USB micro B cable I can see both I2C addresses however I lose connection in debug when I have plugged in a USB-C DFP / UFP and the PD negotiation has taken place. (I think this may be due to some logic contention, possibly due to an incorrect register setting, as in this state the Voltage LEDs appear to randomly flicker).
Question: Is there a known issue / fix to connecting the debugger to the SNK board with the Aardvark? (Searching this help forum I am aware of various driver issues however I have an FTDI cable that I have tried with similar results and I am fairly confident that it's not a driver issue as I can communicate with the SRC board). Are there any known configurations unsupported by the USB-C-PD-DUO-EVM? (My custom application does not use the buttons on the SNK board, using only a single device with 0 virtual devices).
Any contribution appreciated.
Warmest regards.
Laurence
