cancel
Showing results for 
Search instead for 
Did you mean: 

I2C erratum for STM32H7 - does it apply to STM32H753?

Pavel A.
Evangelist III

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

6 REPLIES 6

I'd be interested in knowing also, but haven't had issues with H74x/H75x based I2C OLED's

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

? 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

>> 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?

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Pavel A.
Evangelist III

@Imen DAHMEN​ ?

DOsbo
Senior

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

David, thanks for sharing your case.