DEV Community

Hedy
Hedy

Posted on

Is there a bug in the hardware I2C of STM32?

#stm32 #i2c #bug #stm32f1

Yes, there have been known hardware bugs and limitations in the STM32 I2C peripheral (specifically in older STM32 families like F1, F2, F4, and L0/L1). These issues have been documented by STMicroelectronics in errata sheets and have led to workarounds in firmware or even redesigns in newer STM32 series.

Known STM32 I2C Hardware Bugs
1. STM32F1/F2/F4/L0/L1 Series Issues
a. "Bus Hangs" in Master Mode
Problem: The I2C peripheral may lock up if:

  • A slave NACKs (fails to acknowledge).
  • Clock stretching is misused.
  • A glitch occurs on the bus (e.g., noise-induced SDA/SCL corruption).

Effect: The I2C peripheral gets stuck in an infinite wait state, requiring a full reset or GPIO reconfiguration to recover.

b. Erratic Behavior Under Clock Stretching
Some STM32 I2C peripherals do not handle clock stretching correctly, leading to:

  • Premature timeout.
  • Incorrect clock pulse generation.

c. Missing Repeated Start (Sr) Support (Older Versions)
Some early STM32 I2C implementations had trouble generating a proper repeated start condition, which is required for multi-message I2C transactions (e.g., I2C reads after a write).

d. Incorrect NACK Handling
Some STM32 I2C peripherals fail to properly detect NACKs, leading to silent failures instead of error flags.

2. Workarounds & Fixes
a. Software Reset on Lockup
If the I2C bus hangs, manually reset the I2C peripheral:

c
void I2C_Recover(I2C_TypeDef *I2Cx) {
    // Disable I2C
    I2Cx->CR1 &= ~I2C_CR1_PE;
    // Reconfigure GPIOs (optional, to clear stuck signals)
    GPIO_InitTypeDef GPIO_InitStruct = {0};
    GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_OD;
    GPIO_InitStruct.Pin = SDA_PIN | SCL_PIN;
    HAL_GPIO_Init(I2C_GPIO_PORT, &GPIO_InitStruct);
    // Toggle SCL to force bus release (I2C spec allows this)
    for (int i = 0; i < 16; i++) {
        HAL_GPIO_WritePin(SCL_PORT, SCL_PIN, GPIO_PIN_SET);
        HAL_Delay(1);
        HAL_GPIO_WritePin(SCL_PORT, SCL_PIN, GPIO_PIN_RESET);
    }
    // Re-enable I2C
    I2Cx->CR1 |= I2C_CR1_PE;
}
Enter fullscreen mode Exit fullscreen mode

b. Use Interrupts or DMA Instead of Polling
Polling-based I2C is more prone to lockups. Interrupt-driven or DMA-based I2C improves reliability.

c. Avoid Clock Stretching
Disable clock stretching if possible (I2C_CR1_NOSTRETCH in some models).

d. Use a Newer STM32 Series (F3/F7/H7/G0/G4)
Newer STM32 families (e.g., STM32F7, STM32H7, STM32G0/G4) have revised I2C peripherals with fewer bugs.

3. STMicroelectronics' Response

  • ST has acknowledged these issues in errata sheets (e.g., STM32F4 Errata).
  • Some fixes were implemented in later silicon revisions (check your chip’s revision code).
  • The STM32 HAL and LL libraries include workarounds (but may still require manual fixes).

4. Should You Use STM32 Hardware I2C?

5. Bit-Banging as an Alternative
If hardware I2C is unreliable, implement software-based I2C (GPIO bit-banging):

c
void I2C_WriteBit(uint8_t bit) {
    HAL_GPIO_WritePin(SDA_GPIO, SDA_PIN, bit ? GPIO_PIN_SET : GPIO_PIN_RESET);
    HAL_GPIO_WritePin(SCL_GPIO, SCL_PIN, GPIO_PIN_SET);
    HAL_Delay(1); // Adjust timing per I2C speed
    HAL_GPIO_WritePin(SCL_GPIO, SCL_PIN, GPIO_PIN_RESET);
}
Enter fullscreen mode Exit fullscreen mode

Slower but more reliable for problematic chips.

Conclusion

  • Yes, older STM32 I2C peripherals have hardware bugs, but newer models (F7/H7/G0/G4) are much improved.
  • Workarounds exist (resets, interrupts, avoiding clock stretching).
  • Check your chip’s errata sheet and consider bit-banging if reliability is critical.

Top comments (0)