I am working with STM32G4 NUCLEO and STM32CubeIDE. Created a project to use FDCAN2 (classic mode) to evaluete CAN comm in polling mode. On FDCAN2 CAN messages are only received when I additionally activate FDCAN1.

Hi MBast.3 ,

If the clock divider is common for all FDCAN instances then is necessary to set the divider in FDCAN1. And then the FDCAN1 can be disabled. Activation of FDCAN1 is necessary only for accessing the divider in FDCAN1 register. If register is set then FDCN1 can be disabled (no clock to FDCAN1).

Regards

Igor

Hi Igor,

for my project the code is generated using STM32cubeIDE. I have compared the generated code.

With FDCAN1 and FDCAN2 activated the generated code of function SystemClock_Config()

has the following last line:

void SystemClock_Config(void)

{

 ...

 LL_RCC_SetFDCANClockSource(LL_RCC_FDCAN_CLKSOURCE_PCLK1);

}

When generating the code with only FDCAN2 activated this last line is missing.

After adding this line manually to SystemClock_Config() my project works fine without FDCAN1.

Maybe there is a problem with the code generator.

Regards

MBast.3

Hi MBast.3 ,

I have reported this code generation problem in development team. It will be corrected in future versions of code generator (if mistake will be confirmed).

Thanks and Regards

Igor

Hi Igor,

another issue may be this statement in function HAL_FDCAN_INIT():

/* Check FDCAN instance */

if (hfdcan->Instance == FDCAN1)

{

  /* Configure Clock divider */

  FDCAN_CONFIG->CKDIV = hfdcan->Init.ClockDivider;

}

Without activating FDCAN1 there is no possibility to set the clock devider via code generation.

In my case there was no problem because the reset value of the CKDIV register is 0 and this

means 'devide by 1'.

As a work-around I have put two lines of code in a USER CODE section of main() to avoid overwriting at the next

code generation.

 /* USER CODE BEGIN SysInit */

 LL_RCC_SetFDCANClockSource(LL_RCC_FDCAN_CLKSOURCE_PCLK1);

 FDCAN_CONFIG->CKDIV = FDCAN_CLOCK_DIV1;

 /* USER CODE END SysInit */

Regards

MBast.3

Hi MBast.3 ,

OK - we will check also this behavior and correct it.

Regards

Igor