STM32L496 Errata 2.19.4 Not Addressed In HAL

[Matt001k]

I created an issue on github here,  but wanted to post here as well for visibility.
Copied below are the details of this linked content:

 

Describe the set-up
Custom hardware for our internal product.
STM32L496.
HAL version 1.13.5.
2 devices on I2C bus, HTU21D and PCA9535.

Describe the bug
Some processors through our production have been coming across errata 2.19.4:

 

 

 

The HAL does not seem to address this errata and the timing for I2C transactions begin failing after the bus error occurs.
Sometimes it has led to the I2C bus locking up because the components on the bus (besides the processor) are stuck waiting for a transaction to finish (the device responds properly with ACK/NACK or correct data when the bus error occurs). We have created some messy workarounds that do not fully solve this issue.

Additional context
The following is a diff of the changes I made to address the problem:

diff --git a/STM32L4xx_HAL_Driver/Src/stm32l4xx_hal_i2c.c b/STM32L4xx_HAL_Driver/Src/stm32l4xx_hal_i2c.c
index f2a44238..a6789643 100644
--- a/STM32L4xx_HAL_Driver/Src/stm32l4xx_hal_i2c.c
+++ b/STM32L4xx_HAL_Driver/Src/stm32l4xx_hal_i2c.c
@@ -4664,7 +4664,7 @@ void HAL_I2C_ER_IRQHandler(I2C_HandleTypeDef *hi2c)
 if ((I2C_CHECK_FLAG(itflags, I2C_FLAG_BERR) != RESET) && \
 (I2C_CHECK_IT_SOURCE(itsources, I2C_IT_ERRI) != RESET))
 {
- hi2c->ErrorCode |= HAL_I2C_ERROR_BERR;
+ //hi2c->ErrorCode |= HAL_I2C_ERROR_BERR;
 
 /* Clear BERR flag */
 __HAL_I2C_CLEAR_FLAG(hi2c, I2C_FLAG_BERR);
@@ -7262,12 +7262,12 @@ static HAL_StatusTypeDef I2C_IsErrorOccurred(I2C_HandleTypeDef *hi2c, uint32_t T
 /* Check if a Bus error occurred */
 if (HAL_IS_BIT_SET(itflag, I2C_FLAG_BERR))
 {
- error_code |= HAL_I2C_ERROR_BERR;
+ // error_code |= HAL_I2C_ERROR_BERR;
 
 /* Clear BERR flag */
 __HAL_I2C_CLEAR_FLAG(hi2c, I2C_FLAG_BERR);
 
- status = HAL_ERROR;
+ // status = HAL_ERROR;
 }
 
 /* Check if an Over-Run/Under-Run error occurred */

 

This has absolved all of the strange bus behavior and prevented the lockups aforementioned.

What should be done?

Is this an applicable update for the HAL? Or will we need to have our own custom I2C transaction to address this?

[TDK]

I don't believe HAL implements workarounds for errata.

In this case, the issue is bad enough that it makes some HAL functions unusable, which is unfortunate. Not sure where ST lines in the "should HAL implement workaround for all errata" question.

 

Not sure ignoring BERR is the correct solution. What if there is a bus error? I guess on this chip BERR is unreliable so the functionality is lost entirely? But it seems slave mode is not affected.

[Matt001k]

Not sure ignoring BERR is the correct solution. 
What if there is a bus error? I guess on this chip BERR is unreliable so the functionality is lost entirely?

Yes, that's my largest concern too.

Hopefully some of the workarounds in place, which involve bit banging the clock line and resetting the peripheral, will prevent anything strange from occurring in the case of an actual bus error.

This issue seems to be getting worse with some of the newer MCUs we are getting. Interestingly heating the board seems to prevent the errors from appearing as well, but that's not possible in a real world application of our product.

I did get my answer from the Github issue opened, STM will not support this in the HAL. We do not want to modify the HAL as that will create a maintenance burden if we ever want to update the HAL, so I will have to figure out another solution.

But I do want to bring awareness to both ST and the community here.

Thanks!