HAL Bug Report on STM32F0 v1.9.0 : CAN Receive functions wrongly set RTR bit

[Mathieu Garivet]

Hi,

There is a bug in the release v1.9.0 of the STM32F0 HAL library.

In CAN_Receive_IT() and CAN_Receive() functions the RTR value of the pRxMsg is wrongly set.

Here is what is done:

pRxMsg->RTR = (CAN_RI0R_RTR & hcan->Instance->sFIFOMailBox[FIFONumber].RIR) >> CAN_RI0R_RTR_Pos;

with CAN_RI0R_RTR_Pos = 1;

It means that if the message is a Remote one, the pRxMsg->RTR is equal to 1.

However the CAN lib header file mentions:

  uint32_t RTR;         /*!< Specifies the type of frame for the received message.
                             This parameter can be a value of @ref CAN_remote_transmission_request */

With CAN_remote_transmission_request values defined as:

/** @defgroup CAN_remote_transmission_request CAN Remote Transmission Request
  * @{
  */
#define CAN_RTR_DATA                (0x00000000U)  /*!< Data frame */
#define CAN_RTR_REMOTE              (0x00000002U)  /*!< Remote frame */
/**
  * @}
  */

And that does not match ! CAN_RTR_REMOTE is equal to 2.

In the v1.7.0 release, the bit shift by CAN_RI0R_RTR_Pos was not present and thus RTR was equal to 2 in case of a Remote message.

So I think this line should be revert back to its v1.7.0 version (in order to be handled like the IDE bit for example).

Best regards,

[Imen.D]

Hello @Mathieu Garivet​ ,

We will check this issue internally and come back to you soon.

Regards,

Imen

[Imen.D · Accepted solution]

Hello @Mathieu Garivet​ ,

This issue is fixed in the STM32CubeF0 V1.11.0.

Thanks for bringing this limitation to our attention.

Thanks

Imen