I2C master driver does not recover after slave failure

[rcotterill]

Hello,

I have a Nucleo board with an STM32F767Zi using its I2C master to test a third party chip that is an I2C slave. Unfortunately the slave occasionally fails (stops sending bits) and the STM32 master driver does not recover, it needs a hard reset to clear the fault.

This setup works fine with other devices where we transmit a 16-bit 'memory address' for each i2c read/write.

I see failures about 1 in 10,000. I think there is a bug in HAL_I2C_Master_Transmit_DMA()  and/or HAL_I2C_Master_Receive_DMA(), maybe a DMA timeout not happening.

Has anyone else seen a bug like this?

Any tips for debugging the i2c driver?

The drivers were generated by ST Cube in 2017, with mods from ST Support to run 1MHz I2C master. Updating to drivers generated by the latest STCubeMX is a last resort because we would have to fully re-test another device that uses this platform. Looking at the diffs the code has changed a lot so it's not clear if this bug has been fixed.

Thanks in advance,

Rich

[LCE]

I had some strange problems with I2C TX via DMA on a F767 (can't remember if I used the HAL stuff, but with DMA probably yes), so I ended up using a self-made I2C driver based on interrupts.

[Andrew Neil]

Some previous threads on recovering from I2C failures:

https://community.st.com/t5/stm32-mcus-products/stm32h745i-i2c-recovery-after-addressing-nonexistent-device/m-p/660263/highlight/true#M240602

[rcotterill]

Some good points how to recover the i2c bus, which I will apply later.

Right now I'm still trying to detect that the STM32 has hung up.

Thanks,

Rich