How to recover I2C in stm32 STM32H743 after an error or a locked state which can come due to a glitch or spike on the bus.

[APand.8]

I am using the Nucleo-H743ZI2 board I wanted to know, how to recover I2C after an error or a locked state which can come due to a glitch or spike on the SDA or SCL line.

There is no bit I could find to reset the i2c peripheral in the control register.

[Foued_KH]

Hello @APand.8​ ,

If the error is :

• OVR, ARLO, NACK : you can just do a Transmit again
• BERR : You have to re-enable the peripheral

If you are facing some erratic behavior on STM32, do not forget to check Errata sheet of the device. There are few points related to I2C interface. 

Foued

[Tesla DeLorean · Accepted solution]

Most Slaves don't have an async reset on them.

If they are hanging up the bus you'll need to clock them out of whatever state they are in so they release the bus, and no longer think they are the active device.

Ponder also where this "glitch or spike" is coming from, it you've got the appropriate pull-ups on the bus, and you're working no faster than the slowest device on the bus.

[S.Ma]

Before generating a START bit, check the bus is IDLE (SDA = SCL = high level voltage)

If not, reset the HW I2C (if using), generate 18 STOP bit by SW GPIO bit banging, then reconfigure the I2C and keep going.... works most of the times, and could be conveniently added in I2C examples to reduce support (so many questions seen on this forum about this) ? I2C Bus = 1982...

This should help, may not solve everything...

Of course, Murphy's law-proof it :

Make the STOP bit bitbang compiler maker/optimisation level/core frequency independent.

A rugged and reliable application code is hardly a band-aid quick patch.

[APand.8]

Thank you for your reply, I2C is working fine, for testing, I was explicitly giving the glitch.

[sheqom]

Can you share your solution? I'm having exactly the same problem but I couldn't solve it.