Implementation Record of CANFD Communication Based on STM32H750 and RT-Thread

1 Background

Having worked in the automotive electronics industry for many years, in the past two years I have mainly been engaged in the development of CAN, LIN, and ETH functions. Although during early function verification, Vector provides a test environment based on CANOE software and CAPL scripts that can fully simulate any node and function on various automotive communication networks, the price is extremely expensive. Therefore, when project budgets are tight, it is impossible for each developer to have their own license. Under this premise, I began to consider whether alternative solutions could be made. Thus, I came up with some attempts:

● Purchase relatively inexpensive CAN boxes, LIN boxes, ETH-to-T1 converters, etc. from the market, and then use scripting languages such as Python to simulate node behavior.

● Use affordable chips such as STM32 and GD32 to build my own simulated physical nodes, apply ETH, CAN, LIN protocol stacks, and use open-source projects to simulate node behavior.

After some research, I found that scheme 2 is more challenging and allows more flexible control over both hardware and software. Therefore, I plan to complete my idea based on fully open-source projects available online.

2 Objective

As shown in the figure, the initial target is relatively simple. Since CAN networks are the most common and widely used in automotive communication networks, and considering the peripheral I/O resources and performance of microcontrollers, I plan to adopt two CANFD channels and one ETH channel to implement several conventional functions:

● As a CANFD-supported node, it can perform CANFD frame transmission/reception, message filtering, retransmission, etc.

● As a Router-supported node, it can perform diagnostic routing such as DoCAN → DoCAN, DoIP → DoCAN, and direct routing of CANFD → CANFD.

● As a UDS-supported node, it can respond to diagnostic services.

● The node needs to support CAN communication framework.

3 Environment

3.1 Hardware

The initial selection is STM32H750VBT6. Boards available online are relatively cheap and the performance is not weak. ROM can even be expanded if necessary. In addition, it comes with two FDCAN channels and ETH support, so the cost-performance ratio is very high.

Hardware topology is as follows:

3.2 Software

As for software, without doubt, I chose RT-Thread. I had some exposure before but never actually used it in depth. This is a good opportunity to gain more experience with RT-Thread.

4 Current Work Implemented

Since the title is marked with (1), it indicates that the work related to CANFD on STM32H750 requires multiple parts to describe. Therefore, this article only covers how to implement the transmission and reception of CAN FD Frames and CAN Frames based on HAL-FDCAN and the TJA1042 transceiver without enabling hardware filtering. The part about hardware filtering will be described in future work.

4.1 Project Creation and Configuration

As I prefer the CLI workflow, once the following steps are completed, the project configuration can be considered finished:

● Create a project with Studio, and stop using it afterwards. Later compilation will be done using CMake + GCC, and debugging will use PyOCD + DAPLink.

● Configure using the ENV environment.

After compilation, the program can be flashed directly, and serial output is available.

4.2 Clock Configuration

Note: The arbitration and data domain baud rate and sampling rate of CANFD are determined by the FDCAN clock frequency. According to actual board configuration, FDCAN clock can be set to one of the common 20 MHz, 40 MHz, or 80 MHz. Here, I chose 40 MHz.

4.3 Enable CAN Configuration

4.3.1 ENV

RT-Thread Components → Device Drivers →

● [*] Using CAN device drivers

● Enable CAN hardware filter

● [*] Enable CANFD support

After saving the configuration:

4.3.2 CubeMX

4.3.2.1 Enable FDCAN1 and FDCAN2

4.3.2.2 Usage of Code Generation

Depending on the selection, the location of generated code may vary. Just make sure that the drv can properly call HAL drivers. Details will not be repeated here, as there are plenty of forum articles available.

4.4 Improve CANFD Device Driver

4.4.1 Add Macros

Add the following macros in board.h:

/*#define BSP_USING_ON_CHIP_FLASH*/#define BSP_USING_FDCAN #define BSP_USING_FDCAN1 #define BSP_USING_FDCAN2

4.4.2 Add drv_fdcan.c

According to RT-Thread’s driver model, the kernel provides abstractions of CAN device operations in can.c, but actual operations on CAN controllers require a device driver. In version 5.1.0, only drv_can.c is provided, and it only supports CAN_HAL. After some searching, I found that the ART-Pi official example contains a drv_fdcan.c file that supports FDCAN_HAL. However, this driver has several problems, making it only capable of sending CAN frames, not CANFD frames:

● Only arbitration domain configuration is supported, no data domain configuration.

● Only Classic mode configuration is provided, with no interface for FD mode.

● No preset collections of different baud rates and sampling rates at different clock frequencies, like in drv_can.c.

● No flexible configuration interfaces for Txfifo, Txbuffer, etc.

● No support for transmission/reception of data length greater than 8, and no conversion interface between Length and DLC.

● Other issues as well.

4.4.3 After improving drv_fdcan.c, some important configuration items are as follows:

Bit timing configuration rule:

1 baud rate = (1 / (n + tseg1 + tseg2)) * fclk

If configured as 40 MHz, arbitration segment 500K — 80% sampling rate, data segment 2000K — 70% sampling rate:

4.4.4 Bus Initialization

After completing the configuration, compilation, and flashing, the system automatically initializes FDCAN1 and FDCAN2 at startup.

4.5 Testing

4.5.1 Test Results

After completing the driver, I used the FINISH interface to write a test interface for FDCAN. Test code is as follows:

Test results → As shown in the figure, the following commands were sent:

4.5.2 Test Conclusion

By controlling parameters at the APP layer, and due to the complete compatibility of CANFD with CAN, it is possible to use STM32H750 + TJA1042 combination to send:

● CAN Frames with lengths of 1–8 bytes

● CAN FD Frames with lengths of 1–64 bytes

5 Work Not Completed

● Configuration of HDR filters. Currently, FDCAN filtering supports multiple modes, which requires optimization of HDR configuration along the chain from can.c → drv_fdcan.c.

● Link performance and stress testing of CANFD under high data load.

● Some setting descriptions in the document are relatively rough and will be supplemented with details later.

Copyright Notice: This article is an original work by RT-Thread forum user “Woshizhapuren”. It follows the CC 4.0 BY-SA license agreement. Please indicate the original source and this statement when reprinting.

Original link: https://club.rt-thread.org/ask/article/221a0238569f6f40.html