I2C Bulk Reads with unexpected STOP condition?

General
1

Hi Ian, as far as I know for bulk/sequential I2C reads STOP command is only at the end of all packets … I see it here after the first packet !
Command used: {r:3
I2C START
RX: 0x00 ACK (I2C timeout)0x00 ACK (I2C timeout)0x00 ACK (I2C timeout)

Last packet does not even have 8 clock pulses …

I2C_Bulk_Reads
I2C_Bulk_Reads1485×262 20.4 KB

1 Like
2

I believe this is also due to the SDK I2C PIO program and the way it halts on bus errors. The STOPs are the peripheral recovering from the error state.

Also, it forces some conventions such as sending the address before reading. For example I think it expects you to send at least the address before attempting to read.

Finally, the current firmware also requires that the I2C command ends with a STOP to properly predict when to NACK the last read byte.

try [0x00 r:3]

Still, I see a few things that look like bugs:

  • Those bytes are spaced out way to far. I believe this is the timeout. However I don’t know what is timing out, because reads should not need an ACK. It may be related to not beginning with a write.
  • The operation should halt after a bus error, not keep reading.
  • The compiler should throw an error about lack of first write, as well as lack of stop. These need to be implemented in a per-protocol pre-compiler in the lower levels and I have not gotten to that yet.