FDCAN Read causes a reinitialisation of the entire CAN peripheral on STM32

Hello, I'm trying to develop a piece of firmware using embedded coder that is mainly based around receiving data via FDCAN, performing different calculations on the data and sending the results out via FDCAN again.

The first issue I encountered when running a PIL performance measurement, which showed that each FDCAN Read block takes 2 ms to run. Given that you need one FDCAN Read block per message (as per my understanding at least), I exceeded run times of 50 ms, which is unacceptable for my use case.

Upon diving deeper into the generated code, I have discovered that each FDCAN Read block generates to a read instruction, but also to a reinitialisation. It appears as if the reinitialisation gets executed several times in one model step.

Is there any way to prevent the initialisation? The most obvious way would be to implement the read code myself using custom C functions, however, I would like to use the CAN FD Unpack blocks for parsing the CAN frames. I haven't found anything documented here or in the documentation for the block itself.

Any help is greatly appreaciated!

Best regards

Felix Kuhlmann

Answer 1

[Isha]

Hello,

This behavior is expected from the FDCAN Read block, it generates both initialization and read code in the step function, which is why you see repeated reinitialization and high execution time.

There is no option to disable this in the block itself.

Recommended approach:

• Move FDCAN initialization to one-time init (model initialize)
• Implement the receive using custom C / S-Function (FIFO read only)
• Output CAN_FD_MESSAGE_BUS → continue using CAN FD Unpack

This works because:

• CAN FD Unpack just needs a bus input, independent of how you receive frames, CAN FD Unpack - Unpack individual signals from CAN FD messages - Simulink.
• One-time init can be done using Initialize Function, which runs only at startup, Initialize Function - Execute subsystem on model initialize event - Simulink.

You can’t stop reinit in the block as it use custom receive and keep Unpack for decoding.

Hope this helps.

Answer 2

[Felix]

Hey Isha,

Thank you for your reply. I have also reached out to support and they have provided me with the hint that by setting the "Timeout" option of each FDCAN-Read block to zero, I was able to inhibit the frequent reinitialisation. This could be seen both in the code and in the PIL measurement, which showed a significant drop in run time in comparison to the run I mentioned in the OP.

If I was to write this myself in C, how would I ensure to output the data in the CAN_FD_MESSAGE_BUS struct from a custom C block? Is there a special header file I need to include to have support for this type?

Thank you for your help thus far!

[Saurav Shandilya]

Hi @Felix

Beside setting timeout to 0, observed latency in FDCAN Read block is likely influenced by PIL profiling overhead and may not reflect the actual execution time on hardware.

During PIL execution, the measured timing includes additional overhead from:

• Timer reads inserted for profiling instrumentation (function entry and exit)
• Serialization of block outputs back to the host
• Communication latency for host–target data exchange (e.g., UART/RTIOStream)

Since this overhead is incurred for each instrumented block, it can scale with:

• Number of FDCAN Read blocks in the model
• Number and width of output signals

As a result, block-level execution times in PIL can appear significantly higher than the true runtime cost.

Below example on using Execution profiler block can help you with getting accurate execution time on hardware.

Profile STM32 Algorithms in Real-Time - MATLAB & Simulink