CCP/XCP

•CCP and XCP require a CAN bus set up with Transforms in MxTransIt or with Network Configuration in MxVDev. Transforms are preferred.

•An ASAP2 A2L file is required for the signal definitions with correct ECU address information, scaling, and size. The A2L file is generated during the build process.

1.In MxTransIt, select a CCP or XCP transform from the Toolbox and place it in the Harness window.

2.The following default ports are created:

•CAN - (inport and outport) for sending/receiving CAN frames

•CCP(XCP)_Config - for setting up measurement signals at the time of test execution

•CCP(XCP)_Connect - for connection to the ECU

•CCP(XCP)_Ready - for signaling when ECU has been connected to and test is ready to begin.

The following ports are created on CCP transforms only:

•CCP_DirectCommand – enables the user to send ad hoc CCP commands from MxVDev to the SUT. This is typically used for robustness testing of the CCP code on the SUT.

•CCP_DriverResponse – is used to deliver information about failures in the CCP protocol back to MxVDev and into a test case. For example, if a CCP command is sent but no response is received within the Retry Timeout period, then a transition is transmitted on this port at the time the timeout expires.

•CCP_Flash - is used for flash programming the ECU. See Using CCP for Flash Programming Video Demonstration.

If the CAN bus from Network Configuration is used, then the name of the CAN Port should match the name of the CAN bus used in Network Configuration. For example: If Network Configuration specifies CANI and CAND and the ECU is connected to CAND, then the CAN ports on the XCP/CCP transform should be renamed to CAND. Click on the transform, then select Transform‑>Edit Ports.

By default, the name of the transform is appended to the port names to maintain unique names if more than one CCP or XCP transform is used. These ports can be renamed, however at the very minimum, they should contain "XCP_Config" (CCP_Config) etc. (See image of sample transforms above.)

3.The Property box on the right shows configurable properties for the selected transform. The following settings are used to configure the CAN transport layer and device interface:

•Tx Id (CRO): CAN ID of the Command Receive Object: message sent from the master device (MxVDev) to the slave device (SUT ECU).

•Rx Id (DTO): CAN ID of the Data Transmission Object: message sent from the slave device to the master device (Command Return Message or Event Message or Data Acquisition Message).

▪Valid Standard CAN IDs range from 0 to 0x7FF. Valid Extended CAN IDs range from 0 to 0x1FFFFFFF.

•Extended CAN Id - specify if the 'Tx' and 'Rx' fields are standard or extended.

•Max DLC Required - specify whether to always set CAN message DLC to 8 bytes (otherwise size of the packet is used as DLC).

•Queued Poll Limit - By default this is set to 10, which means if there are more than 10 Poll commands being queued up, they are be discarded in favor of write commands. You can decrease that limit if you wish to further prioritize write commands. See Limiting Poll Requests.

•Retry Count - specify how many times to resend the command packet if the slave device does not respond.

•Retry Timeout - specify how long to wait (in ms) for the slave device to respond, before re-sending the command packet.

•Tick Period - specify how often the transform should be ticked. (Depending on PC Performance this might need to be slower than 1ms.)

CCP Only:

•Endianness - to specify byte order.

•Station ID - specify station address of the slave device.

Note: For CCP/XCP,  arrays currently can be used as stimulus only, not as response.
 

4.If you are using Seed and Key, specify the following properties:

•Seed Key Required - Set to True if your ECU needs to be unlocked.

•DLL Path- This is the Seed Key DLL that needs to have function ASAP1A_CCP_ComputeKeyFromSeed() exported.

•Privilege Level - Which level of security to unlock on connect. Contact your developer for the required setting, by default 0x01 CAL and 0x02 DAQ.

The definitions of the stimulus and response variables for the SUT should be defined in the ASAP2 A2L file. Every time the project is reloaded into MxVDev, the A2L file time stamp is checked, and if it is different, signal information is parsed and updated. If the signal information was updated (memory address, conversion info) the current .mxform file is marked for re-saving. You will see the following message in the Notifications window: "A2L file has been modified since the last check! .mxform will be updated and re-saved"

Notes:

•The file should contain the correct ECU memory address for each variable, and correct scaling, min/max value, and byte length information.

•Any comments in the A2L file should be on a single line.

Currently the following A2L conversion methods for signals are supported:

•RAT_FUNC - fractional rational function of the following type:
 
f(x)=( A*x^2 + B*x + C)/(D*x^2 + E*x + F)

All coefficients are supported, A, B, C, D, E, and F, giving the flexibility to use any polynomial of that type as a conversion.

Note: This conversion is not imported to MxVDev signal information (scaling and offset will not change). Inside the MxVDev test case all values are treated as physical values.

If you have an existing CCP/XCP project, delete CCP/XCP signals from your data dictionary and re-add the desired A2L signals on your transforms.

Conversion happens when the value is transmitted to the ECU inside the CCP/XCP transform.

In the case where function denominator equals 0, the function returns 0.

In the case of a quadratic equation, the inverse of function returns first non-negative root.

ASAP2 example:

COEFFS 0 4 8 0 0 5

/* Control unit internal values of revolutions (INT) is calculated from */

/* physical values (PHYS: unit of PHYS is [rpm]) as follows: */

/* INT = (4/5) * PHYS/[rpm] + (8/5) */

/* inverted: PHYS/[rpm] = 1.25 * INT - 2.0 */

•TAB_VERB - verbal conversion table (Enums)

Note: Enumeration values cannot be hexadecimal (Use 0, 1, 2 instead of 0x0, 0x1, 0x2).

Enumeration labels should be unique.

•The BIT_MASK keyword can be used to mask out single bits of the value to be processed. The least significant bit in BIT_MASK determines how far the masked value is shifted to the right.

ASAP2 example:

Value to be masked     BIT_MASK             Result

10110110                     0x1 = 1 (bin)            0 (bin)

10110110                     0x2 = 10 (bin)          1 (bin)

10110110                     0x6 = 110 (bin)        11 (bin)

10110110                     0xC = 1100 (bin)     01 (bin)

10111010                     0xC = 1100 (bin)     10 (bin)

10111110                     0xC = 1100 (bin)     11 (bin)

10111110                     0xA = 1010 (bin)     101 (bin)

The following conversion methods and characteristic types are not supported:

•FORM - conversion based on the formula specified by the optional FORMULA keyword.

•TAB_INTP - table with interpolation.

•TAB_NOINTP - table without interpolation.

•CUBOID - The characteristic is a table with an x-axis, y-axis, z-axis, and an output axis.

•VAL_BLK - The characteristic is an array of numeric values (no axes).

1.In Properties, specify the A2L file by clicking on File path property and browse to select the correct file. The A2L file should be placed in the project directory, so that the relative path is stored correctly.

2.Click the Pick signals property to bring up the form that you can use to select the subset of A2L file signals for the test.

3.Find all the signals to be used during testing and press the >> button to add them to the transform.

4.By default, Measurement signals are outputs (use DAQ or Poll (upload) to read from the slave device) and Characteristics are inputs (use download to write to the slave device). To change the data flow direction either double-click on the signal and change the data flow property in the signal information window, or press the Change Data Flow button on the bottom of the Signal Filter form.

5.Once done, click OK. The stimulus signals show up on the left (input) side of the transform and the response signals show up on the right (output) side of the transform.

6.Export the signals from the transform to be visible to MxVDev Signal Dictionary.

In Project Settings, under the Execution tab, select RTClock as the time source. Optionally, 'Optimize For Speed' can be checked to minimize GUI updates until the test is done.

To connect to the device under test, Config, Connect, and Ready signals should be added to the test case.

The Config  signal (CCP_Config or XCP_Config) is used to specify configuration information for the output signals. Double-click on the signal editor area to create a configuration transition. A dialog box displays, showing the options for the output Signals of the Transform. Put a check mark next to the signals to be used in the current test Scenario. Next, specify the data flow type: Poll, ShortPoll, or DAQ. Poll requests data periodically at the specified Poll Rate. DAQ receives data from the device with the configured Prescaler and Event Channel. If using DAQ, make sure that Prescaler and Event Channel values are supported by the device under test.

Tip: You can use Shift-click or Ctrl-click to select multiple signals in the Edit Transition dialog box. Then right-click and use the context menu to set values for the selected signals.

The Connect signal (CCP_Connect or XCP_Connect) tells the transform to initiate the set up and connection sequence to the device. The transform uses the information from the Config signal to set up the test during connection to the ECU, so it is important that the transition on the Config signal happens before Connect transitions from 0 to 1. To send the disconnect command to the device, create a transition from 1 to 0 in the test case.

The Ready signal (CCP_Ready or XCP_Ready) shows when connection with the device is established. At this point, the test data is received and sent to the device.

As a requirement for this transform to work properly, the transition on the Config signal must be before the first Connect transition. This way the driver is properly set up for stimulus and response signals. If only stimulus signals are needed, a transition on the Config signal is still necessary. Create an "empty" transition, but you can choose not to select (instrument) any response signals. In general, there should be only one Config signal transition per CCP/XCP session. A second transition overrides the preceding one and another Connect is needed.

Data Flow Types

To request (read) data from the SUT using CCP/XCP, the signal must be defined in the A2L file. Depending on which commands the system supports, the Config signal allows 3 different data flow types: DAQ, Poll, and ShortPoll which are used in the background to request data from the ECU/SUT.

As a rule of thumb, if you need data faster than 20-50 ms, use the DAQ method of reading. For anything else, use ShortPoll since it is still significantly faster than Poll. Use Poll only if needed for large variables longer than 4 bytes.

Poll

Poll uses SET_MTA and UPLOAD. It uses a total of 2 round-trip CAN messages. This method is the slowest because the tester waits for a response to each request.

ShortPoll

ShortPoll uses the SHORT_UP command and only needs 1 round-trip CAN message. This works only for signals that are 4 bytes or less.

DAQ

DAQ uses a number of commands to set up DAQ on the system, then it uses only one-way messages from the system to the tester to stream data at the periodic rate. DAQ mode is the fastest way to request data from the system under test.

The DAQ Rate depends on your system's DAQ Event Channel and the configured Prescaler value set in the Config signal. For example: if your SUT's event channel is executed every 5 ms, and Prescaler is set to 2, DAQ will stream data at a rate of 10ms (5 times 2).

Limiting Poll Requests

To ensure data consistency, all commands sent to the SUT require a response, and subsequent commands are queued up before being sent. To prioritize stimulus write requests, MxVDev can limit how many poll requests are placed into the queue. The Queued Poll Limit property specifies how many poll requests (Upload/ShortUpload commands) the CCP/XCP driver queues before dropping requests to prioritize other commands. This property does not limit the amount of signals that are configured for polling, but how many requests are queued. A few signals with a fast poll rate can fill up the queue. See above for the differences between Poll, Short Poll, and DAQ.

If the performance of your project is inadequate, check the following:

•In the CCP_Config (or XCP_Config) signal you can pick your acquisition method. There are 3 different types: Poll, ShortPoll, and DAQ. If you have many signals to measure at a high rate, use the DAQ method. When using ShortPoll, do not use a rate faster than 20-50 ms. The Poll method should be used at slow rates and for large data such as strings.

•If you have changed the Queued Poll Limit from the default, it can cause your CCP/XCP requests to get behind in a queue if there are frequent poll requests.

•Check to see if the bus utilization is too high with CCP polling requests. This image shows what one would expect on a highly saturated bus with too many polling requests. In the case of bus saturation, increasing the Polled Queue Limit would only delay the problem, not solve it. In situations where the queue is being overrun just slightly, the problem can be solved by simply removing one signal from your polling list (which is why we don’t advocate modifying the queued poll limit).

Warning from Highly Saturated Bus