Deployment and troubleshooting of Softing CAN-AC2-PCI interface card

Deployment and troubleshooting of Softing CAN-AC2-PCI interface card

In the field of vehicle electronics research and testing, the CAN bus communication interface is the core bridge connecting the testing PC and ECU (Electronic Control Unit). As modern computer motherboards gradually eliminate traditional PCI slots and shift towards PCIe architecture, many early built ECU engineering test benches, simulation nodes, or verification systems face challenges in finding hardware spare parts and maintaining underlying systems. Softing CAN-AC2-PCI, as a classic short version PCI bus interface card, still plays an important role in a large number of in vehicle network testing and diagnostic systems due to its dual channel independent communication, local data preprocessing, and excellent electrical isolation capabilities. Unlike regular commercial CAN cards, it is an "Active card" with an independent microcontroller. This article will provide engineers with a detailed practical guide based on engineering practice, covering hardware architecture, API integration, system deployment, and troubleshooting.

Analysis of Hardware Architecture and Core Features

CAN-AC2-PCI is not a simple physical layer converter, but an intelligent communication board with powerful local processing capabilities.

Active board and local preprocessing

The board is equipped with a 16 bit microcontroller (Infineon CI165) and 4kB of DPRAM (Dual Port RAM, 16 bit) as the interface with the PC. The biggest advantage of this proactive design lies in local data buffering and preprocessing. In high-speed CAN networks (especially when the baud rate is high), if all underlying communication frames rely on the PC's CPU to process, it will result in extremely high CPU usage, which in turn will affect the real-time performance of the testing software. CAN-AC2-PCI offloaded these time sensitive tasks onto the microcontroller of the board, greatly reducing the computational pressure on the PC.

Dual channel independence and scalability

This interface card provides two completely independent CAN bus channels, both compliant with ISO 11898-2 high-speed CAN standard and CAN 2.0B protocol (supporting 11 bit/29 bit identifiers). Two D-Sub 9-pin interfaces (DB9) work independently, which is crucial for testing scenarios that require simultaneous access to power buses (such as engine, gearbox) and body buses (such as doors, instruments). In addition, Piggyback slots are reserved for each channel. If low-speed CAN (fault-tolerant CAN) needs to be connected, it can be achieved by installing CAN-AC2-PCI-LS expansion modules that support TJA1053 (or compatible) transceivers. By inserting multiple CAN-AC2-PCI cards into the same PC, the system can quickly expand to 4, 6, or even more communication channels.

Galvanic Isolation

In automotive electronic testing or harsh industrial manufacturing environments, there is often a potential difference between the grounding of the PC and the grounding of the vehicle/test bench. If not isolated, the "ground loop" current formed by this potential difference will not only seriously interfere with CAN communication, but may even burn out the PC motherboard or ECU interface. The vehicle interface of CAN-AC2-PCI is electrically isolated from the PC interface, effectively blocking interference from the ground loop and ensuring the long-term stable operation of the system.

Integration of software API and diagnostic protocol

Hardware is the foundation, software is the soul. The powerful functionality of CAN-AC2-PCI relies on the rich API interfaces provided by Softing.

Standard CAN-API

This is the standard API that Softing uses for all CAN interfaces. It provides developers with a powerful underlying communication mechanism, supporting functions such as periodic sending, event triggered reception, and error frame detection, and is suitable for various customized ECU engineering testing software written in languages such as C/C++.

D-PDU API (optional upgrade)

With the development of automotive diagnostic technology, traditional CAN-API is no longer able to meet complex diagnostic requirements. By purchasing the PDUAPI-ECU upgrade package, users can enable the D-PDU API. This API follows the ISO 22900 (MVCI) standard and directly supports CAN based diagnostics (ISO 15765 DoCAN) as well as unified diagnostic services (UDS, ISO 14229). This means that engineers can directly flash, read fault codes (DTCs), and perform diagnostic services on the ECU using standardized interfaces on the same card, without the need to write cumbersome underlying protocol stacks. For scenarios where equipment needs to be integrated into professional diagnostic systems (such as OEM testers), the D-PDU API is essential.

Operating System compatibility 

The historical background of this hardware design determined that its software support was mainly concentrated on older Windows platforms, such as Windows XP, Vista, and Windows 7. When deploying on modern Windows 10/11 systems, it is often necessary to search for specific older drivers or restrict them to run in specific virtual machine environments. This is also a major challenge facing the maintenance of old test benches at present.

System deployment and hardware installation specifications

Due to the particularity of the PCI interface, deploying such boards requires strict system specifications to be followed.

PC hardware resource allocation

According to the technical specifications, the PC side needs to allocate 4kB of high-end memory address space (Upper memory area) and one idle interrupt (IRQ) for the board. Although modern motherboards typically support Plug and Play for PCI devices, IRQ conflicts or address space mapping errors may still occur in some industrial motherboards or outdated BIOS. If the board cannot be correctly recognized by the device manager, it is recommended to enter BIOS settings, check the resource allocation of the PCI slot, or try replacing the PCI slot.

Power supply and power consumption

This card is directly powered by the PCI slot of the PC (5V), with a typical current consumption of about 410mA. Before installation, it is necessary to ensure stable power supply to the PCI slot of the motherboard. When plugging or unplugging the board, the PC power must be completely cut off, and live plugging is strictly prohibited to avoid damaging the PCI bus controller or board.

Cable connection and terminal matching

Connect the vehicle network using a standard DB9 male adapter cable. Key note: There must be a terminal resistance of 120 ohms at both ends of the CAN bus. If the test bench does not have a built-in terminal resistor, it must be manually connected to the terminal resistor at the end node of the physical network, otherwise the communication signal will undergo severe reflection, resulting in a sharp increase in bit error rate.

Common troubleshooting and on-site maintenance

In old test benches, CAN-AC2-PCI failures are often caused by hardware aging, system upgrades, or configuration errors. The following are typical troubleshooting directions:

Phenomenon 1: The board cannot be found in the device manager or displays a yellow exclamation mark

Troubleshooting approach: Firstly, check if the driver program is installed correctly and matches the operating system version. Secondly, confirm whether the PCI slot is disabled or not enough IRQ resources are allocated in the BIOS. For old motherboards, try cleaning the PCI gold finger oxide layer and replacing the slot for testing.

Phenomenon 2: The board can recognize, but the upper computer software reports "unable to open channel" or "channel initialization failure"

Troubleshooting approach: Check if multiple software are simultaneously occupying the channel (APIs usually have exclusivity). Secondly, check if the power supply is sufficient (if multiple cards are inserted, an external auxiliary power supply may be required). Finally, confirm whether the underlying hardware configuration files (such as bit rate settings in the registry or configuration software) are consistent with the bus network.

Phenomenon 3: CAN communication is intermittent and error frames occur frequently

Troubleshooting approach: This is a typical physical layer issue. Firstly, use a multimeter to measure the resistance between CAN-H and CAN_L, which should be approximately 60 ohms (two 120 ohms in parallel). If the resistance value is abnormal, check whether the cable is broken and whether the terminal resistance is missing. Secondly, check if the shielding layer is single ended grounded, or if common mode interference has occurred between the PC and the rack due to a lack of electrical isolation. Although the board comes with isolation, improper wiring of external harnesses (such as parallel with high-voltage lines) can still introduce interference.

Phenomenon 4: Need to connect to low-speed fault-tolerant CAN network, but unable to establish communication

Troubleshooting strategy: CAN-AC2-PCI only supports high-speed CAN (ISO 11898-2) by default. If the target network is low-speed CAN, CAN-AC2-PCI-LS (Piggyback expansion board) must be installed on the corresponding channel, and the channel must be configured as low-speed mode in the software API, and the baud rate may be set according to the actual network situation (such as 125kbps or lower).

Phenomenon 5: System crashes or communication interruption without reason in high temperature environment

Troubleshooting strategy: The operating temperature range of this board is 0~+55 ℃, and the storage temperature is -20~+70 ℃. If the internal heat dissipation of the test chassis is poor, resulting in high temperatures near the PCI slot, it can easily cause thermal stability issues with the components. Suggest enhancing the air duct heat dissipation inside the chassis to ensure that the ambient temperature is within the compliant range.