Introduction Controller Area Network (CAN) is a bus standard proposed by Bosch in Germany to solve the information communication problem between automotive electronic control units. With its excellent performance, high reliability, and low price, it is now widely used in the automotive field. To ensure the safe and stable operation of automotive CAN bus nodes and to improve the efficiency of mass production, it is essential to test CAN node products during the production process. Therefore, developing an automotive CAN node tester based on the CAN bus is crucial. This paper ensures the versatility of the tester by selecting a high-speed processor and employing virtual instrument technology, allowing it to test multiple CAN nodes simply through software updates. CAN Protocol Overview The CAN protocol is based on the ISO/OSI 7-layer open interconnect reference model. To facilitate application and ensure error-free data transmission between nodes, only the bottom two layers of the ISO/OSI model are defined: the data link layer and the physical layer. The application layer protocol is defined by the user or can adopt standard protocols developed by some international organizations. CAN is a typical serial bus structure that communicates in half-duplex mode, where one node sends information and multiple nodes receive information. Unlike master-slave buses, CAN uses a broadcast access method, a peer-to-peer bus network. In the CAN bus communication protocol, there is no master/slave concept for node addresses, nor is there any information related to node addresses. Information appears in the form of messages, and its data structure is shown in Figure 1. The arbitration field in Figure 1 indicates the message type and priority. Nodes on the CAN bus will decide whether to read data from the message packet based on the identifier, thus avoiding unnecessary frequent interruptions in node processing of information on the bus, improving data transmission rate, and ensuring an extremely low data error rate. System Hardware Design The hardware design of the tester mainly includes three parts: the processor and its memory circuit, the CAN bus interface circuit, and the RS232 interface circuit. The structure diagram is shown in Figure 2. The processor uses the AT91RM9200 from Atmel, based on the ARM920T core. This processor operates at a frequency of up to 180MHz and can be expanded with 32MB Flash and 64MB RAM, enabling it to meet the testing needs of most automotive CAN nodes. The chip integrates many standard interfaces, such as USB master/slave interfaces, Ethernet, and RS-232, enabling easy connection to a PC. Test data can be uploaded to the PC in real time, allowing for online monitoring and data processing thanks to the PC's powerful processing capabilities and rich data processing software. The AT91RM9200 includes a high-speed on-chip SRAM working area and a low-latency external bus interface to seamlessly connect external and internal memory-mapped peripherals as required by the application. External memory includes one S29GL256N Flash and two K4S561632A-TC/L80 SDRAMs, with a Flash capacity of 32MB and an SDRAM capacity of 64MB. The CAN bus interface circuit consists of a bus controller and a physical layer interface, enabling CAN bus communication between the tester and the CAN node under test, which is a prerequisite for testing. The CAN bus controller uses the PHILIPS SJA1000, which offers better performance and stability, supports the CAN 2.0A/B protocol, and has two operating modes: Basic CAN and Peli CAN. It can simultaneously support 11-bit and 29-bit identifiers and can connect more CAN nodes. The physical layer interface is implemented using the TJA1054, which can connect up to 32 nodes. Built-in slope control and good matching of CANL and CANH bus outputs result in very low electromagnetic interference (EME). It has excellent bus fault management capabilities, automatically switching to single-wire mode in case of a bus fault and automatically resetting to differential mode after fault repair. It also provides short-circuit protection for power and ground, making it particularly suitable for CAN communication within automobiles. The RS232 interface circuit serves as the communication interface between the tester and the PC. The AT91RM9200 has an internal UART controller, allowing for easy connection to a PC for online monitoring and data storage of test information. Software Design The software design includes two parts: the host computer program and the slave computer program. The host computer program was developed on NI's LabWindows/CVI platform, specifically designed for virtual instruments. It includes two parts: a USB communication program and a test program. LabWindows/CVI supports numerous buses (including PCI, PCI Express, PXI, PCMCIA, USB, Ethernet, GPIB, serial port, and IEEE 1394), facilitating the development of RS232 communication programs. The test program includes a human-machine interface (i.e., the instrument panel) and test records. LabWindows/CVI provides rich controls, enabling rapid development of the instrument panel and eliminating the need to develop a separate human-machine interface (mainly LCD and buttons) on the lower-level computer. The developed instrument panel interface is shown in the figure below. The lower-level program uses Linux as the operating system for the test instrument, employing the relatively new Linux-2.6.13 kernel, making the software design modular and easy to port. The software mainly consists of two parts: a communication program and a test program. The communication program includes a CAN bus communication program and a USB communication program. This article mainly introduces the CAN communication program. The CAN communication program includes the initialization, data reception, and data transmission of the SJA1000 chip. After the tester is powered on, the SJA1000 is initialized. This operation must be performed correctly and reliably, as it is a prerequisite for receiving and sending data. According to the SJA1000 manual, the design code is as follows: `writesja1000(MODADDR, 0x09); // Set mode register, enter reset operation to initialize writesja1000(CDRADDR, 0x88); // Set clock divider register, select PeliCAN mode writesja1000(AMR0ADDR, AMR0); // Set receive mask register 0 writesja1000(AMR1ADDR, AMR1); // Set receive mask register 1 writesja1000(AMR2ADDR, AMR2); // Set receive mask register 2 writesja1000(AMR3ADDR, AMR3); // Set receive mask register 3 writesja1000(ACR0ADDR, ACR0); // Set receive acceptance code register 0 writesja1000(ACR1ADDR, ACR1); // Set receive acceptance code register 1 writesja1000(ACR2ADDR, ACR2);` // Set receive acceptance code register 2 writesja1000(ACR3ADDR, ACR3); // Set receive acceptance code register 3 writesja1000(BTR0ADDR, 0x03); // Set bus timer 0 writesja1000(BTR1ADDR, 0xFF); // Set bus timer 1 writesja1000(OCRADDR, 0xAA); // Set output register writesja1000(RBSAADDR, 0x00); // Set receive data buffer start address writesja1000(TXERRADDR, 0x00); // Clear transmit error register writesja1000(RXERRADDR, 0x00); // Clear receive error register readsja1000(ECCADDR); // Clear error code capture register writesja1000(IERADDR, 0xFF); // Enable interrupt register writesja1000(MODADDR, 0x08); //Set the mode register to enter the party operation mode for sending and receiving data. writesja1000() and readsja1000() are encapsulated low-level functions, and their specific implementations are as follows: static void writesja1000(unsigned char addr, unsigned char data) { *SJAADDR = addr; *SJADATA = data; } static unsigned char readsja1000(unsigned char addr) { *SJAADDR = addr; return *SJADATA; } Where SJADATA and SJAADDR are the AT91RM9200 addresses allocated for reading/writing data or addresses of SJA1000, respectively. Both receiving and sending data are implemented using interrupts. The interrupt-based data processing flow is the key to the CAN communication program, and its specific implementation flow is shown in Figure 4. Conclusion Compared to traditional 8/16-bit microcontroller tester systems, the tester described in this paper is based on a 32-bit ARM9 processor, with a running speed of up to 180MHz and strong expandability. It adopts a Linux operating system, making the software more modular, easier to update and port, and more stable in operation. The tester's operation panel is implemented using virtual instrument technology, facilitating functional expansion and strong versatility. During on-site testing of automotive CAN nodes, this tester operated stably and quickly, ensuring the smooth production of the product.