Bug report: STM32F4 Cube 1.18.0 HAL CAN driver generates incorrect code.

[EGibs.0]

Cube 1.18.0 appears to generate HAL CAN code in can.c and can.h which is aimed at the 1.21.0 redisigned CAN driver.

The code refers to member variables which do not exist in the 1.18.0 register structures, for example:

 hcan1.Init.SyncJumpWidth = CAN_SJW_1TQ;

 hcan1.Init.TimeSeg1 = CAN_BS1_7TQ;

 hcan1.Init.TimeSeg2 = CAN_BS2_8TQ;

Significantly, the new CAN driver (redesigned in version 1.19.0) appears to have no documentation, so cannot easily be used.

The old code is rendered unusable by the above bug, so neither version can be used.

In trying to find a solution to this problem I reinstalled CubeMX from scratch, removing all downloaded driver installations, and only installed the F4 version 1.18.0.

[EGibs.0]

Actually, it looks like it is only the MX_CAN1_Init() function which is affected, and it is only the names of the CAN_InitTypeDef stucture which are different.

The other generated code looks correct, and equivalent to previous versions.

[Imen.D]

Hello @Community member​ ,

The HAL CAN driver is reworked in STM32CubeF4 formware package version 1.19.0 to bypass limitations on CAN present with previous HAL CAN driver versions.

So, the new HAL CAN driver is the recommended version to use and it is located as usual in Drivers/STM32F4xx_HAL_Driver/Src and Drivers/STM32F4xx_HAL_Driver/Inc folders. It can be enabled through switch HAL_CAN_MODULE_ENABLED in stm32f4xx_hal_conf.h

The legacy HAL CAN driver is also present in the release in Drivers/STM32F4xx_HAL_Driver/Src/Legacy and Drivers/STM32F4xx_HAL_Driver/Inc/Legacy folders for software compatibility reasons. Its usage is not recommended as deprecated. It can however be enabled through switch HAL_CAN_LEGACY_MODULE_ENABLED in stm32f1xx_hal_conf.h

Please find below a short migration guide:

• Fields of CAN_InitTypeDef structure are renamed: SJW to SyncJumpWidth, BS1 to TimeSeg1, BS2 to TimeSeg2, ABOM to AutoBusOff, AWUM to AutoWakeUp, NART to AutoRetransmission (inversed), RFLM to ReceiveFifoLocked and TXFP to TransmitFifoPriority
• HAL_CAN_Init() is split into both HAL_CAN_Init() and HAL_CAN_Start()
• HAL_CAN_Transmit() is replaced by HAL_CAN_AddTxMessage() to place Tx request, then HAL_CAN_GetTxMailboxesFreeLevel() for polling until completion
• HAL_CAN_Transmit_IT() is replaced by HAL_CAN_ActivateNotification() to enable transmission with interrupt mode, then HAL_CAN_AddTxMessage() to place Tx request
• HAL_CAN_Receive() is replaced by HAL_CAN_GetRxFifoFillLevel() for polling until reception, then HAL_CAN_GetRxMessage() to get Rx message
• HAL_CAN_Receive_IT() is replaced by HAL_CAN_ActivateNotification() to enable reception with interrupt mode, then HAL_CAN_GetRxMessage() in the receive callback to get Rx message
• HAL_CAN_Sleep() is renamed to HAL_CAN_RequestSleep()
• HAL_CAN_TxCpltCallback() is split into HAL_CAN_TxMailbox0CompleteCallback(), HAL_CAN_TxMailbox1CompleteCallback() and HAL_CAN_TxMailbox2CompleteCallback()
• HAL_CAN_RxCpltCallback() is split into HAL_CAN_RxFifo0MsgPendingCallback() and HAL_CAN_RxFifo1MsgPendingCallback()

Here is attached the presentation on how to develop a CAN application with new API and how to migrate from old API to new API. This will help you to have more idea on how to configure CAN and use HAL functions from new CAN API.

With Regards,

Imen.