STM32C092GCU6: FDCAN interrupt handler name mismatch

[Vric]

Hello,

I may have found a bug related to the STM32C092GCU6 MCU and the FDCAN peripheral.

I created a new project and experienced issues with FDCAN reception: no RX messages were received, and the callback

HAL_FDCAN_RxFifo0Callback() was never triggered.

 After several days of troubleshooting, I discovered a possible mismatch between the startup file and the generated interrupt handler names.

 In startup_stm32c092gcux.s, the following interrupt vectors are defined: 

    .word FDCAN_IT0_IRQHandler    /* FDCAN global interrupt 0 */
    .word FDCAN_IT1_IRQHandler    /* FDCAN global interrupt 1 */

However, when generating code with STM32CubeMX, the following interrupt handlers are created in stm32c0xx_it.c: 

    void FDCAN1_IT0_IRQHandler(void)
    {
        HAL_FDCAN_IRQHandler(&hfdcan1);
    }
 

    void FDCAN1_IT1_IRQHandler(void)
    {
        HAL_FDCAN_IRQHandler(&hfdcan1);
    }

As a result, the startup file expects FDCAN_IT0_IRQHandler / FDCAN_IT1_IRQHandler,

but the generated code provides FDCAN1_IT0_IRQHandler / FDCAN1_IT1_IRQHandler.

Because of this mismatch, the FDCAN interrupts are never handled.

I am not sure whether this is a configuration issue on my side, or a bug

in the startup file or STM32CubeMX code generation for this device.

Attached you can find:

- the .ioc file

- startup_stm32c092gcux.s

- stm32c0xx_it.c 

[mƎALLEm]

Hello,

I'm not sure that's a CubeMx issue.

I've already created a project in this post CAN FD network normal mode does not work with NUCLEO-C092RC boards and the interrupt worked fine.

Generating the code based on your attached file I have the following lines in the .s file:

  .word  FDCAN1_IT0_IRQHandler             /* FDCAN1 interrupt request 0 pending          */
  .word  FDCAN1_IT1_IRQHandler             /* FDCAN1 interrupt request 1 pending          */

I think you are using CubeMx 6.16.0 and the latest version is 6.17.0 which points to the Cube HAL C0 V1.4.0..

I suspect something was wrong in the HAL which 6.16.0 was pointing to. (Not sure but this is my thought).

The startup file (.s) is not generated by CubeMx but rather a copy from the HAL package, That's why I'm telling this is not a CubeMx issue.

[Vric]

Hello,

yes, I am using CubeMX 6.16.0, so that could indeed be the cause of the problem.

It would be great if you could try generating the project with CubeMX 6.16.0

on your side as well, to check whether the same behavior occurs.

[mƎALLEm]

---

@Vric wrote:

Hello,

yes, I am using CubeMX 6.16.0, so that could indeed be the cause of the problem.

It would be great if you could try generating the project with CubeMX 6.16.0

on your side as well, to check whether the same behavior occurs.

---

The recommendation is to use the latest version of all stuff: CubeMx, HAL version etc .. If the problem doesn't show in this condition nothing to do from our side because it was fixed in the latest version(s) of the environment.

I invite you to use your CubeMx version but in the Project manager use the latest version of the HAL: