Posted on April 04, 2016 at 11:47Hi @all,
I'm using HAL library V1.4 in my current project. While checking error handling functions, I came across some problems with interrupt handling in combination with FreeRTOS (
https://sourceforge.net/p/freertos/discussion/382005/thread/ca400abe
/). While analyzing this problem, I found that the HAL library does busy waiting within some of the interrupt handler functions,e.g.:
HAL_DMA_IRQHandler(i2c_handle)
calls
static HAL_StatusTypeDef I2C_WaitOnSTOPFlagUntilTimeout(I2C_HandleTypeDef *hi2c, uint32_t Timeout)
{
uint32_t tickstart = 0x00;
->tickstart = HAL_GetTick();
->while(__HAL_I2C_GET_FLAG(hi2c, I2C_FLAG_STOPF) == RESET)
{
/* Check if a NACK is detected */
if(I2C_IsAcknowledgeFailed(hi2c, Timeout) != HAL_OK)
{
return HAL_ERROR;
}
/* Check for the Timeout */
--->if((Timeout == 0) || ((HAL_GetTick()-tickstart) > Timeout))
{
hi2c->ErrorCode |= HAL_I2C_ERROR_TIMEOUT;
hi2c->State= HAL_I2C_STATE_READY;
/* Process Unlocked */
__HAL_UNLOCK(hi2c);
return HAL_TIMEOUT;
}
}
return HAL_OK;
}
In the case of an error, the calling IRQ handler blocks for 25 ms (at 1ms tick). But even without errors, I would prefer not to have busy-waiting IRQs...
To circumvent this, I now would like to move the IRQ handler call into an low priority RTOS thread which is then unblocked by the IRQ.
My question: Is it save to call the HAL IRQ handler functions from within normal code context instead of interrupt context? This is not only for I2C but for all peripherals.
Thanks for your help!
