2021-03-18 12:18 PM
Errata for STM32H72x/3x has p. 2.16.4 Transmission stalled after 1st byte transfer
Does it by chance apply to STM32H753 as well?
My customer reports a similar behavior in field, I cannot repro it on my setup.
Thanks,
--pa
2021-03-18 01:05 PM
I'd be interested in knowing also, but haven't had issues with H74x/H75x based I2C OLED's
2021-03-19 12:36 PM
? How this is related to OLEDs?
My case is polling several sensors (TI, Analog Devices) using repeated start sequence; every read from these devices starts from writing some address or control word.
Debug info from the customer shows that I2C transactions are stuck after or during sending the 1st byte. Looks very similar to the errata item 2.16.4 though their MCU is a H753. They don't understand what triggers it - can be high temperature or voltage glitches.
One of proposed workarounds should be easy to do in the HAL library (HAL_I2C_Mem_Write, HAL_I2C_Mem_Read).
--pa
2021-03-19 12:59 PM
>> How this is related to OLEDs?
Tangential hearsay?
I'm throwing in an unrelated I2C observation, having not had a lock up on an H7, for an unspecified slave device.
Unless your problem actually locks up the core (QSPI style) surely you could have a timeout/recovery strategy for non-responsive I2C slaves?
2021-03-22 09:15 AM
@Imen DAHMEN ?
2022-09-14 02:21 AM
Hi Pavel, we've just encountered an I2C/DMA issue with our STM32H743. It transmits the address and the first data byte successfully (both acked), but fails to transmit the 2nd data byte. There is no error generated and the i2c clock remains low. The driver waits indefinitely for the transmission to complete (which it never does). We've found some boards are more susceptible to the issue than others. A screenshot of the i2c stalling is attached.
The ratio of our i2c clock to APB clock is in range specified by the STM32H72x errata, so we are also wondering if it was incorrectly excluded from the STM32H743 errata. We're changing the clock ratio and will let you know if it fixes the issue.
Cheers
David
2022-09-15 03:25 PM
David, thanks for sharing your case.