Weird delays between consecutive can_send() with MCP281XFD

[GilDev]

Hi,

Using an MCP2518FD controller + transceiver on an STM32G474 board, I’m trying to send CAN-FD frames as fast as possible. The frames themselves look good, use the proper bitrates and I can properly receive them (using a SeeedStudio shield with a Raspberry Pi 5 as host).

The issue is that I’m having a delay between frames, and I have no idea where this is coming from. I don’t have it when sending from my Raspberry Pi for example (using cangen from can-utils).

Here’s my DTS:

&spi1 {
	pinctrl-0 = <&spi1_sck_pa5 &spi1_miso_pa6 &spi1_mosi_pa7>;
	pinctrl-names = "default";
	cs-gpios = <&gpioa 4 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
	status = "okay";

	mcp251xfd: mcp251xfd@0 {
		compatible = "microchip,mcp251xfd";
		status = "okay";
		reg = <0x0>;
		spi-max-frequency = <20000000>;
		int-gpios = <&gpioe 9 GPIO_ACTIVE_LOW>;
		osc-freq = <20000000>;
		bitrate-data = <5000000>;
		bitrate = <1000000>;
		sample-point-data = <875>;
		sample-point = <875>;
	};
};

Here’s my prj.conf:

CONFIG_SPI=y

CONFIG_CAN=y
CONFIG_CAN_FD_MODE=y
CONFIG_CAN_SHELL=y
CONFIG_CAN_LOG_LEVEL_DBG=y

CONFIG_CAN_MCP251XFD=y
CONFIG_CAN_MCP251XFD_MAX_TX_QUEUE=16 # Changing this didn't help
CONFIG_CAN_MCP251XFD_RX_FIFO_ITEMS=8 # Changing this didn't help

Here’s my source:

struct can_frame sensor_frame = {
	.flags = (CAN_FRAME_IDE | CAN_FRAME_FDF | CAN_FRAME_BRS),
	.id = 0x42,
	.dlc = can_bytes_to_dlc(64),
};
while (1) {
	for (uint8_t frame = 0; frame < 5; frame++) {
		can_send(can_dev, &sensor_frame, K_USEC(100), NULL, NULL);
	}
	k_sleep(K_MSEC(1000));
	LOG_INF("");
}

Here’s my log:

…
[00:01:52.588,000] <dbg> can_mcp251xfd: mcp251xfd_send: Sending 64 bytes. Id: 0x42, ID type: extended  FD frame BRS
[00:01:52.589,000] <dbg> can_mcp251xfd: mcp251xfd_send: Sending 64 bytes. Id: 0x42, ID type: extended  FD frame BRS
[00:01:52.589,000] <dbg> can_mcp251xfd: mcp251xfd_send: Sending 64 bytes. Id: 0x42, ID type: extended  FD frame BRS
[00:01:52.590,000] <dbg> can_mcp251xfd: mcp251xfd_send: Sending 64 bytes. Id: 0x42, ID type: extended  FD frame BRS
[00:01:52.590,000] <dbg> can_mcp251xfd: mcp251xfd_send: Sending 64 bytes. Id: 0x42, ID type: extended  FD frame BRS
[00:01:53.591,000] <inf> main: 
[00:01:53.591,000] <dbg> can_mcp251xfd: mcp251xfd_send: Sending 64 bytes. Id: 0x42, ID type: extended  FD frame BRS
[00:01:53.591,000] <dbg> can_mcp251xfd: mcp251xfd_send: Sending 64 bytes. Id: 0x42, ID type: extended  FD frame BRS
[00:01:53.592,000] <dbg> can_mcp251xfd: mcp251xfd_send: Sending 64 bytes. Id: 0x42, ID type: extended  FD frame BRS
[00:01:53.592,000] <dbg> can_mcp251xfd: mcp251xfd_send: Sending 64 bytes. Id: 0x42, ID type: extended  FD frame BRS
[00:01:53.592,000] <dbg> can_mcp251xfd: mcp251xfd_send: Sending 64 bytes. Id: 0x42, ID type: extended  FD frame BRS
[00:01:54.593,000] <inf> main: 
…

Here’s my frame (getting a delay of ~490 µs between frames):

If I change my source to add a callback on send error/success:

void can_tx_callback(const struct device *dev, int error, void *user_data)
{
	ARG_UNUSED(dev);
	ARG_UNUSED(user_data);

	if (error) {
		LOG_ERR("CAN TX error: %d", error);
	}
}
…
can_send(can_dev, &sensor_frame, K_USEC(100), can_tx_callback, NULL);
…

I get the same logs but here’s my frame (getting a delay of ~180 µs, then ~490 µs, and so on):

Does anyone please have any idea on what could be adding this weird delay? I need to send my frames as fast as possible for my application. Thanks!

[GilDev]

After some investigations, we found that the delay are likely to be caused by the SPI communication (20 MHz) between the MCU and the CAN controller. We currently have no idea why, but any byte sent via SPI seems to have a delay (which corresponds to about the time it takes to send a byte, so it’s about two times slower because of that).

We are exploring enabling DMA on the SPI1 of the STM32G474 but with no luck currently. We are also looking in enabling the embedded fdcan1 controller with the MCP set as a transceiver only, without any luck (the STM32 FDCAN drivers seems to enforce the usage of MCAN, not sure what is going on here…).