Problems with Opencores' I2C "READ" function

Hello,

I am wondering if any of you have encountered a problem in which the Opencores' I2C "READ" function failed. The problem I am seeing is that when prior to the data read from the slave device, the master doesn't write the 7-bits device address and a logic HIGH (to indicate a read), specifically, the master failed to send the last logic HIGH to indicate a read. As a result the slave thinks a write operation was sent as opposed to a read operation. I am wondering if any of you have encountered something similar to this.

In order to initiate a read sequence, I first sent a write to the slave, followed by the memory address location of the slave's register, then I sent the read instruction. I checked whether wb_ack_o pin is asserted and that the TIP signal have been negated before proceeding from one command to another. Is there something else that I need to do prior to executing from one command to another (i.e. more pauses?)? Or do I need to turn on clock stretching? I thought the clock stretching is supported automatically.

I used Virtex-II Pro to implement the I2C interface. The device is communicating to a Finisar XFP. I've seen this problem occuring specifically to Finisar XFPs. In addition, I have one board that exhibit this issue regardless of the XFPs used. My goal is trying to isolate whether this is an XFP issue or how I implement the I2C cores.

Any comments and suggestions are welcomed.

Thanks,

-M

Reply to
markus
Loading thread data ...

I've successfully used the core on 2 different designs...

Here's the sequence I use to read a byte...

// device address and dummy write WR(TXR,{dev,0}) WR(CR,STA|WR) wait for not tip and ack // memory address WR(TXR,addr) WR(CR,WR) wait for not tip and ack // start reading WR(TXR,{dev,1}) WR(CR,STA|WR) wait for not tip and ack WR(CR,RD|ACK|STO) wait for not tip RD(RXR)

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, 
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266
Reply to
Mark McDougall

Hi Mark,

Thanks for your comment.

Is the waiting for TIP and ack an "and" function i.e. both must be deasserted before proceeding to the next step? Is the ack you are referring to is the ack from Status Register bit 7 or from wb_ack_o?

Thanks,

-M

Mark McDougall wrote:

Reply to
markus

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.