2018-02-07 08:41 AM
Hi,
We are running a system with a single F7 I2C master and a number of F0 based I2C slaves (currently 4 slaves), each slave is connected to the master via ~0.3m cables. We are using 10-bit addressing.
We are seeing a very intermittent issue where the the 9th clock edge does not rise very high (0.7v), all previous clocks are OK. It seems that this then confuses the slaves I2C statemachine and SDA stays low. Please see the attached logic shot.
Is this a known issue? We are seriously scratching our heads here as this has been troubling us for a number of weeks now.
Thanks,
Peter.
2018-02-07 08:43 AM
Pins configured in Open-Drain? What kind of pull-ups?
2018-02-07 09:47 AM
Yes, open drain.
This is a stm32f746-disco, pullups are 2k7.
Thanks,
Peter.
2018-02-07 11:52 AM
Ideally, make the SW stop when this condition is met. Then reset manually each slave to know which one contributes.
Test with 7 bit addressing mode for comparison. (in case one slave is 7 bit and others 10 bit).
Some STM32 decode more than a single slave address, better make sure all is well.
Which bit is clunky? Slave address one? Data read, data write or random position?
2018-02-07 12:03 PM
You might be able to tune it a little via I2C_TIMINGR.SCLDEL.
2018-02-07 03:00 PM
swap the pullup to 10k
2018-02-07 04:11 PM
Does the part you're using do anything like clock-stretching? The Master really should be the only thing driving the SCL.
https://www.nxp.com/docs/en/user-guide/UM10204.pdf
2018-02-08 02:12 AM
The image attached shows the issue, the 18th clock does not rise very high (or is either a spike/noise). It turned out I had disabled the analogue filter capabilities via the HAL API (I've used the std peripheral library before and never came across the filter features - so disabled this via the HAL). When we've re-enabled the analogue filter for the master and all slaves we are no longer seeing instabilities (though will test for a much longer time today).
Thanks,
Peter.