Posted on March 04, 2017 at 10:53Hi,
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?
#i2c-problem #i2c-on-stm32l4x6xx-errata-question
