Received FDCAN 64bytes data but FDCAN_RxHeader.datalength is 15, is it a bug?

[dqsh06]

Split from this thread.

thanks to @Ozone @Karl Yamashita,

this afternoon I have tried to extend can2.0 to canfd with my project of stm32g474vet6.  I found some strange things, I think there may be a bug of stm32g474vet6 fdcan module.

I modifed the FDCAN_TxHeader to FD_Frame and datelength to 64byte. for  FDCAN_RxHeader, almost nothing to modify. then i used an app on PC to send a 64bytes CAN message,  then my code received the 64bytes message and copied to rxbuffer, the rxbuffer had 64bytes data, but FDCAN_RxHeader.datalength is 15. it is not 64. 

i think this is a bug of stm32g474vet6, it received 64bytes data but FDCAN_RxHeader.datalength is 15. I have no can tool now (with used by other people), when i have the can tool, i will take screenshot to show the strange thing.

hello @mƎALLEm @Saket_Om did you meet FDCAN received 64bytes but  FDCAN_RxHeader.datalength is 15? is there some configuration I miss?

 

Thanks a lot!

[mƎALLEm]

---

@dqsh06 wrote:

hello @mƎALLEm @Saket_Om did you meet FDCAN received 64bytes but  FDCAN_RxHeader.datalength is 15? is there some configuration I miss?

---

This is not a bug and the information is provided in the reference manual RM0440 Rev 9:

DLC=15 means 64 bytes!

[Karl Yamashita]

When using ST's data structure for FDCAN_RxHeaderTypeDef, you should look what the reference is for DataLength, which they reference FDCAN_data_length_code 

/**
 * @brief FDCAN Rx header structure definition
 */
typedef struct
{
 uint32_t Identifier; /*!< Specifies the identifier.
 This parameter must be a number between:
 - 0 and 0x7FF, if IdType is FDCAN_STANDARD_ID
 - 0 and 0x1FFFFFFF, if IdType is FDCAN_EXTENDED_ID */

 uint32_t IdType; /*!< Specifies the identifier type of the received message.
 This parameter can be a value of @ref FDCAN_id_type */

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

 uint32_t DataLength; /*!< Specifies the received frame length.
 This parameter can be a value of @ref FDCAN_data_length_code */

 uint32_t ErrorStateIndicator; /*!< Specifies the error state indicator.
 This parameter can be a value of @ref FDCAN_error_state_indicator */

 uint32_t BitRateSwitch; /*!< Specifies whether the Rx frame is received with or without bit
 rate switching.
 This parameter can be a value of @ref FDCAN_bit_rate_switching */

 uint32_t FDFormat; /*!< Specifies whether the Rx frame is received in classic or FD
 format.
 This parameter can be a value of @ref FDCAN_format */

 uint32_t RxTimestamp; /*!< Specifies the timestamp counter value captured on start of frame
 reception.
 This parameter must be a number between 0 and 0xFFFF */

 uint32_t FilterIndex; /*!< Specifies the index of matching Rx acceptance filter element.
 This parameter must be a number between:
 - 0 and (SRAMCAN_FLS_NBR-1), if IdType is FDCAN_STANDARD_ID
 - 0 and (SRAMCAN_FLE_NBR-1), if IdType is FDCAN_EXTENDED_ID */

 uint32_t IsFilterMatchingFrame; /*!< Specifies whether the accepted frame did not match any Rx filter.
 Acceptance of non-matching frames may be enabled via
 HAL_FDCAN_ConfigGlobalFilter().
 This parameter can be 0 or 1 */

} FDCAN_RxHeaderTypeDef;

 

You can see how they defined the values

/** @defgroup FDCAN_data_length_code FDCAN Data Length Code
 * @{
 */
#define FDCAN_DLC_BYTES_0 ((uint32_t)0x00000000U) /*!< 0 bytes data field */
#define FDCAN_DLC_BYTES_1 ((uint32_t)0x00010000U) /*!< 1 bytes data field */
#define FDCAN_DLC_BYTES_2 ((uint32_t)0x00020000U) /*!< 2 bytes data field */
#define FDCAN_DLC_BYTES_3 ((uint32_t)0x00030000U) /*!< 3 bytes data field */
#define FDCAN_DLC_BYTES_4 ((uint32_t)0x00040000U) /*!< 4 bytes data field */
#define FDCAN_DLC_BYTES_5 ((uint32_t)0x00050000U) /*!< 5 bytes data field */
#define FDCAN_DLC_BYTES_6 ((uint32_t)0x00060000U) /*!< 6 bytes data field */
#define FDCAN_DLC_BYTES_7 ((uint32_t)0x00070000U) /*!< 7 bytes data field */
#define FDCAN_DLC_BYTES_8 ((uint32_t)0x00080000U) /*!< 8 bytes data field */
#define FDCAN_DLC_BYTES_12 ((uint32_t)0x00090000U) /*!< 12 bytes data field */
#define FDCAN_DLC_BYTES_16 ((uint32_t)0x000A0000U) /*!< 16 bytes data field */
#define FDCAN_DLC_BYTES_20 ((uint32_t)0x000B0000U) /*!< 20 bytes data field */
#define FDCAN_DLC_BYTES_24 ((uint32_t)0x000C0000U) /*!< 24 bytes data field */
#define FDCAN_DLC_BYTES_32 ((uint32_t)0x000D0000U) /*!< 32 bytes data field */
#define FDCAN_DLC_BYTES_48 ((uint32_t)0x000E0000U) /*!< 48 bytes data field */
#define FDCAN_DLC_BYTES_64 ((uint32_t)0x000F0000U) /*!< 64 bytes data field */

 

 

[dqsh06]

hello @Karl Yamashita 

my misunderstanding.

Thanks a lot.

dqsh06

[Ozone]

CAN FD is a different standard.
It is an extension of standard CAN, but with necessary differences to differentiate between both kinds of nodes, and to facilitate higher baudrates.

You can run a CAN FD network instead, if those improvements help you.
Although I would avoid a network mixing both kinds of nodes, especially if you have no real expertise with CAN.

On a related note, I would recommend the CiA (Can in Automation) organisation and website in this regard : https://www.can-cia.org/

They have a lot of documents and expertise in this field, including CAN FD and CAN XL, although not everything for free.

[dqsh06]

hello @Ozone ,

Thanks for your reply!

as my project situation, this is a new project and no legacy CAN network and CAN nodes, I am the architect and I am the designer, I can choose to use CANFD or CAN2.0, what i like, what it is. so I will try to use CANFD with the benefit of 64bytes payload.

I will check  https://www.can-cia.org/

thank you!

 

   

[Ozone]

That is ok, if your environment and bus lengths allows for it.
As mentioned, for our application it makes no sense, we can't even reach the 1 MBit rate of standard CAN. Besides the compatibility issue.