Skip to main content
Visitor II
April 3, 2024
Question

STM32G474 strange I2C behavior

  • April 3, 2024
  • 1 reply
  • 1211 views

Hi,

I hope somebody can explain the following behavior:

I use a NUCLEO-G474RE board for I2C testing. I have an external I2C slave which provides the required pull-ups for SDA/SCL when it's powered.

Now my STM32 started with connected but not powered I2C slave and tried to communicate, which was not possible due to the missing pull-ups and because of missing slave supply. Then I powered the slave but SDA/SCL still show LOW level, measured with a scope. When disconnecting SDA/SCL I see HIGH levels at the slave side, what tells me that the pull-ups do what they should do and that the STM32 pulls the signals low permanently.

When checking the I2C state it shows READY and the last error was a TIMEOUT.

I use the HAL for the I2C interface.

Can anybody tell me what happens with the pin states of my I2C interface?

Thanks and best regards

    This topic has been closed for replies.

    1 reply

    Technical Moderator
    April 5, 2024

    Hello @kf_SEA ,

    Make sure that I2C clock speed is correctly configured and check the timing settings.

    Check also the I2C pull-up resistors and the speed mode to use within the right specifications (Standard, Fast, or Fast Plus).

    ImenD_0-1712313425469.png

    This FAQ describes few tips related to I2C peripheral on STM32 devices: STM32 I2C does not work - STMicroelectronics Community

    kf_SEAAuthor
    Visitor II
    April 5, 2024

    Hi @Imen.D ,

    thanks for your respronse.

    I don't have problems with I2C in general, but only if I run my application without I2C pull-ups from the beginning.

    It seems to be the a problem when trying to communicate without them.

    When I enable the pull-ups later (yes, they are switchable in my external hardware), the STM pulls SDA and SCL low continously until a reset.

    When running my application with pull-ups from the beginning there is not a problem at all.

    Can you tell me, why there is a state after i2c timeout that blocks the bus 'forever'?

    Thanks and regards