STM32G4 FW 1.5.2 FDCan Error/Bug?

[Framet]

Hi guys

I've upgraded from 1.5.1 to 1.5.2 and I'm receiving HardFaults when using FDCAN

\STM32Cube\Repository\STM32Cube_FW_G4_V1.5.1\Drivers\STM32G4xx_HAL_Driver\Src\stm32g4xx_hal_fdcan.c

FW 1.5.1 Line: 3493

 

 

/* Write Tx payload to the message RAM */
 for (ByteCounter = 0; ByteCounter < DLCtoBytes[pTxHeader->DataLength >> 16U]; ByteCounter += 4U)
 {
 *TxAddress = (((uint32_t)pTxData[ByteCounter + 3U] << 24U) |
 ((uint32_t)pTxData[ByteCounter + 2U] << 16U) |
 ((uint32_t)pTxData[ByteCounter + 1U] << 8U) |
 (uint32_t)pTxData[ByteCounter]);
 TxAddress++;
 }

 

 

FW 1.5.2 Line: 3523

 

 

 /* Write Tx payload to the message RAM */
 for (ByteCounter = 0; ByteCounter < DLCtoBytes[pTxHeader->DataLength]; ByteCounter += 4U)
 {
 *TxAddress = (((uint32_t)pTxData[ByteCounter + 3U] << 24U) |
 ((uint32_t)pTxData[ByteCounter + 2U] << 16U) |
 ((uint32_t)pTxData[ByteCounter + 1U] << 8U) |
 (uint32_t)pTxData[ByteCounter]);
 TxAddress++;
 }

 

 

 

I've not investigated much time but it looks like to me that the DataLength Code is not correctly shifted?

This results access in the DLCtoBytes[16] with an index far beyond 16?

I'm reverting back to 1.5.1 for the moment.

 

Cheers 

Franco

[KDJEM.1]

Hello @Framet ,

Thank you for reporting this issue.

Could you please explain your setup and the use case leading to this HardFaults?

Could you please share the code?

Thank you.

Kaouthar

[Framet]

Hi Kaouthar

We are using an STM32G431CU. It collects sensor data and publishes those data via the CANFD bus. We use all 64 Bytes of the CANFD Payload and the publish frequency of a single CAN Message is around 1khz.

It does only crash when starting the data stream.

We currently use STM32Cube_FW_G4_V1.5.1 which does work. In STM32Cube_FW_G4_V1.5.2 it does not work probably because of the described code difference above.

The Project is created with STM32CubeMX 6.7.0 using HAL Library. The used STM32CubeIDE is Version 1.11.0.

There is no custom code for sending the CAN Messages. The default HAL Library is used.

[KDJEM.1]

Hi @Framet ,

Thanks for this clarification.  To check the issue could you please share your .ioc file and  the code around HAL_FDCAN_AddMessageToTxFifoQ function ?

 

Also, could you please check FDCAN_TxHeaderTypeDef struct, especially the DataLength because the shift is now made by the HAL and not the define used for dataLength.

Thank you.

Kaouthar

[Framet]

---

Also, could you please check FDCAN_TxHeaderTypeDef struct, especially the DataLength because the shift is now made by the HAL and not the define used for dataLength.

---

We fill the DataLength according to the defines here:

#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 */

So from 1.5.1 to 1.5.2 did this change in the HAL Library that the user has not use the DataLength Code anymore?
I will have a look as soon as i can.

[KDJEM.1]

Hi @Framet ,

The definitions of the FDCAN_DLC_BYTES_X macros are now shift-free so they comply to the definition of the DLC stm32g4xx_hal_driver/Inc/stm32g4xx_hal_fdcan.h. Please take a look to this Github.

/** @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)0x00000001U) /*!< 1 bytes data field */
#define FDCAN_DLC_BYTES_2 ((uint32_t)0x00000002U) /*!< 2 bytes data field */
#define FDCAN_DLC_BYTES_3 ((uint32_t)0x00000003U) /*!< 3 bytes data field */
#define FDCAN_DLC_BYTES_4 ((uint32_t)0x00000004U) /*!< 4 bytes data field */
#define FDCAN_DLC_BYTES_5 ((uint32_t)0x00000005U) /*!< 5 bytes data field */
#define FDCAN_DLC_BYTES_6 ((uint32_t)0x00000006U) /*!< 6 bytes data field */
#define FDCAN_DLC_BYTES_7 ((uint32_t)0x00000007U) /*!< 7 bytes data field */
#define FDCAN_DLC_BYTES_8 ((uint32_t)0x00000008U) /*!< 8 bytes data field */
#define FDCAN_DLC_BYTES_12 ((uint32_t)0x00000009U) /*!< 12 bytes data field */
#define FDCAN_DLC_BYTES_16 ((uint32_t)0x0000000AU) /*!< 16 bytes data field */
#define FDCAN_DLC_BYTES_20 ((uint32_t)0x0000000BU) /*!< 20 bytes data field */
#define FDCAN_DLC_BYTES_24 ((uint32_t)0x0000000CU) /*!< 24 bytes data field */
#define FDCAN_DLC_BYTES_32 ((uint32_t)0x0000000DU) /*!< 32 bytes data field */
#define FDCAN_DLC_BYTES_48 ((uint32_t)0x0000000EU) /*!< 48 bytes data field */
#define FDCAN_DLC_BYTES_64 ((uint32_t)0x0000000FU) /*!< 64 bytes data field */
/**

Thank you.

Kaouthar

[Nico_S]

i ran into the same issue.. If you do such changes why don't you add some checks to the code? This is really bad.. 

The quality of the HAL libraries is insane.