I2C not always starting up properly

[RHarte]

I have a design with an STM32F415 MCU which has two I2C-peripherals: a CAT24AA16 serial EEPROM and a TSC2007 touch screen controller on the same I2C bus. I2C setup is standard as generated by CubeMX.

I find that 90% of the time the system starts up OK with both peripherals working fine, but in the other 10% the system starts up with always both peripherals seemingly not working and HAL_I2C_IsDeviceReady giving HAL_ERROR as result on both peripherals. Usually giving one or more system resets on the MCU (without power-cycling the whole PCB) solves the problem which leads me to believe that it's not the peripherals that are in some wrong state but something within the MCU is. Giving the statistical nature of the problem, it could perhaps be a register or variable which is not initialised properly and has an undefined power-up state.

Has anyone experienced this and/or has any tips where to look for a solution?

[Foued_KH]

Hello @RHarte​ ,

You may connect an Oscilloscope to see the SDA and SCL behavior.

Foued

[RHarte]

Thank you very much for your reply! Your suggestion is a bit of a problem. It concerns not one of our own designs but an existing (and apparently somewhat flawed) design that one of our customers has asked us to take under our wings. In this SMD-board the SDA and SCL lines are not easily accessible for my logic analyser and we don't have a breadboard prototype to fall back on...

Since I'm 99% sure it's a software issue and the software itself is as vanilla as it gets I was hoping more people have experienced a similar problem and would be able to give me some quick pointers as to in which direction to look.

Anyway I will also pursue this path and see if I can use my steady hand and microscopic skills to connect some wires for tracing the signals. Probably the pullup resistors could offer me a decent connection point 😁

[Pavel A.]

If hooking up a scope is this hard, perhaps it's easier to take several samples of SCL and SDA in software (read N samples, store, inspect with debugger).

[Bob S · Accepted solution]

There should be pull-up resistors on the I2C lines. Solder wires to those to clip your logic analyzer or scope leads to. If there are no external pull-up resistors, that may be one of your problems. The STM32 internal pull-ups are weaker than suggested for I2C. Try slowing down the I2C clock frequency (you should be able to override the 100000 value in CubeMX, or whatever speed you are using).

You also might try adding some code before you call MX_I2Cx_Init() to configure the pins as open-drain outputs. Manually generate a start condition, then send 9 clock pulses then a stop.

[RHarte]

The pullups were indeed a good place to hook up my logic analyser, and I noticed SDA remained low at bootup when the problem occurs. So that indicated a bus hangup.

For that issue, the 9 clock pulses did the trick! I also found out why there was a problem with the bus between reboots: there is quite heavy i2c-traffic going on most of the time, and giving a (random manual) reboot gives a decent chance of rebooting in the middle of an i2c-sequence, thus leaving the peripherals on the bus hanging.

I did not yet find a clear reason why the bus sometimes hangs on power-up, but anyway also that problem is fixed by giving 9 clockpulses. In theory the method could even be a bit more sophisticated by giving clockpulses until SDA goes high, but I'm already very happy I got this stability thing out of the way!

Thanks guys!

[Bob S]

In order to give better visibility on the answered topics, please click on 'Select as Best' on the reply which solved your issue or answered your question. See also 'Best Answers'