How to reset I2C on STM32F4407 without resetting the MCU

[Nils B]

Hello

I have trouble with handling an I2C error on my STM32F407. My I2C bus usually works fine but it sometimes hangs, with both clock and data lines are high, but the I2C communication does not start. The SR2.BUSY bit remains high and sometimes when this bit is indeed low, the SR1.SB bit remains low after the code sets the CR1.START to initiate a transfer.

I've noticed that resetting the entire MCU fixes the problem, I2C communication restarts and everything is fine.

However, resetting the entire MCU is not an option. Instead I'd rather like to reset just the I2C peripheral.

I've tried doing this in a number of ways:

• By setting and clearing APB1RSTR.I2C2RST
• By setting CR1.STOP to generate a stop in the communication
• By setting CR1.SWRST to generate a software reset of the I2C peripheral
• By clearing CR1.PE 

The above is followed by calling the same setup routines as used initially to set up I2C communication.

Once the error happens, none of this seems to fix the error.

• What other ways are there to reset the I2C peripheral?
• What could cause the SR2.BUSY bit to remain high?
• What could cause the SR1.SB bit to remain low after setting the CR1.START bit?

I have spent a lot of time with this issue and would greatly appreciate any help I could get.

Best regards

Nils

[AvaTar]

BTW, with SPL I meant the Standard Peripheral Library, a more robust but now abandoned predecessor of Cube.

It's still availabe for the early F4xx variants, and comes with plenty of examples - and driver code for the peripherals.

In this "Worst Forum Ever", it is really hard to keep track of threads one got involved.

[damien_lobb]

I have recently had the same issue, and I thought it would be worth noting what I found, in case someone else is struggling with this.

The solution given by Nils B -

> So, in all, what I did was set the software reset bit (CR1.SWRST) and then call the init function once more, thus resetting the peripheral to the same state it is after startup.

I found that the Deinit function must be run after the SWRST. Without it, CR2 was never set, and thus the clk never generated, tieing SCL low constantly. I have no idea why this is, as it passes the Init function without error.

[S.Ma]

Reference Manual, SYSCFG has reset bit for each peripheral. Set and clear the bit for the chosen I2C.

[YHass.14]

Hello all,

I have also same problem with I2C.

I use STM32F439BGT6.

After the I2C was stuck, I set the software reset bit (CR1.SWRST) but this bit remained 1.

The init function (HAL_I2C_Init) didn't clear this bit and the I2C didn't work at all.

I cleared the software reset bit (CR1.SWRST) via debugger and after it the device started to work.

A few questions:

1) Is the software reset bit (CR1.SWRST) cleared automatically or should I clear by software?

2) If I should clear by software, how long time should I wait between setting and clearing (microseconds or milliseconds)?

3) Should I reset and clear of the software reset bit (CR1.SWRST) in disable interrupts state?

Thanks.

Yacob Hassidim.

[damien_lobb]

Hi Yacob,

I​ believe some of the I2C drivers will clear it automatically but you may have to do it yourself depending on your version. You can step through the driver to find out, but there's no harm in doing it yourself aswell.

I​ am not sure about the timing, but most drivers I've looked at don't seem to give any delay so probably don't need to worry about it, but this information should be given in your device's datasheet.

Hope this helps.

Damien​

[Tesla DeLorean]

External I2C peripherals can also get into odd states. Worst case clock them out driving pins as GPIO

[YHass.14]

Hello Damien,

Thanks for your response.

Yacob Hassidim.

[YHass.14]

Hello Clive,

Thanks for your response.

Yacob Hassidim.

[Hcuon.1]

Thanks Nils B,

I had the same problem with Stm8.

I have solved this problem in your way.

I'm really thankful to you