We are seeing the issue on I2C bus where the sensor communication is failing. I2C bus error.
There are many functions in driver like SI1133_paramSet() which are calling I2C read() back to back. These calls are failing. If we add some delay between calls it works fine. Finally we resorted to add delay in the I2C_Read() and I2C_Write() functions in the beginning. It resolved the issue.
I think, si1133 has some issue if host MCU runs fast and sends commands quickly one after the other.
Did you capture the I2C transaction using a scope? That can tell you what happened between 2 I2C transactions that caused the failure.
What's the I2C clock frequency? The capture seems to be 2 I2C reads back to back and the second one failed which holds the SDA line low? Do you have a capture with delay as a comparison?
I2C Clock frequency is 100 kHz.
If I add delay the next I2C command works fine and so do all the commands as our firmware reads the sensor at regular intervals. So, I cannot take the screenshot after adding a delay because it would update the screen regularly at every second.
From the capture, SDA stuck low at the end because the sensor is expecting a NACK at the end of a single READ sequence (See Figure 3.8 in the datasheet). Can you check your I2C driver code and see if it's missing the NACK?
I understand. Note that, low level I2C driver is working fine (i) with other standard I2C interfaces and (ii) after adding delay.
Sending NACK before STOP bit in read cycle and sending ACK before STOP bit in write cycle are standard I2C ways. Our low level driver implements this. Our IC is Microchip ATSAMD51.
I re-counted the pulses in the capture and there is the NACK at the edge of the last clock pulse but didn't hold long enough. A couple of things you can try:
1. Reduce the I2C frequency and see if that helps.
2. Increase the pull-up resistor on the I2C bus.