STM32F4 I2C - is it possible for slave MCU device I2C interface to stop functioning while the rest of the I2C master MCU and attached devices carry on communicating happily?

[jim239955_st]

I have an STM32F401 MCU acting as a master on its I2C1 port linked to a slave STM32F407 MCU, and a couple of DIO expanders (PCF8575). After a random period of between minutes and days the Master appears to stop updating the Slave MCU but continues to read and write correctly to the DIO expanders. All functions would normally be executed once per cycle through the program in normal running of the master program. The issue appears to be with the Slave MCU. Is this possible or is the slave I2C1 also running correctly and something else in the slave program is preventing the data being used? Apart from this single I2C1 port the rest of the slave MCU functions appear to run normally including Uart inputs and a second I2C2 port linked to an EEprom memory bank.

Any advice would be welcomed.

[KnarfB]

There may be glitches on the bus (or in your code) putting the slave in an error state? Would hook-up a logic analyzer to check if/how the master transactions are answered by your slave. Moreover, add checks for all error conditions/return codes to your slave code and add some logging or attach a debugger to the slave after the error happened. A crude workaround would be resetting the slave by the watchdog if not polled on I2C bus :)

hth

KnarfB

[jim239955_st]

Thank you for the advice. I will do that tomorrow. This is a project i have taken over form a guy who left and to be honest it is not very good coding. He has not added in any error checking or activated the error interrupts for these i2C busses so i will do that next..

[Piranha]

You are asking for advice, but haven't told anything about the firmware. If it uses the broken bloatware named HAL, then expecting it to work is illogical. Typically the strategy of HAL developers and users is to ignore the bugs and pretend they do not exist.

https://community.st.com/s/question/0D50X0000C5Tns8SQC/bug-stm32-hal-driver-lock-mechanism-is-not-interrupt-safe

[Tesla DeLorean]

The device would need to understand that it has failed in order for it to attempt recovery.

​

T​his however might be potentially disruptive if it fails repeatedly and jams the bus, rather than just dying quietly.

[Tesla DeLorean]

If one slave freezes but doesn't jam SDA low, then addressing that device will fail, but everyone else will be fine​