I am using a K60 as an I2C master. The I2C communication works but occasionally there are errors. In the photo shows SCL and SDA on both sides of a level translator. The red arrow points to what I call a runt clock. It begins at the correct time but for some reason it stops and looks like a glitch on the scope. Note there are only 8 clock pulses rather than expected 9. Since the K60 is the source of SCL, is this a problem in the K60? The K60 is the only master on the I2C bus.
Has anyone seen this and know what could cause it? The position of the missing clock varies.
Looking back at some notes I have from this project, it looks like we tried to pulse SCL to recover I2C, and the pulse was to allow the slave to release the SDA line since it was missing one clock cycle. But that was not a perfect solution. We then tried lowering the value of our pull-up resistors on SCL and SDA and that appeared to work the best; we also reduced the number of I2C calls as we were transmitting to the slave device a bit too much anyways. Hopefully this helps.
I've had plenty of I2C headaches but that's not a glitch I've seen before. Are you using the SDK's I2C API? Sure you're not touching any registers that might affect it? I agree with Mark that it's most likely a firmware problem. I've never used it with a level shifter, though. I was going to suggest checking that something in the hardware isn't pulling the line low but it looks like the high interval in the runt clock is dropped almost completely, and if something else was pulling it low the position of the other clock pulses would be unaffected, so it has to be internal to the part.
Maybe set a watchpoint on I2Cx_F and make sure nothing is messing with the frequency divider?
Scott
Hi
I have used the K60 and intensive I2C master operation in a number of products during the last 6 years without any known issues (in revision 1 and revision 2 parts). This suggests that the I2C controller in the device doesn't have any erratas that cause such behavior. It is likely that there is a firmware issue - are you sure that no writes are attempted to the peripheral at the wrong time when it is presently in operation?
Regards
Mark