I'm getting sporadic I2C bus errors with no terminating ACK

[BDimk.1]

I'm using STM32H743 I2C1 and FW as of december 2021.

I'm testing in continous loop PMBus communication (straight I2C master interface).

Appr. all 8h I'm getting a sporadic bus error.

A good transaction looks like:

this is a register read (addr-len=1) for a two-byte response.

my bus error transaction (some bus, devices, etc):

My software detects the bus error and stops in sw breakpoint (after returning from ISR).

I see different strange characteristics in this picture:

1) the clock stretch of the PSU is shorter than the good TA.

2) the returned register content of the PSU is 0xffff; this is suspicious on the protocol level, as this is a strange slinear16 value.

3) there is no second master ack after the last byte and no end marker. Both ack=1 and end-marker would be a function of the master STM, or am I mistake?

My only reponse to this incident is to drop the data and reinitialize the stm32-hal-i2c (deinit/init). But I suspect this event to also inpact the stability of my code, as I do get sporadic hard-faults when I run this software without debugger support.

Any explanations/ideas/proposals for improovements?

Thanks a lot,

Bernward

[waclawek.jan]

> 1) the clock stretch of the PSU is shorter than the good TA.

> 2) the returned register content of the PSU is 0xffff, this is suspicious

Why do you think this is problem on the STM32 side, then?

JW

[BDimk.1]

Wow, that answer was quick!

Yes I agree that observation 1+2 look like a problem of the device.

Still, a short clock stretch and a high sitting data-line are to my understanding a valid bus state (from device pov), and I'm missing the ACK /end marker of the STM32H743 core. So I'm looking for an explanation, why this is a bus fault from STM master pov.

Thanks a lot,

Bernward

[waclawek.jan]

I don't know. It depends on how exactly the I2C handler is written. You did not say that, but I guess you use Cube/HAL. I don't use 'H7 nor Cube/HAL and am not interested in it; but you can debug it as your own software, it is open source.

You can try to debug it by simulating the issue using a second STM32 as a slave, which would be programmed to return the "faulty" sequence.

JW

[BDimk.1]

YES, I'm using stm32h7xx_hal_i2c.c as of december 2021. And no, you can't debug that, because that behaviour is probably part of the ASIC implementation of the STM32H743 i2c core. So I do not see that the stm 32 hal is sending a ack/nack by command.

My question is, if this recorded trace with all stm code can be explained to be i2c standard conform. I see it conflicting to my understanding of I2C signalling.

Thank you.