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.