STM32F302 does not release SCL on Arbitration Lost Error (ARLO) in Slave Mode

[t.sparber]

Hello,

I'm using a STM32F302RBTx in IC2 Slave Mode with Clock Stretching Enabled.

In general the Communication with a Master works fine. During testing the following problem appeared: When an Arbitration Lost error is introduced, the Slave detects this and triggers the ISR. The HAL Library also reports the status code 0x02 for ARLO, but the SCL line is never released.

ISR.BUSY is 1

ISR.TXIS is 0

ISR.TXE is 0

ISR.ADDR is 0

According to the Reference Manual, when an ARLO is detected, SCL and SDA lines are released.

RM0365 page 815.

"In slave mode, arbitration loss is detected during data phase and data acknowledge

phase. In this case, the transfer is stopped, and the SCL and SDA lines are released."

Even Setting the CR1.PE to 0 does not release the SCL. Forcing a SystemReset using NVIC_SystemReset, correctly releases the SCL but this is not a good solution for our use case.

Note: The same behavior is observed when the BERR flag is set.

Any advice is appreciated.

Best Regards,

T. Sparber

[waclawek.jan]

Are you sure it's the Slave which holds the SCL line?

JW

[t.sparber]

I'm pretty sure it is the slave. The reasoning is that as soon as the NVIC_SystemReset is performed (or the debugger triggers a reset), the SCL line returns to high.

[waclawek.jan]

I2C modules are notoriously hard to get right both in software and hardware.

Maybe you could try to finish the transaction regardless of the error, i.e. try to ignore the error. It may be easier in software you own than in Cube/HAL; but you can try to disable the error interrupt, at least as an experiment.

Instead of resetting the whole chip, you could try to reset only the I2C through its respective reset bit in RCC_APBxRSTR.

JW

[t.sparber]

I did some more tests.

Using the RCC_APB1RSTR_I2CxRST register I can reset the peripherial (all register values are set back their default value), but the SCL Line is still not released.

Note: In some cases the of the ARLO or BERR flag the SCL lines are released or stay released. (Maybe when der controller would not have blocked them anyway).

To trigger the BERR and ARLO I randomly pull the SDA line to GND. So maybe this could be reproduced on other setups as well.

Ignoring the error would be ok for me as long as the hardware releases the SCL line not blocking other slaves/master. I tried disabling the ER ISR, but this does not help. SCL line is still blocked.

Might there be a bug in the controllers i2c peripherial? The Errata does not mention anything regarding this issue.

[waclawek.jan]

There are at least 2 distinct I2C incarnations in STM32s. The I2C in 'F3 appears to be of the same type as that in 'F0, I have experience with the 'F3 but with 'F0 I have I2C slaves and I never experienced "hanging" SCL on the slaves side - "abusing" the bus (among other things, shorting both SDA and SCL to GND manually) is part of the "normal" I2C testing procedure.

This may of course depend on the particular setup (timing and maybe other registers/bits), but also on the states handling - in case of clock stretching, SCL may remain low if a state which implies SCL stretching is not handled properly. Reset should release it unconditinally, though, as well as clearing PE; but I never needed to resort to that (the different incarnation of I2C as found in 'F4 is a wholly other issue).

I might've mentioned that I don't use Cube.

JW