cancel
Showing results for 
Search instead for 
Did you mean: 

Nucleo STM32L432KC - Sporadic error when write to expander's port GPIO using HAL functions

ABric.2
Associate II

Hi,

For a project I'm using Nucleo STM32L432KC and STM32CubeMX V1.17.0.

I'm using the same code template for differents project and it's the first time I get this kind of errors:

At some points, when writing to a GPIO of expander PCA9535DB, I have HAL_ERROR returned. This error occurs when in function HAL_I2C_Mem_Write (same error with HAL_I2C_Mem_Read) from stm32l4xx_hal_i2c.c file.

    /* Process Locked */
    __HAL_LOCK(hi2c);
 
    /* Init tickstart for timeout management*/
    tickstart = HAL_GetTick();
 
    if (I2C_WaitOnFlagUntilTimeout(hi2c, I2C_FLAG_BUSY, SET, I2C_TIMEOUT_BUSY, tickstart) != HAL_OK)
    {
      return HAL_ERROR;
    }

Above the code that return the HAL_ERROR. (from file stm32l4xx_hal_i2c.c)

The fact is that the timeout is raised in I2C_WaitOnFlagUntilTimeout but I have no idea why.

As the code sometimes work and sometimes not, I assume that I2C address and parameters are correct. (Speed is 100KHz).

If someone already has the same behavior, help is welcome.

Best regards,

Antoine

1 ACCEPTED SOLUTION

Accepted Solutions
Bob S
Principal

The STM32's I2C hardware thinks one or both SCL/SDA lines are low. And usually (for me) it is an issue in the STM32, not from an external device. I've had this show up on various CPU families (G4, L4, F4, F7). The brute force work-around is to disable the I2C via __HAL_I2C_DISABLE() then re-initialize it via MX_I2Cx_Init() to make sure all the HAL layer variables get reset correctly along with the I2C hardware.

I haven't spent the time to figure out if this is a HAL issue, user code issue or external hardware issue (i.e. maybe ringing or noise coupled onto the signals).

View solution in original post

2 REPLIES 2
Bob S
Principal

The STM32's I2C hardware thinks one or both SCL/SDA lines are low. And usually (for me) it is an issue in the STM32, not from an external device. I've had this show up on various CPU families (G4, L4, F4, F7). The brute force work-around is to disable the I2C via __HAL_I2C_DISABLE() then re-initialize it via MX_I2Cx_Init() to make sure all the HAL layer variables get reset correctly along with the I2C hardware.

I haven't spent the time to figure out if this is a HAL issue, user code issue or external hardware issue (i.e. maybe ringing or noise coupled onto the signals).

ABric.2
Associate II

Hi Bob,

Thanks for the reply. I did has you explain and it solves my issue !

Best regards,

Antoine