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

 

[canadianJaouk]

Hi,

I use the I2C from open core on most of my projects at work, I have
never noticed such behavior.

I assume your sequence of operation looks like this:

write slave address+w bit
write register address
write slave addres+r bit
read

What I2C core register (cr, crc, tx, etc...) values do you write with
each transaction, I can compare with what I am doing...

Also, I am using the inta (interrupt) to tell me when a transaction is
over, not the TIP signal.

-Jake

On Nov 15, 5:33 pm, markus_1...@yahoo.com wrote:

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

 

Hi Jake,

Thanks for your reply. I appreciate it.

When you said you used inta, did you mean that you used the wb_inta_o
(i.e. wishbone inta output) or the Interrupt Flag from the Status
Register?

In my design I created a state machine to execute the entire sequence
for the read function. It looks like our algorithm is similar. I've
decided to refine the detail for the algorithm in order to make sure
that I've done this correctly. Here's my algorithm:

write slave address and write bit to TXR register, then wait for
wb_ack_o.
write STA and WR to the CR register, then wait for wb_ack_o.
wait for ~TIP and ~RxACK in the SR register.

write register address to TXR register, then wait for wb_ack_o.
write WR to the CR register, then wait for wb_ack_o.
wait for ~TIP and ~RxACK in the SR register.

write slave address and read bit to TXR register, then wait for
wb_ack_o.
write STA and WR to the CR register, then wait for wb_ack_o.
wait for ~TIP and ~RxACK in the SR register.

write RD to the CR register to indicate a read, then wait for wb_ack_o.
wait for ~TIP in the SR register.
repeat this until 2nd to last read.

for the last read:
write STO, RD, and ACK to CR register, then wait for wb_ack_o.
wait for ~TIP in the SR register.

Please let me know if you find anything fishy (i.e. whether my
algorithm inadvertently caused clock stretching to be disabled). I'll
try your suggestion with inta as well. Thanks.

-Markus


canadianJaouk wrote:

Hi,

I use the I2C from open core on most of my projects at work, I have
never noticed such behavior.

I assume your sequence of operation looks like this:

write slave address+w bit
write register address
write slave addres+r bit
read

What I2C core register (cr, crc, tx, etc...) values do you write with
each transaction, I can compare with what I am doing...

Also, I am using the inta (interrupt) to tell me when a transaction is
over, not the TIP signal.

-Jake

On Nov 15, 5:33 pm, markus_1...@yahoo.com wrote:
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