TI E2E Community
DLP & MEMS
New DLP Applications & Technology Forum
I'm using a USB-to-gpio Adapter to interface with the I2C signals on the 24 pin port on the side of a Pico 2 DLP projector.
Reference GUIs and Libraries for Eval and Usage of the USB Inteface Adapter (zip 272 KB)
I extracted the files and opened the file USB SAA GUI.exe which opens as the USB Adapter EVM.
I followed the instructions for connecting the Adapter. The green LED lights up when the adapter is connected
to the USB port. Then I turn on power to the Pico 2.
In the text boxes in the I2C section 36 is entered as the device address,
12 entered as the command number and 00 entered as the data.
Clicking on Send results in "ERROR". No matter what numbers are entered in the boxes,
the always result is always "ERROR".
This command should turn the green LED off. The pico 2 display output does not change.
A line at the bottom of the Adapter EVM screen says "adapter not attached"
1) Is it possible the USB Adapter is not communicating with the Pico 2?
2) Is there any way to set the I2C baud rate or is this automatically set internally by interaction between the two devices?
3) Is there an I2C device that could be used to test the I2C capability of the USB adapter?
4) Is there any other possibility that might be the problem?
Try using 0x1b for the Pico Kit v2 I2C address. I don't know if that will work, but some I2C programs shift or mask the I2C address in strange ways. The actual I2C address of the Pico Kit is 0x36.
I tried using 0x1b as the address. I have experimented with a lot of different numbers for the address and for the data and always receive an error.
Also, a note at the bottom of the page says "Adapter not attached"
Is there any way to just buy a working system?
Or someone who would put the projector and USB adapter together in working condition?
Yes, I have the User's Guide.
The Guide says that the baud rate is set at 100 kHz and the pullup resistors are set at 2.2k by default.
Three pins on the Pico 2 are connected to the USB Adapter as follows:
DLP 24 Pin Connector USB Adapter 10 Pin
Blue wire pin 22, AX_SDA pin 10, I2C data
Yellow wire pin 23, AX_SCL pin 9, I2C clock
White wire pin 24, Ground pin 6, ground
Pins 22 and 23 are pulled high. There are no signals on either pin 22 or 23.
If you can not see any signals on the AX_SDA and AX_SCL when you write from the PC (through the adapter), then the adapter and/or software is not sending signals. Pay particular attention to the AX_SCL - whenever the PC is trying to send data, it will put a clock on this line.
If you are not seeing any clock signal when you think that you should be sending data, then the adapter is not driving the signals. Also, watch these signals when you power up the Pico Kit v2. It may "talk" on these lines during boot up.
Let me explain a little about I2C communication. I2C utilizes open-drain outputs, meaning the drivers on the data (SDA) and clock (SCL) signals only drive low. An external pull-up brings these signals high when they are not driven low. If these signals are not driven, you should see them high. When the USB-I2C Adapter (the master) initiates a transaction, it will drive the data signal low while not driving the clock signal. This creates a start condition. Then, the adapter will drive the clock signal low and then stop driving the clock signal, repating this over and over again to create a clock with 100KHz frequency. At the same time, the data line will be driven low as needed to send the slave address and read or write command. After the slave address is sent by the master, the slave responds with an acknowledge by driving SDA low on the next clock cycle. If you are seeing a communication error, the slave is not responding with an acknowledge. Have you probed the signals in the DLP connector to make sure the adapter is toggling the SCL and SDA line?
So a typical command would be: S 36 04 00 00 00 00 P. This command sets the Input source to be the RGB interface by writing to sub-address 0x04, the values 0x00000000, where
S = start (SDA low with SCL high)
0x36 = 7-bit slave address 0x1B, appended with a write command (1), so this is (0x1B<<1) + 0x1 = 0x36
04 = sub-addres 0x04
00 00 00 00 = data of all zero
P = stop command, SCL high with SDA going high
So when you setup the transfer in the USB Adapter application, set the device address to 0x1B, select I2C Write, set CMD = 04, Data = 00000000, then press send. You should see an ACK.
When you enter the slave address in the device address field, you might need to enter a decimal address, and not a hex number. Thus, instead of entering 0x1b, enter 27.
The SDA line toggles when the Pico 2 is powered up. After trying this dozens of times,
I only saw the toggling once.
Other than this, the SCL and SDA lines always remain high and never toggle.
The device address cannot contain letter characters so it has to be decimal.
All device addresses that I have tested result in error. So far, I have tested
device addresses 24, 25, 27, 36, 37, 39, 54, 55, 58, 59.
The USB adapter does not toggle either the clock or data lines
This is true regardless of whether an I2C device is connected to the USB adapter.
One question: should the USB adapter toggle the SCL or SDA lines even if nothing is attached?
Yes, the USB adapter should toggle the SCL and SDA lines even when nothing is attached. It will look for an acknowledge once a command is sent. The acknowledge will be sent by the Pico. The Pico will not respond until it sees a command with its slave address. On power=up, these lines should show as grounded and then pulled high once the supplies come up.
If you are not seeing the lines toggling when nothing is attached, something else is causing the problem: USB driver conflict, problem in the connections, too strong of a pullup, etc.
I wondered if Alan found a solution to his problem as I am having exactly the same issue...
I am trying to communicate to a bq78pl116 by sending SMBUS commands from the .NET app "USB SAA GUI.exe". found in sllc288.zip
This .NET program was compiled in 2006 and I am running windows 7. The program does not appear to connect to the USB-GPIO Adapter.
I have tried uploading two firmwares to the USB interface (PM and BQ types) and reprogrammed the original shipped firmware...
Can anyone assist?
PS BqWizard works fine but I need to test SMBUS commands/data as I am having problems interfacing with a uCu.
Were you able to find a solution to your problem? I have the same problem: USB-GPIO adapter not communicating under Windows 7 (64bit).
I'm having the exact same problem with Vista & Windows 7 (64bit). The standard USB plug-n-play drivers are NOT effective with 64-bit Operating Systems. I'm looking for 64-bit drivers drivers that will communicate correctly with the USB Interface Adapter, just like Vista & Windows 7 (32 bit) drivers do.
If anyone knows where 64-bit drivers area, please let us, the programming community, know.
Anthony, Markus, Roy,
I believe that all of you are using the usb-to-gpio adapter from http://www.ti.com/tool/USB-to-gpio. I suggest that if you have not solved the 64-bit driver issues that you cantact TI Technical Support (http://www.ti.com/general/docs/dsnsuprt.tsp). Also, there may be another E2E group which is more directly connected with this product, but I am not sure which one it is. It looks like it is "Power Management" which is responsible for this product now.
Also, Google for something related and see if anyone else on the internet has grappled with the same issue.
I am using a different usb adapter for i2c communication, and am having some issues. Without the pico projector connected, the adapter is sending the correct signals and driving the SCL line at 100kHz and 3.3V (the adaptor has 4.7k pull-up resistors; though, I've also tried a Raspberry Pi with 1.8k pull-ups and get similar results). However, when I connect the projector through the AUX connection, I don't see any information on the SDA or SCL lines anymore. In an earlier post, you mentioned checking the voltage levels on the SDA and SCL lines without anything connected. I've done this, and get 3.3V on the SDA line, but only 120mV on the SCL line. I'd appreciate any information on how to troubleshoot this further.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.