2019-04-09 02:45 AM
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,
Solved! Go to Solution.
2019-10-30 09:03 AM
Hello @Mathieu Garivet ,
This issue is fixed in the STM32CubeF0 V1.11.0.
Thanks for bringing this limitation to our attention.
Thanks
Imen
2019-04-09 06:28 AM
Hello @Mathieu Garivet ,
We will check this issue internally and come back to you soon.
Regards,
Imen
2019-10-30 09:03 AM
Hello @Mathieu Garivet ,
This issue is fixed in the STM32CubeF0 V1.11.0.
Thanks for bringing this limitation to our attention.
Thanks
Imen