Skip to main content
Associate
February 17, 2026
Solved

STM32H743 FDCAN bootloader with Classic CAN

  • February 17, 2026
  • 2 replies
  • 308 views

Hello everyone!

In our system we have a set of subsystem that uses F4/F7 MCUs and one - with STM32H743 MCU.

We want to use system CAN bootloader for all of them. Everything seems ok, except STM32H743 device. From AN2606 we know that it starts in bootloader with such FDCAN config: 'Connection bit rate 250 kbit/s', 'Data bit rate 1000 kbit/s', 'FrameFormat = FDCAN_FRAME_FD_BRS'. So, it waits for FD frames.

The question is: can we use default CAN (not FD) with 250 kbit/s bitrate to update every subsystem there? Will STM32H7 recieve default frames and work in default  CAN formats?

Best answer by mƎALLEm

Not possible for the bootloader to understand CAN2.0 frames as it was configured in CAN-FD with bitrate switching in the bootloader.

So to answer your question: no it couldn't receive classic frames but with no error propagation on the CAN bus. The bitrate in the data phase (1Mb/s) is different from the one set in the Nominal phase (250kb/s). CAN2.0 couldn't manage this bitrate switching. You need a host bootloader with FD/bitrate switching activated with the same bitrates (250kb/s / 1Mb/s).

2 replies

mƎALLEm
Technical Moderator
February 17, 2026

Hello @CuuuSyn and welcome to the ST community,

According to the this part from the table Table 123 / AN2606 "Introduction to system memory boot mode on STM32 MCUs" rev 69:

mALLEm_0-1771326558987.png

And to the AN5405 "How to use FDCAN bootloader protocol on STM32 MCUs" rev 7:

mALLEm_1-1771326953864.png

That's not possible.

You need to have a separate the CAN bus. One for Classic CAN and another for FDCAN format.

"To give better visibility on the answered topics, please click on ""Accept as Solution"" on the reply which solved your issue or answered your question."
CuuuSynAuthor
Associate
February 17, 2026

That looks a bit strange.. FDCAN peripheral has backward compatibility with standard CAN, so it should be able to recieve standard frames. So, it seems that there have to be a backward compatibility in bootloader interface too..

mƎALLEm
Technical Moderator
February 17, 2026

@CuuuSyn wrote:

That looks a bit strange.. FDCAN peripheral has backward compatibility with standard CAN, so it should be able to recieve standard frames. So, it seems that there have to be a backward compatibility in bootloader interface too..


Here you are talking about the FDCAN backward compatibility vs CAN2.0, but what about the CAN2.0 nodes sharing the same bus as FDCAN nodes communicating with FDCAN frames?

Refer to this thread.

And this paper: Hybridization of CAN and CAN FD networks

mALLEm_0-1771329437044.png

 

"To give better visibility on the answered topics, please click on ""Accept as Solution"" on the reply which solved your issue or answered your question."
CuuuSynAuthor
Associate
February 17, 2026

Yeah, I agreee, that CAN2.0 node will not uderstand FD CAN frames. However, our system is based only on  two CAN2.0 busses and the master device can only send standard frames.

But a STM32H7 subsystem has FDCAN peripheral, so it should be able to receive and understand 2.0 frames. So, will the bootloader be able to get commands over standard CAN? Also, if it receives a valid command over CAN 2.0, will it send the response using a classic CAN 2.0 frame, or will it transmit a CAN FD frame instead?

mƎALLEm
mƎALLEmBest answer
Technical Moderator
February 17, 2026

Not possible for the bootloader to understand CAN2.0 frames as it was configured in CAN-FD with bitrate switching in the bootloader.

So to answer your question: no it couldn't receive classic frames but with no error propagation on the CAN bus. The bitrate in the data phase (1Mb/s) is different from the one set in the Nominal phase (250kb/s). CAN2.0 couldn't manage this bitrate switching. You need a host bootloader with FD/bitrate switching activated with the same bitrates (250kb/s / 1Mb/s).

"To give better visibility on the answered topics, please click on ""Accept as Solution"" on the reply which solved your issue or answered your question."
CuuuSynAuthor
Associate
February 18, 2026

Oh, I understood.. Thanks for the clarification!