Bug in HAL? Same CAN message's RTR is 2 in f4xx_hal_can and 1 in l4xx_hal_can.c

[FS.1]

I am sending an RTR message to two different micro controllers. On an F412 an RTR value "2" arrives, on an L471 an RTR value "1" arrives.

When looking at the code in f4xx_hal_can.c from the STM32Cube FW_F4 V1.25.0 package at around line 1560, I can see:

pHeader->RTR = (CAN_RI0R_RTR & hcan->Instance->sFIFOMailBox[RxFifo].RIR);
pHeader->DLC = (CAN_RDT0R_DLC & hcan->Instance->sFIFOMailBox[RxFifo].RDTR) >> CAN_RDT0R_DLC_Pos;
pHeader->FilterMatchIndex = (CAN_RDT0R_FMI & hcan->Instance->sFIFOMailBox[RxFifo].RDTR) >> CAN_RDT0R_FMI_Pos;
pHeader->Timestamp = (CAN_RDT0R_TIME & hcan->Instance->sFIFOMailBox[RxFifo].RDTR) >> CAN_RDT0R_TIME_Pos;

While in the l4xx_hal_can.c from the STM32Cube FW_L4 V1.15.1 package I find this:

pHeader->RTR = (CAN_RI0R_RTR & hcan->Instance->sFIFOMailBox[RxFifo].RIR) >> CAN_RI0R_RTR_Pos;
pHeader->DLC = (CAN_RDT0R_DLC & hcan->Instance->sFIFOMailBox[RxFifo].RDTR) >> CAN_RDT0R_DLC_Pos;
pHeader->FilterMatchIndex = (CAN_RDT0R_FMI &  hcan->Instance->sFIFOMailBox[RxFifo].RDTR) >> CAN_RDT0R_FMI_Pos;
pHeader->Timestamp = (CAN_RDT0R_TIME & hcan->Instance->sFIFOMailBox[RxFifo].RDTR) >> CAN_RDT0R_TIME_Pos;

Here the variable is shifted by 1 which changes the value from 2 to 1.

Is this shift operation missing the the f4 library?

Cheers

[Imen.D]

Hello @FS.1​ ,

Thank you for reported this issue.

I fact, in the header file, it is indicated that the RTR field of the structure CAN_RxHeaderTypeDef can have the value CAN_RTR_DATA (0) or CAN_RTR_REMOTE (2) and not the value of register's field  (0 : data frame or 1 : remote frame). It means that the shift should not be performed to have the expected value.

So, the implementation in the STM32L4Cube firmware should be aligned with the one in the STM32CubeF4 firmware (without the shift).

Best Regards,

Imen

[FS.1]

Hello Imen,

thanks for pointing to the definitions in the header.

As I see it, the values 0 and 2 are there in both versions.

#define CAN_RTR_DATA                (0x00000000U)  /*!< Data frame   */
#define CAN_RTR_REMOTE              (0x00000002U)  /*!< Remote frame */

And in the L4 firmware, they are shifted to get it to be 0 and 1.

From the user perspective, I would have expected it to be 0 and 1 since it's an onn/off flag.

Is there a reason to make it 0 and 2?

Do I understand you correctly that for the L4 firmware (where it is 0 and 1 currently) it will be changed to 0 and 2? If so, when will it happen? It's is a breaking change after all.

Cheers