USB 8451 I2C acknowledge bit problem

[ggaryt]

Hello,

I'm in the middle of developing a I2C interface for a Xilinx Vertex-5 evaluation board.  This is a standard Philips I2C interface and I'm able to view the SCL and SDA lines and everything looks like it should be working but I'm not getting the acknowledge returned on the SDA line. 

We have flags output on other pins and the acknowledge is working but it seem the SDA line isn't releasing the line to allow the acknowledge to go low. 

I have tired the write program examples that came with 8.6 but they are for a serial PROM and I don't believe serial PROM return an acknowledge during programming.  I have also tried the example from the "Using I2C with LabVIEW and the USB-8451" and even though all the clocks and data looks good at the proper pins the acknowledge bit stay high. 

The Discussion Forum has a similar question about acknowledge on a "smbus_Read_Block" (11-9-06) where "newbieLBW" ask about this for a block read.  I have tried that example and created it for a write but I'm still not getting a acknowledge bit to go low.

I have attached my I2C development vi that is just to prove functionality. And the write routine is in case loop 2.

[Mr.F · Accepted solution]

Hi,

Are you getting an error? What is the program doing that you don’t expect it to?

[ggaryt]

Hello Matt,

Thanks for taking the time to look this over.  I would like to send you the latest version I have on the write, I have reduced it down to just writing the address and seeing if I get a ack.  The loop of interest on still # 2 and as you'll see it is very basic.  I'm receiving an error right after the run script and the error is no ack.  Looking at the waveform the ack bit seem it is being driven high since the rising edge is sharp like the address bit, which makes me thing I'm not releasing the SDA line.  I'm trying to get a good picture from our O-scope but the LeCroy is having some problems.  Please take a look at the current attachment and let me know if you see anything I'm missing.

Happiest of Holiday to you.

Gary Tyrna

Tahoe RF Semiconductor, Inc.

[Mr.F]

Have you verified that the control byte is what the Xilinx board is expecting? Also it might be helpful if for trouble shooting purposes you created a straight line of code and post any error messages you received and where.

[ggaryt]

Matt,

Yes we have verified that the Xilinx is getting the information it needs and it returning a acknowledge pulse on the 9th SCL clock pulse.  I see this because we brought out the signal to a extra pin on the connector along with start and stop flags to make sure things inside the Xilinx were seeing the input properly.  When I run this program in a debug mode and highlight the data path the only errors I received is from the 'run script' function when the 8451 tried to write the address.

Quick question for you.  I had mention a discussion forum question about the acknowledge bit on a smbus which is quite like the I2C interface.  In that

example the read multi-byte function starts with a create script, script clock rate,script issue start, address+write, script write, then another script issue

start, then it go on to another address+write.  My question is, it seem to me that nothing happens on the I2C SDA line until your data enters the 'run script'

and I'm not seeing why they have two starts without a run.  I have tried to duplicate the multi read front section to see what it does but mine doesn't seem

to run in as much as the SDA line never starts unless I have the run script in the read path.  My understanding is that the 'script start and address+write are

just setup for the run script and without the run script nothing executes.  Yes or No?

I want to thank you for taking the time to view this question I have.  The purpose for this interface is a future chip we are designing and we are using the I2C for reading and writing control registers within the chip.  I need to get the development platform working before I move onto the full interface and all the registers are 32 bits wide so I'm going to have to do all multi-byte reads and writes.

I hope I have answer some of your question and will be looking forward to any information you can pass along.  I'm going to be out of the office until the 28th but I'll keep and eye on this forum from home where I'll be working on the full interface design but without the read and writes for now.

Merry Christmas and the Happiest of New Years to you and your family!

Gary Tyrna

Tahoe RF Semiconductor, Inc.

[Mr.F]

Hi Gary,

Just to eliminate any confusion in the transfer can you post a screen shot of the error message you receive? Also, you mentioned that you might be able to obtain an O-scope capture; can you post that as well? Are you sure you have right value for your external pull up resistor, they are usually 2.2k or 4.7k?

[GSJT]

Hi Matt,

I'll post all this data for you including the screen shot of the error message and the SCL and SDA line data to give you a better idea of what is going on.  As for the pull up they are 10K I'll change them to 4.7K if you believe this would help the issue.

I'm currently at home on vacation until Monday the 28th.  So if we can put this on hold until then I'll get that data to you on Monday.

Thanks Again and Merry Christmas

Gary Tyrna

Tahoe RF Semiconductor. Inc.

[ggaryt]

Hello Matt,

Here is the information you asked for about the error message and the timing off the SDA & SCL lines which are channels 1 & 2.  Channels 3 & 4 are the acknowledge bit, channel 3 is the acknowledge bit that is suppose to be pulling down the line and channel 4 is it invert.  Let me know if there is anything else you would like to see.

Gary Tyrna

Tahoe RF Semiconductor, Inc.

[Mr.F]

Hi Gary,

Can you post a SPY capture of this event as well? I’d like to compare what being physically transferred on the bus with what the driver sees.

[ggaryt]

Hi Matt,

Here is the NI SPY capture I have on a initialization, reset, and then a write.  I hope this will help you out.

Happy New Years,

Gary Tyrna

Tahoe RF Semiconductor, Inc.