I am trying to understand the errata sheet for STM32L4x6xx series of MCU (DocID026121 Rev 4, December 2016).
I2C peripheral limitations section lists one of the silicon bugs as
“2.6.3 Wrong data sampling when data set-up time (tSU;DAT) is smaller than one I2CCLK period.
The I2C SDA line is not correctly sampled when tSU;DAT is smaller than one I2CCLK (I2C clock) period: the previous SDA value is sampled instead of the current one. This can result in a wrong slave address reception, a wrong received data byte, or a wrong received acknowledge bit.”
Here is the suggested workaround:
“Increase the I2CCLK frequency to get I2CCLK period smaller than the transmitter minimum data set-up time. Or, if it is possible, increase the transmitter minimum data set-up time.”
The I2C bus specification and user manual specify a minimum data set-up time (tSU;DAT) at:
- 250 ns in Standard-mode
- 100 ns in Fast-mode
- 50 ns in Fast-mode Plus
Did I get it right that virtually in all cases data set-up time is indeed smaller than one clock period and this particular bug inherently affects every I2C usage?
I am a bit confused as according to workaround, even for Standard-mode the I2C clock should be increased to at least 1/250ns = 4MHz, which is well above I2C operational frequencies in any mode. This essentially makes the workaround useless.
So here is my question: Is it possible to use I2C peripheral in STM32L4x6xx at all? Or the silicon bug described makes it unusable and software bit-banging of I/O port lines is the only option to implement I2C comms in this chips?