__HAL_LOCK routines with no __HAL_UNLOCK

[AndyJT]

Posted on November 03, 2016 at 15:39

Hi,

__HAL_LOCK has never bothered us previously with v 1.3 HAL library.However, I have updated to 1.5.1 STM32F7 lib and found that stm32f7xx_hal_sai caused us problems.It was related to the handle being kept locked after calling HAL_SAI_DMAStop when no DMA transfer was already happening. (ie, hdma->Lock = HAL_LOCKED)I notice there are lots of routines which lock the SAI handle, yet return without unlocking. Shouldn't all return paths unlock the handle ??For example:HAL_StatusTypeDef HAL_SAI_DMAStop(SAI_HandleTypeDef *hsai){  /* Process Locked */  __HAL_LOCK(hsai);  /* Disable the SAI DMA request */  hsai->Instance->CR1 &= ~SAI_xCR1_DMAEN;  /* Abort the SAI DMA Streams */  if(hsai->hdmatx != NULL)  {    if(HAL_DMA_Abort(hsai->hdmatx) != HAL_OK)    {  // SHOULD INSERT THIS HERE ????? __HAL_UNLOCK(hsai);      return HAL_ERROR;    }  }  if(hsai->hdmarx != NULL)  {    if(HAL_DMA_Abort(hsai->hdmarx) != HAL_OK)    {  // SHOULD INSERT THIS HERE ????? __HAL_UNLOCK(hsai);      return HAL_ERROR;    }  }    /* Disable SAI peripheral */  SAI_Disable(hsai);  hsai->State = HAL_SAI_STATE_READY;  /* Process Unlocked */  __HAL_UNLOCK(hsai);  return HAL_OK;} #stm32f7 #dogfooding

[Tesla DeLorean]

Posted on November 03, 2016 at 17:00

Shouldn't all return paths unlock the handle ??

You'd think, but the library is disappointingly poor in its implementation and testing.