I2C peripheral Multi-master mode

[navidcity]

Hello all,
I'm using STM32L552 MCU and its I2C peripheral to control a board. I'm facing a phenomenal which I not quite sure how to handle that. I have a pretty old fan controller chip on the board which is kind of really slow. Not only it works with I2C frequencies under 100 KHz but also the internal RISC core of the fan controller crashes if the master initiates the I2C transactions to fast. As a result of this crash the I2C lines are getting low by the fan controller. This makes STM32 MCU to assume that there is another master on the bus and there is a START condition. So it waits for STOP condition which is never going to come. In software I receive a HAL_I2C_ERROR_TIMEOUT and the I2C peripheral never recovers from its state.

The first workaround was to simply reset the board to make everything clear. Obviously it's not a solution; I wanted to just develop the software further more.

Then I found out that if I disable the peripheral and enable it afterwards (I ensure that there is at least 3 APB clock cycles in between), the bus will recover from its state and I'm able to initiate I2C transactions. 

This workaround introduces another problem though. If I reset the peripheral once it will never go into multi master mode. I mean when the fan controller crashes I don't get the timeout error. I get HAL_I2C_ERROR_ARLO instead and I2C peripheral never goes into multi-master mode.
The problem here is That later after the initialization phase another master comes on the I2C bus and I really want to catch the START condition and go into multi-master mode.
If anyone has any idea about this issue I would be happy to discuss it.

[TDK]

ARLO would indicate SCL is being pulled low externally, which matches your earlier observations.

If SCL is being pulled low by the fan controller indefinitely, nothing on the STM32 I2C peripheral side can recover from this state, since the pins are driven in OD mode. Power cycling the fan controller would likely recover.

[navidcity]

Thanks for the reply.
The SCL isn't pulled low indefinitely by fan controller. It's only a voltage spike on the line which makes this problem. 

I attached two useful images. They are captured by a logic analyzer. 

[Pavel A.]

@navidcity  Does this old fan controller act as master and the STM32 as slave? or other device acts as master and STM32 as slave? STM32 has several I2C controllers so you can isolate the old bad thing on its own bus.

[navidcity]

No, the fan controller is purely an I²C slave device. But by causing the glitch on the SCL line STM32 I²C peripheral thinks there is another master on the bus talking. So it goes into multi master mode. For now there is no other master on the bus. In the project plan at some point we are going to introduce another master to the I²C tree. But now the bus belongs only to the STM32.

[Danish1]

Looking at the analog trace, I see those lines are going down fairly slowly. That makes me wonder if your fan-controller isn't actually driving them low. But rather it is failing to pull them up. And other things (e.g. your 'scope probe) are pulling them down.

Do you have other pull-up resistors for SCL, SDA in the system? If so, what value are they?