cancel
Showing results for 
Search instead for 
Did you mean: 

HAL_I2C hangs when it enters I2C_WaitOnFlagUntilTimeout() function.

ty.locke
Associate II

I'm using verion 1.1.5 of the I-CUBE-LRWAN software and reading a few I2C sensors using the HAL_I2C functions.

No issues when sensors are functioning properly; however, I have run into periodic sensor failure issues while testing, either permanent or temporary, where one of the I2C lines may be held low or enter the wrong state.

In these cases, once the HAL TX enters the I2C_WaitOnFlagUntilTimeout() function, timeout is never reached and the entire application hangs until the board is reset.

Has anyone encountered a similar issue or have an advice on this problem?

In the real world there are bound to be issues here and there with defects and bad communication once in a while, ideally this should not freeze the entire application if the STM32 fails to communicate with a slave device properly during a single read.

Code snippet below:

In a failed scenario, I2C_FLAG_BUSY remains set and it appears HAL_GetTick() never exceeds Tickstart to generate the HAL_TIMEOUT return.

static HAL_StatusTypeDef I2C_WaitOnFlagUntilTimeout(I2C_HandleTypeDef *hi2c, uint32_t Flag, FlagStatus Status, uint32_t Timeout, uint32_t Tickstart)

{

 while(__HAL_I2C_GET_FLAG(hi2c, Flag) == Status)

 {

  if(Timeout != HAL_MAX_DELAY)

  {

   if((Timeout == 0U)||((HAL_GetTick() - Tickstart ) > Timeout))

   {

    hi2c->State= HAL_I2C_STATE_READY;

    hi2c->Mode = HAL_I2C_MODE_NONE;

    /* Process Unlocked */

    __HAL_UNLOCK(hi2c);

    return HAL_TIMEOUT;

   }

  }

 }

 return HAL_OK;

}

12 REPLIES 12
Gumer RoMa
Associate II

I got the same issue with HAL_GetTick() function. I notice it gets stuck when I call a HAL_I2C function FROM an interruption (in my case, from an UART interruption). It works fine when called from the main loop.

Hope this helps to find a work around in your code.

MBertocchi
Associate II

I also had this problem and I firmly believed that it was a software bug, but after hours of testing I realized that the problem was on the priority I gave to the interrupt. the SysTick has a priority 0 interrupt while the uart has to be set to priority 1, and then you will see that everything works.

MBertocchi
Associate II

I also had this problem and I firmly believed that it was a software bug, but after hours of testing I realized that the problem was on the priority I gave to the interrupt. the SysTick has a priority 0 interrupt while the uart has to be set to priority 1, and then you will see that everything works.