In  FX3 Release note, for I2C, 5 ms delay is required after write operation,

but it cause the fatal problem in performance, I think.

I guess this is because the I2C hardware runs in background, and

I2C API (CyU3PI2cTransmitBytes, etc) returns without waiting for the 'done' of hardware.

Is this idea right? and if it is right, can I get the done status of the I2C hardware?

Experimentally, I tried to shorten this delay as equal as the transmit time

(that is calculated with transmit bytes and clock rate) and it succeeded.

And when this delay is more shorter, I2C waveform is broken.

So, this delay-time calculation may be useful for workaround,

but I think it shall fail if the slave device use clock-stretching.

That is due to the write cycle that most EEPROMs have.

We can keep retrying the transfer till it succeeds, the EEPROM datasheets don't have anything preventing this approach but we haven't done extensive testing of this approach yet. We'll most probably take a deeper look at it in future release.

Regards,

Anand

I apologize, I was misunderstanding.

I have used CyU3PI2cDeInit() and CyU3PI2cInit() immediately after CyU3PTransmitBytes(), and

it caused I2C bus violation.

In calling only CyU3PTransmitBytes() continuously, it works right.

For 5 ms wait described in release note, I understood it's required for EEPROM write busy cycle.

I found that I2C bus violation case when continuously calling of CyU3PI2cTransmitBytes()

with small interval.

I attached a waveform in fatal case.

But  the phenomenon is not stable (sometimes another waveform appears),

I think it depends on access pattern, timing, etc.

Inserting a large delay after transmit prevents this problem, but I don't know the best number of duration.

Attached waveform appeared in these sequence:

(1) call CyU3PTransmitBytes() with two data bytes.

     Slave address and first data byte are stored in the preamble.

     (length of preamble is 2, byteCount argument is 1)

     This calling returns success (but, at last byte, slave device sends NAK).

(2) wait 16 us with CyU3PBusyWait().

(3) transmit two dara bytes, such as (1).

Hi Kudoh,

does your I2C-slave use clock-stretching to signal that it's not yet ready for another byte to receive? The waveform looks like that since at the second transmission the clock keeps low after acknowledge of 2nd byte...

Regards,

Robert

Hi.

In this case, the slave device does not use clock-stretching.

I guess FX3 I2C hardware is confusing.

I attached another waveform. In this case, I transmit same sequence with no wait.

(slaveAddress + 1 byte data for preamble,  1 byte for additional data, API call 2 times).

By the way, I guess  CyU3PTransmitBytes() transmits the preamble data synchronously, but

for the additional data transmitting, this API runs asynchronously and

at the time of API returns, I2C transmitting is running in background.

This means that  this API can not check ACK/NAK after preamble, and

returns success even if the slave device send NAK.

Is this true?

Hi,

I found out that I2C-transmit API returns success even if slave sent a NAK if you transmit just 1 databyte (so 3rd parameter is 1). If you send 2 or more bytes the API seems to work properly. The support team told me it's a bug and it will be fixed with next patch/release.

Regards!

Hi.

I tested CyU3PTransmitBytes() with setting 3rd parameter to 2 or larger,

and I confirmed it works correctly with no wait.

Thanks.