We are having some issues with how the LS1020a handles (or rather, doesn't handle) clock stretching with a particular i2c slave device. Sections 25.6.4.2-3 of the LS1021A reference manual seem to indicate that the i2c hardware in the LS1020a supports clock stretching only after the 9th bit...which I take to mean the ACK/NAK bit.
The i2c slave that is clock stretching is a microcontroller that one of our vendors implements the firmware for. Previously, this slave device was stretching during the ACK/NAK. The LS1020a was obviously not honoring this and we attributed it to the fact that the ls1020a only supports clock stretching *after* the ACK bit. So, we asked the vendor to only stretch after the ACK to workaround this issue. Unfortunately, this doesn't seem to help since the LS1020a continues to ignore the slave's clock stretching.
I'll add scope captures that show both of the events that I mentioned.
Is this expected? Does the LS1020a support clock stretching? If so, under what conditions?
Thanks,
Ben
Have a great day,
We do not have any report about I2C clock stretching issue for the LS1020A/LS1021A. Please create a Technical Case, see: How I could create a Service Request? | NXP Community . In the Technical case please use better image quality for scope shot and add explanation for the traces on the shot image.
TIC
I'm attaching a scope shot showing the current problem where the i2c slave is stretching the clock after the ACK. It's clear to see when the slave is driving SDA or SCL due to the series resistance. In this case, the LS1020a attempted to drive two clock pulses while the slave was clock stretching.