I2C write after read with multi-byte addresses

[nnik]

I'm using RT595 evk to talk over I2C to a custom chip which has 4-byte register addresses. I'd chosen the I3C0 bus and decided to use the driver provided in the SDK. Specifically, the function that's doing the transaction is 

I3C_MasterTransferBlocking

which seems to do these steps in theory:

1. Start

2. Setup for I2C write.

3. Write subaddress (register address on the slave), which can be up to 4 bytes.

4. Repeated start

5. Setup for I2C read.

6. Read data.

7. Stop

However, hooking up a logic analyzer, I'm seeing a different behavior on the I2C bus that is:

1. Start

2. Setup for I2C write.

3. Write only the Most significant byte of the subaddress.

After this step, I'm not seeing the next significant byte, but the one after. My slave is not ACKing that and the bus enters a stuck state at that point.

Do you have any recommendations on this API or using a different one?

[nnik]

Thanks Omar. The behavior I mentioned is with the subAddressSize set to 4.

[Omar_Anguiano]

Hello

Is this issue also present when using I2C bus from the RT500 side?  This test is to check if the issue is on the I3C bus or in the follower(slave) device.
It will be helpful to check if the problem persists by calling I3C_MasterTransferNonBlocking().

If you have more questions do not hesitate to ask me.
Best regards,
Omar

[nnik]

Hey Omar,

Not sure what you meant by this:

Is this issue also present when using I2C bus from the RT500 side? 

From the scope shots, it looks like an issue on the master side- Out of the 4 byte sub address. Using an example 0x06040270, I was only seeing the intermittent bytes 06 and 02 on the bus. The slave was ACKing 06, but it didn't ack 02- which is likely a different problem on the slave.

One thing which I tried was to write a single byte at a time to the registers  MWDATAH and MWDATAHE instead of MWDATAB and MWDATABE respectively. This seems to work, but it's not reliable, and I don't think it's supposed to work. I also tried writing 2 bytes at a time to the same MWDATAH+ registers, which didn't work.

It seems like the I3C_MasterTransferBlocking is doing the right thing up until writing to the FIFO. I'll try I3C_MasterTransferNonBlocking as well.

[Omar_Anguiano]

This bug is not present in I2C, for that reason I suggest you test your follower(slave) in the RT500 I2C bus.
RT500 I3C bus has some limitations regarding I2C mode; this restriction is when you when to use Multi-Master in I2C, and this is because the I3C use clock in push-pull, not open drain, this to support fast modes and fast most plus. 

Multi-master in i2c requires clock-stretching. It works by using the open-drain clock and data so that a master can back off if another master is holding the clock low when it released it high (with some nasty timing issues to allow for the pullup to work).

Is it possible to attach the communication scopes to have a better picture of how the communication is made?

If you have more questions do not hesitate to ask me.
Best regards,
Omar

[nnik]

Adding a note that I'm observing the same behavior with I3C_MasterTransferNonBlocking.

[Omar_Anguiano]

Hello
Hope you are well.
Please set "subaddressSize" to 4 in the variable type i3c_master_transfer_t before calling I3C_MasterTransferBlocking().

If you have more questions do not hesitate to ask me.
Best regards,
Omar