USB-to-gpio error

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.

Pascal

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.

Alan,

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,

Pascal

Alan,

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.

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...

No joy.

Can anyone assist?

PS BqWizard works fine but I need to test SMBUS commands/data as I am having problems interfacing with a uCu.

Thanks again

Anthony

Anthony,

Were you able to find a solution to your problem?  I have the same problem: USB-GPIO adapter not communicating under Windows 7 (64bit).

Marius,

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.

Thanks!

Roy

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.

Best regards,

Pascal

Pascal,

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.

Regards,
Kevin 

Kevin,

Is this an older Pico Kit v2? I suspect that the problem is that there is a resistor which should have not been populated, but is on your board. It is R12. You can get the schematics for the Pico Kit v2 from here: http://www.digikey.com/pico (look in the lower right corner - "Related Pico 2 Documents".

On the MAIN BOARD-12142009.pdf schematic look for IC2-EN2. You will find U64. On pin 5 you will see R12, a 10K resistor which pulls the pin to ground. This resistor should be removed. On the main board (you will have to take the Pico Kit v2 apart) R12 (and U64) are located at the pin 59/60 end of J30. R12 is the nearest to the board edge of the 3 resistors at this end of J30. If R12 is there, it should be (very carefully) removed.

If R12 is not there, then there is some other reason that the I2C is not working.

Pascal,

Thanks for responding.  Unfortunately, R12 wasn't there, so something else must be wrong.  We recently bought the Pico Kit from digikey.

Pascale,

I didn't resolve the issue with that unit, but we've purchased another one and it works well.  Now I am trying to solve the tearing video issue mentioned in this post: http://e2e.ti.com/support/dlp__mems_micro-electro-mechanical_systems/f/94/p/160019/835260.aspx#835260

Anyone have  a good method for encoding a 60Hz video acceptable to the pico projector given a series of TIFF images? (playing off Angstrom on the Beagleboard-XM)

Thanks,
Kevin