STM32 I2C Multi-master problem

[SGars]

I'm seeing a problem which seems to be related to the one discussed here: https://community.st.com/s/question/0D50X00009XkgoYSAR/stm32-i2c-multimaster-hardware-bug

In my case though I'm not using DMA, I'm just using interrupt driven I2C but the symptom is the same:

When an MCU is addressed for a slave read at exactly the same moment it attempts to master a write transaction on the bus the collision is not detected as an arbitration loss, but the peripheral switches to slave transmission and performs that transaction, but then as soon as that is complete it starts the master transmission but with chaotic data values (uses the last TXDATA value that was loaded at the end of the slave transmission).

The closed bug referred to above mentioned that this was now a known bug in the I2C peripheral and that the errata sheets would be updated. However I can't find any mention of this behaviour in the errata sheets for the micros I'm using (an STM32F746 and STM32F071), both of which seem to display this behaviour.

Can you confirm whether this problem is expected to occur with these micros and whether there are any recommended workarounds please ?

Thanks,

Steve

[SGars]

I've done some further digging on this and the bug is documented in the errata for STM32F030x4/x6/x8/x, but not for the STM32F071 or STM32F746 that I'm using.

So I've applied the workaround suggested in the STM32F03 errata (clearing the START bit immediately after clearing the ADDR bit) and also the suggestion from @Dan Hepler (@https://community.st.com/s/profile/0050X000007vun8QAA) to reset the peripheral after the STOP for the slave transaction.

The application of both of these seems to have at least stopped the problems with the bus getting jammed low after a slave/master collision and I guess that at least gives scope for the application to retry the master transaction.

Can someone from ST confirm that this issue is common across all the latest micros (or at least the ones I'm using) - I guess they use the same I2C ip block so should presumeably have the same errata ?

Thanks,

Steve