ECU MC Toolkit
Overview
ECU MC toolkit comprises two communication protocols: CAN Calibration Protocol (CCP) and Universal Calibration Protocol (xCP). CCP is an older protocol and works over CAN, while XCP, an expansion of CCP, works over several different physical layers. The ECU MC toolkit supports XCP over CAN, TCP/IP, and UDP.
Basic troubleshooting and pertinent information
The first step is to ensure that the physical layer is configured properly. Relevant questions would include:
- Using CCP or XCP? If XCP, what is the physical layer (CAN or Ethernet)?
- If it’s CAN:
- Check that the baud rate in ECU MC matches the proper baud rate for the ECU.
- Ensure that your network is terminated properly.
- If you run an XNET Bus Monitor at the same time as your ECU MC program, do you see error frames on the bus?
- If so, this indicates a problem with termination, improper baud rate settings, or improper sample point settings. CAN FD systems can be especially sensitive to baud rate or sample point mismatches. See this article for more details .
- Remove all devices from the bus, except for the ECU and the device running the ECU MC application, and see if the issue persists.
If the physical layer seems to be working properly, then the next step in our investigation is to determine what messages are being sent on the bus. XCP and CCP are both well-documented communication protocols with standardized messages and responses between nodes on the network. By obtaining a log of the communication between nodes, we can see exactly which command or message caused the communication to break down, what error code was thrown by which device, and why.
Note: The most important thing to capture in a log is the initial communication between the ECU MC toolkit and the ECU. We’re looking for the commands that are sent during initialization—we don’t care so much about the DAQ data that is being sent.
On WindowsECU MC Toolkit installs a utility called ECUMC CCP and XCP Trace. The utility will run as soon as it is launched. The utility is located at
C:\Program Files (x86)\National Instruments\ECU Measurement and Calibration Toolkit\bin\ECUMC XCP and CCP Trace.exe (or you can search for this utility in the Windows search bar). Once the utility is launched, run your ECU MC application, and then go back to the utility and save the log file that pops up. To change the commands captured by the trace, go to
Trace >>
Options.
On an RT target
- Physical layer is CAN: You’ll have to set up a separate CAN interface on your network to act as a passive observer. This could be an XNET Bus Monitor session with "Listen Only?" set to ON.
- Physical layer is Ethernet (UDP or TCP/IP): There are packages available to allow Wireshark on a Linux RT controller.
A communication log is sometimes difficult to decipher on its own. It is often necessary to have the A2L database file on hand for cross-reference. We don’t always need the whole file—usually just the relevant section is fine (e.g., just defining the connection parameters for the ECU).
Seedkey DLLs
A seed/key algorithm is a method of securing an ECU by only allowing certain devices to access it. It is stored as a function in a DLL called a seedkey DLL. A seedkey DLL generates a call-and-response kind of password.
When you try to connect to a protected ECU, it generates a seed, which is just a random number, and uses the seedkey algorithm to generate the proper key, or response. In order to continue, you have to take that seed and provide it as an input to the proper seedkey DLL, which performs the same calculation as the ECU to generate the appropriate key. Once you provide the key, the ECU unlocks, and you’re allowed to interact with it.
FAQs
- Can I use a seedkey DLL on a real-time target?
Some seedkey libraries come as .so files, which are compatible with Linux RT targets. If you’re able to compile the seedkey DLL as a .so file, it should then be able to run on Linux RT.
Otherwise, DLLs are Windows files, and as such cannot run on RT targets. You will not be able to deploy a seedkey DLL to an RT target running an ECU MC application. The solution is to open a remote seedkey session. This requires the RT target to have a connection to a Windows host PC.
For example, you are running an ECU MC application on a CompactRIO target running Linux RT. Your ECU is protected by a seedkey algorithm. The ECU MC application attempts to connect to the ECU, and the ECU responds with a seed. The ECU MC application takes the seed and sends it over an Ethernet connection to a VI running on the Windows PC, called a remote seedkey server. This VI takes the seed, provides it as an input to the seedkey DLL, gets the key as an output, and sends that key back to the application running on the CompactRIO. The application then sends the key to the ECU, allowing for a connection.
The ECU MC Toolkit ships with an out-of-the-box remote seedkey server application, found in LabVIEW under Help >> Find Examples >> Toolkits and Modules >> ECU Measurement and Calibration >> Advanced >> Remote Seedkey.lvproj.
- Error -301039 occurred at MC ECU Connect.vi
Error -301039 occurred at MC ECU Connect.vi
Possible reason(s):
ECU Measurement and Calibration Toolkit: (Hex 0xFFFB6811) The function to calculate the key was not found in the Seed-Key dll. Solution: Make sure that the Seed-Key dll exports the function "ASAP1A_CCP_ComputeKeyFromSeed" (without any further decorations).
As the error indicates, the trick here is in the name of the function in the seedkey DLL which calculates the key based on the seed. The ECU MC Toolkit accepts only two possible names for this function:
- CCP: ASAP1A_CCP_ComputeKeyFromSeed
- XCP: XCP_ComputeKeyFromSeed and XCP_GetAvailablePrivileges.
Seedkey DLLs sometimes use different function names for the key-generating function, such as seed2key. While this can be functional in some XCP master software, this is a deviation from the CCP or XCP standard which the ECU MC Toolkit does not support.
To investigate the presence and name of the key-generating function in the seedkey DLL, you can use a third-party utility such as Dependency Walker to see the names of its functions.
The solution is to change the seedkey function name in the seedkey DLL to a supported name.
Automotive Diagnostic Command Set
Overview
The Automotive Diagnostic Command Set (ADCS) is an API that adds support for several automotive communication protocols: KWP2000 (Key Word Protocol), UDS (Unified Diagnostic Services), and OBD (On-Board Diagnostics). These protocols are used to communicate with an ECU to collect data and program onboard memory. They are often used for diagnostic purposes: gathering fault codes and monitoring the condition or status of the ECU during operation.
These protocols mostly operate on the high-speed CAN physical layer, but sometimes use CAN FD and LIN as well.
Basic troubleshooting and pertinent information
Since these protocols work over CAN and LIN, start by ensuring that the physical layer is working properly. Relevant questions would include:
- Check that the baud rate in ADCS matches the proper baud rate for the ECU.
- Ensure that your network is terminated properly.
- If you run an XNET Bus Monitor at the same time as your ADCS program, do you see error frames on the bus?
- If so, this indicates a problem with termination, improper baud rate settings, or improper sample point settings. CAN FD systems can be especially sensitive to baud rate or sample point mismatches. See this article for more details.
- Remove all devices from the bus, except for the ECU and the device running the ADCS application, and see if the issue persists.
If the physical layer seems to be working properly, then the next step in our investigation is to determine what messages are being sent on the bus. The various protocols supported by ADCS are well-documented communication protocols with standardized messages and responses between nodes on the network. By obtaining a log of the communication between nodes, we can see exactly which command or message caused the communication to break down, what error code was thrown by which device, and why.
In order to take a trace of the network communication, start an XNET Bus Monitor session in Subordinate Mode on the same interface being used by ADCS. Make sure that Log Error Frames? and Log Transmitted Frames? are both checked.
FAQs
- How do I find out which OBD PIDs are supported by my ECU?
The ADCS Toolkit ships with an example called OBD Get Supported PIDs.vi. When the customer runs this example, the Supported PIDs array shows, in order, which PIDs are and are not supported. The PIDs Out columns show the numeric names of the supported PIDs. Refer to this Wikipedia page to correlate the PID names to actual values.
- Does ADCS support ECU databases, such as ODX files?
Databases are not currently supported by ADCS.