CANFD Communication Implementation Based on STM32H750 and RT-Thread

1. Background

I have been working in the automotive electronics industry for several years, and for the past two years, I’ve mainly focused on the functional development of CAN, LIN, and Ethernet (ETH). Recently, during a discussion with a testing colleague, we talked about the challenges of verifying early-stage features. Although V Company’s testing environment, based on CANOE software and CAPL scripts, can fully simulate any node and functionality on the automotive communication network, the cost is quite high. As a result, it’s not feasible to purchase a license for every team member when the project budget is tight. Given this, I wondered if there might be alternative solutions.

Some potential solutions I thought of include:

• Purchasing more affordable CAN, LIN, and ETH-to-T1 boxes available on the market and using script languages like Python to simulate node behavior.
• Using affordable microcontrollers like STM32 or GD32 to create a simulated physical node, implementing protocol stacks like ETH, CAN, LIN, and simulating node behavior through open-source projects.

After some research, I found that the second solution would be more challenging and would provide more control over both the hardware and software. Therefore, I decided to base my approach on fully open-source projects available online to bring my idea to life.

2. Objective

As shown in the diagram, my initial goal is relatively simple. Since CAN is the most common and widely used communication network in automotive applications, and considering the peripheral I/O resources and performance limitations of microcontrollers, I plan to implement a system with two CANFD channels and one ETH channel to achieve the following conventional functions:

• The node, supporting CANFD, can transmit and receive CANFD messages, perform message filtering, and handle message retransmission.
• The node, acting as a router, can perform diagnostic routing for DoCAN->DoCAN, DoIP->DoCAN, and direct CANFD->CANFD routing.
• The node, supporting UDS (Unified Diagnostic Services), can respond to diagnostic requests.
• The node should support CAN

Communication Protocols.

3. Environment

3.1 Hardware

I initially selected the STM32H750VBT6, as development boards for this model are relatively inexpensive and offer solid performance. If necessary, ROM can even be expanded. Additionally, the chip comes with two FDCAN interfaces and supports Ethernet (ETH), making it a highly cost-effective choice.

The hardware topology is as follows:

3.2 Software

I am using RT-Thread for the software.

4. Current Progress

Since the title includes “(1),” it indicates that the work related to implementing CANFD on the STM32H750 will be divided into multiple parts. This article focuses solely on how to send and receive CAN FD Frames and CAN Frames using the HAL-FDCAN library and TJA1042 transceiver, without enabling the hardware filtering functionality. The hardware filtering implementation will be covered in future sections.

4.1 Project Creation and Configuration

As I prefer working in a CLI environment, I consider the project configuration complete once the following steps are done:

• Use STM32CubeIDE to create an initial project (only for the initial setup). Afterward, all builds are done using CMake and GCC, while debugging is handled via pyOCD and DAPLink.
• Configure the environment using the RT-Thread ENV tool for subsequent development.

After compiling, the firmware can be directly flashed, and output can be observed via the serial port.

4.2 Clock Configuration

Note: The bit rate and sampling rate for the CANFD arbitration and data segments are derived from the FDCAN clock frequency. In practice, after configuring the board, the FDCAN clock can be set to one of the common frequencies: 20 MHz, 40 MHz, or 80 MHz. For this project, I have chosen 40 MHz as the clock frequency.

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 Using the Generated Code

The location of the generated code varies depending on the selection method. The key is to ensure that the driver (drv) can be correctly called when invoking the HAL drivers. The specific details are not elaborated here, as there are many articles on the forum that cover this topic in depth.

4.4 Enhancing the CANFD Device Driver

4.4.1 Add Macro

add macro 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

Here’s the translation and rewritten version:

According to RT-Thread’s driver model, the kernel provides an abstraction layer for various CAN device operations in can.c. However, the specific operations for controlling a CAN controller require a dedicated device driver. In version 5.1.0 of the software, only drv_can.c is included, which supports CAN_HAL but not FDCAN_HAL. After some research, I found that the ARTPI official examples include a drv_fdcan.c file, which does support FDCAN_HAL. However, this driver has several issues that prevent it from sending CANFD frames, allowing only the transmission of standard CAN frames:

1. Supports configuration for arbitration segments only, with no configuration for data segments.
2. Provides an interface for Classic CAN mode but not for FD mode.
3. Lacks pre-defined configuration sets for various bit rates and sampling rates under different clock frequencies, as seen in drv_can.c.
4. Does not offer flexible configuration options for using TXFIFO or TXBUFFER methods.
5. Does not support sending or receiving data lengths greater than 8 bytes and lacks an interface for converting between Length and DLC (Data Length Code).
6. Various other limitations.

4.4.3 Improvements to drv_fdcan.c

After implementing several enhancements to drv_fdcan.c, the key configuration items include:

Timing Parameters Setup Rules
The bit rate is determined by the following formula:
Bit Rate=1(n+tseg1+tseg2)×fclk\text{Bit Rate} = \frac{1}{(n + \text{tseg1} + \text{tseg2})} \times \text{fclk}Bit Rate=(n+tseg1+tseg2)1​×fclk

For example:

• With a clock frequency of 40 MHz, configure:
• Arbitration segment: 500 Kbps, with 80% sampling rate.
• Data segment: 2000 Kbps, with 70% sampling rate.

      ************************        
      Bit Timing Parameters           | Normal        | Data        
      -------------------------------|---------------|----------------        
      CAN Subsystem Core Clock Input  | 40 MHz        | 40 MHz        
      Time Constant                   | 25 ns         | 25 ns        
      Phase Segment 1                 | 63 tq         | 13 tq        
      Phase Segment 2                 | 16 tq         | 6 tq        
      Synchronization Jump Width      | 16 tq         | 6 tq        
      Bit Length                      | 40 tq = 1 µs  | 40 tq = 1 µs        
      Bit Rate                        | 500 kbps      | 2 Mbps

4.4.4 Bus Initialization

Once the configuration is complete and the firmware is compiled and flashed, the system will automatically initialize FDCAN1 and FDCAN2 upon startup.

4.5 Testing

4.5.1 Test Results

After completing the driver, I created a test interface for FDCAN using the FINISH interface. The test code is shown below:

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

4.5.2 Test Conclusion

The system can be controlled through the application layer parameters. Due to CANFD’s full compatibility with CAN, the following can be successfully transmitted on the STM32H750 + TJA1042 combination:

• CAN Frames with lengths ranging from 1 to 8 bytes.
• CAN FD Frames with lengths ranging from 1 to 64 bytes.

5. Unfinished Tasks

• Configuration of HDR filters: Currently, FDCAN offers multiple filtering modes, and optimizations are needed to configure HDR filtering through the link from can.c to drv_fdcan.c.
• Performance and stress testing of the CANFD link under high data conditions.
• Some configuration descriptions in the documentation are relatively brief and will be supplemented with more detailed information.

Copyright Statement: This article is an original work by RT-Thread Club User “Woshizhapuren” and follows the CC 4.0 BY-SA license. Please include the original source link and this statement when reposting.

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