• TI Thinks Resolved

USB-to-gpio error

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.



I downloaded

         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?



  • Alan,

    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.


    Best regards,


  • In reply to Pascal DLP:

    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? 

  • In reply to Alan Jackson:

    Alan, Yes, it is possible that the Pico Kit and the I2C adapter are not communicating. The baud rate is NOT negotiated, but must be set. It should be set on the adapter side to 100kHz. I do not have one of the USB-to-I2C adapter modules which you are using. Do you have it configured for I2C at 100kHz? It appears that there are several parameters which can be configured on the adapter module. Have you measured the voltage at the pins which you are connecting to on the Pico Kit (J113 pins 22-AX_SDA, 23 AX_SCL)? These pins are pulled up to 3.3V by 2.2k resistors. So, when you probe them (nothing connected, Pico kit turned on) there should be about 3.3V on these pins. Can you see the I2C signals being toggled by the adapter (probe with oscilloscope)? These are some suggestions. Pascal

    Best regards,


  • In reply to Pascal DLP:

    Alan, Do you have the USB Interface Adapter Evaluation Module User's Guide (SLLU093)? This should help with using the USB-I2C adapter. Pascal

    Best regards,


  • In reply to Pascal DLP:


    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.


  • In reply to Alan Jackson:


    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.

    Best regards,


    Best regards,


  • In reply to Alan Jackson:



    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. 



  • In reply to Alan Jackson:

    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.

  • In reply to PedroGelabert:

    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?



  • In reply to Alan Jackson:

    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.