CAN driver - comparison between HAL Driver and Standard Peripheral Driver

[carlo-dev-git]

From STM32F4xx Standard Peripherals Drivers V1.8.1 (27-January-2022) release notes:

stm32f4xx_can.c:

• Update to avoid race condition
  • Update CAN_Receive(), CAN_FIFORelease() & CAN_CancelTransmit() APIs to use '=' instead of '|='.

Analyzing the current code of the file stm32f4xx_hal_can.c you can still see the use of SET_BIT().
Is this race condition not present in the HAL driver and/or has it been resolved elsewhere?

[ASEHSTM]

Hello @carlo-dev-git,

Thank you for your report. This point has been tracked internally.

With Regards,

[ASEHSTM]

ST Internal Reference: 202753

[ASEHSTM]

Hello @carlo-dev-git,

After further analysis, we confirmed that the use of the operator = is unnecessary for all HAL CAN processes. The requirement for this operator is limited to the interrupt process, where the fix has been successfully implemented. Below is the macro that addresses the race condition issue:

#define __HAL_CAN_CLEAR_FLAG(__HANDLE__, __FLAG__) \
  ((((__FLAG__) >> 8U) == 5U) ? (((__HANDLE__)->Instance->TSR) = (1U << ((__FLAG__) & CAN_FLAG_MASK))) : \
   (((__FLAG__) >> 8U) == 2U) ? (((__HANDLE__)->Instance->RF0R) = (1U << ((__FLAG__) & CAN_FLAG_MASK))) : \
   (((__FLAG__) >> 8U) == 4U) ? (((__HANDLE__)->Instance->RF1R) = (1U << ((__FLAG__) & CAN_FLAG_MASK))) : \
   (((__FLAG__) >> 8U) == 1U) ? (((__HANDLE__)->Instance->MSR) = (1U << ((__FLAG__) & CAN_FLAG_MASK))) : 0U)

Thank you,
With Regards,

[carlo-dev-git]

Hello ASEHSTM, thanks for your reply.
Please clarify the race conditions for me.

The macro is correctly used in the IRQ handler in these cases:

Row 1742:       __HAL_CAN_CLEAR_FLAG(hcan, CAN_FLAG_RQCP0);
Row 1785:       __HAL_CAN_CLEAR_FLAG(hcan, CAN_FLAG_RQCP1);
Row 1828:       __HAL_CAN_CLEAR_FLAG(hcan, CAN_FLAG_RQCP2);
Row 1877:       __HAL_CAN_CLEAR_FLAG(hcan, CAN_FLAG_FOV0);
Row 1887:       __HAL_CAN_CLEAR_FLAG(hcan, CAN_FLAG_FF0);
Row 1926:       __HAL_CAN_CLEAR_FLAG(hcan, CAN_FLAG_FOV1);
Row 1936:       __HAL_CAN_CLEAR_FLAG(hcan, CAN_FLAG_FF1);
Row 1972:       __HAL_CAN_CLEAR_FLAG(hcan, CAN_FLAG_SLAKI);
Row 1991:       __HAL_CAN_CLEAR_FLAG(hcan, CAN_FLAG_WKU);
Row 2079:       __HAL_CAN_CLEAR_FLAG(hcan, CAN_FLAG_ERRI);

In function HAL_CAN_GetRxMessage() bits CAN_RF0R_RFOM0 and CAN_RF0R_RFOM1 are set using the SET_BIT() macro:

    (...)
    /* Release the FIFO */
    if (RxFifo == CAN_RX_FIFO0) /* Rx element is assigned to Rx FIFO 0 */
    {
      /* Release RX FIFO 0 */
      SET_BIT(hcan->Instance->RF0R, CAN_RF0R_RFOM0);
    }
    else /* Rx element is assigned to Rx FIFO 1 */
    {
      /* Release RX FIFO 1 */
      SET_BIT(hcan->Instance->RF1R, CAN_RF1R_RFOM1);
    }
    (...)

this means that this function cannot be called from the IRQ callback?

In StdPeriph driver the fix addressed specifically this case.
StdPeriph driver PRE V1.8.1 (OLD)

  /* Release FIFO0 */
  if (FIFONumber == CAN_FIFO0)
  {
    CANx->RF0R |= CAN_RF0R_RFOM0;
  }
  /* Release FIFO1 */
  else /* FIFONumber == CAN_FIFO1 */
  {
    CANx->RF1R |= CAN_RF1R_RFOM1;
  }

StdPeriph driver V1.8.1 (27-January-2022)

  /* Release FIFO0 */
  if (FIFONumber == CAN_FIFO0)
  {
    CANx->RF0R = CAN_RF0R_RFOM0;
  }
  /* Release FIFO1 */
  else /* FIFONumber == CAN_FIFO1 */
  {
    CANx->RF1R = CAN_RF1R_RFOM1;
  }