My current board design have a number of slave that is connected on the same I2C bus as the CPT112S. one of which is the temperature sensor. We occasionally received a bad data from the temperature sensor and we later found of that there is a glitch on the I2C clock. It is as though one of the slave randomly detecting a rising edge and driving it low. I soldered a series resistors on each of the slaves to identify the one that driving the clock low right after a rising edge, and we found CPT112S is the slave causing the glitch. Generally it would be ok if the slave hold the clock low to make adjustment to the clock rate, however, it seems that the CPT112S is holding just after the rising edge that cause other slave to read it as a clock. Please see the attachment for more detail on how the series resistor affect the waveform. The clock rate is running at 88kbit so it is far within the 400kbit. Please let us know if there is anything that we may have done to cause the CPT112S pulling the clock late or is this a bug in the CPT112S firmware. We can reproduce this issue on both revision A1 and A2. Thank you, Tan
This is strange and we haven't come across such an issue in the past. How often do you see this happening? do you have multiple boards across which you are seeing similar behavior? Just to confirm, you have 1.5k pull ups on the I2C pins of the CPT112S, right?
Do you have a capture of this happening where you can tell what the data byte being sent from the master is? What is the value of the preceding byte?
Are you using repeated starts?
One theory is that a repeated start is seen by the 112s as a new start, and the data byte corresponds to its address or something weird like that.
What is the ADDR of the CPT112S device? The default? Something else?
Oh, I see, on your ticket it is mentioned that the CPT device's ADDR is 0x70. Very strange, since the clock in your image is being pulled low during bit 7 of the address 0x90 being sent...
Could you zoom in on this screen capture to show the SDA and SCL lines in more detail?
Sorry - I didn't see any timescales in the captures: does the 112S low period change when you change the I2C clock speed?
Are you using haptics (buzzer)?