cancel
Showing results for 
Search instead for 
Did you mean: 

Occasional runt I2C 9th clock edge.

Peter Morrow
Associate II
Posted on February 07, 2018 at 17:41

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.

7 REPLIES 7
Posted on February 07, 2018 at 17:43

Pins configured in Open-Drain? What kind of pull-ups?

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Posted on February 07, 2018 at 17:47

Yes, open drain.

This is a stm32f746-disco, pullups are 2k7.

Thanks,

Peter.

S.Ma
Principal
Posted on February 07, 2018 at 20:52

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?

Posted on February 07, 2018 at 21:03

You might be able to tune it a little via I2C_TIMINGR.SCLDEL.

T J
Lead
Posted on February 08, 2018 at 00:00

swap the pullup to 10k

Posted on February 08, 2018 at 00:11

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

 
Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Peter Morrow
Associate II
Posted on February 08, 2018 at 11:12

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.