[stm32] Fdcan driver

[rleh]

• Fdcan driver
• Example for Nucleo-G474RE
• Test on real hardware
• Can message filtering
• Enable CAN-FD long frame support
• Adapt other can drivers

[salkinium]

Could you convert this to << syntax? The whole printf is quite large and it is fully optional.

Suggested change

	s.printf("id=%04lx,id2=%04lx", f.identifier, f.mask);
	s << "id=" << modm::hex << uint32_t(f.identifier) << modm::ascii << ",id2=" << modm::hex << uint32_t(f.mask) << modm::ascii;

[nicoBruhn]

I have been working on the FD CAN driver for the last couple of days. It is working on internal loopback on an stm32g474. I still don't have the hardware available to properly test normal operation mode with bitrate switching. Once I've done that I'll try to update it so it will work with modm's auto generation. The code for the driver is here:
fd_can.hpp
fd_can.cpp

You can also have a look at how I decided to handle the can message. I know it has been up for discussion how to handle it.
can_message.hpp
can_message.cpp

[nicoBruhn]

Tested the code with two MCP2562FD. I could not get bit rate switching to work. It made no difference at all. Though I was still able to run at 5 MHz. I also tested enabling transmission delays but that resulted in can frame errors. All in all FD can is working.

I don't know when I'll have time to update the code to modm's auto generation because I'm a bit busy with work.

[chris-durand]

Thanks for your contribution!

I don't know when I'll have time to update the code to modm's auto generation because I'm a bit busy with work.

Don't worry. There is always someone, who can help out. I am planning to use an STM32G47* with CAN in a design at work at the end of the month. So, this someone could be me, but I don't know if I can find any hardware for testing the flexible datarate mode.

[nicoBruhn]

Don't worry. There is always someone, who can help out. I am planning to use an STM32G47* with CAN in a design at work at the end of the month. So, this someone could be me, but I don't now if I can find any hardware for testing the flexible datarate mode.

Just a heads up that the driver is setup to run off PCLK clock. I don't know how you would detect which clock the user setup the CAN Interface for.

[chris-durand]

Just a heads up that the driver is setup to run off PCLK clock. I don't know how you would detect which clock the user setup the CAN Interface for.

The good thing is the driver doesn't need to know where the clock comes from, its frequency is enough. The clock mux configuration is not done within the CAN driver. It is handled by the user and the information is passed to the driver on initialization.

When calling Fdcan1::initialize() the user provides the SystemClock struct as a template argument. The driver just uses the frequency defined in SystemClock::Fdcan1. That way a driver does not depend on a specific clock tree implementation and works on different device families that use the same hardware IP but different clock architectures. For instance, H7 devices can't run Fdcan from PCLK.

[nicoBruhn]

Just a heads up that the driver is setup to run off PCLK clock. I don't know how you would detect which clock the user setup the CAN Interface for.

The good thing is the driver doesn't need to know where the clock comes from, its frequency is enough. The clock mux configuration is not done within the CAN driver. It is handled by the user and the information is passed to the driver on initialization.

When calling Fdcan1::initialize() the user provides the SystemClock struct as a template argument. The driver just uses the frequency defined in SystemClock::Fdcan1. That way a driver does not depend on a specific clock tree implementation and works on different device families that use the same hardware IP but different clock architectures. For instance, H7 devices can't run Fdcan from PCLK.

Parsing SystemClock does not help as you need to on the stm32g4 to modify the RCC_CCIPR register to select the source. Right now I just hardcoded the selection. Something similar to this has to be done for FD CAN.

[chris-durand]

Parsing SystemClock does not help as you need to on the stm32g4 to modify the RCC_CCIPR register to select the source. > Right now I just hardcoded the selection. Something similar to this has to be done for FD CAN.

Not necessarily. It is a design choice whether the FD CAN driver should manage the clock mux or the user does during clock configuration. Both are possible. If you look at the modm I²C and Uart drivers, none of the them touch the clock muxes. The user configures the clocks and puts the right value into the SystemClock struct, the driver reads the supplied clock and calculates the right prescalers.