XCP ECU M&C Toolkit: error -301073

[LucianM]

Hi,

I receive this error while I try to connect with an ECU on XCP using a cRIO 9035 and NI 9862 module and I cannot find any details about the possible cause (error -301073: Access denied). I suspected a seed-key mismatch but I see that there are specific errors for that. The program opens the ECU, set the baudrate, DTO ID and CRO ID and calls the ECU Connect.vi which returns the error.

LabVIEW 2015 SP1, ECU M&C Toolkit 15.0

[JefeL]

This error is indeed from a seed-key mismatch. Can you tell us if you are using the shipping example seed-key with the Demo ECU example or are you using one of your own?

First I will recommend making sure that the seed-key dll is valid and has the right signature etc.

If we know that the DLL works, i.e. tested with another system etc, then we can look into a compiler issue. The cRIO903x uses a RT OS that doesn't support the full run time library of Windows. Accordingly, compiling the DLL in a revision of Visual Studio higher than VS 2008 can have unpredictable results. Make sure the DLL is compiled using VS 6 or VS 2008.

[LucianM]

Sorry for late reply!

I am using a real ECU but I have no seed-key.dll for it. Some colleagues which are using a different tool for XCP communication told me that there is no dll and they disabled this seed-key option and it's working. One of them send me a CAN trace file where I see no 0xF8 command - does that mean that seed-key is not used? Will the XCP ECU M&C API allow connection w/o seed-key if ECU is not using it?

In the meantime I found out that I am using a wrong a2l file. I received a new one and a new software version that will be flashed on the ECU and then I will try again. I'll post the results shortly! Thank you so far!

[JefeL]

You are correct. The 0xF8 command is a request for a seed from the ECU. If your ECU does not implement access restrictions then there is no need to request a seed or use a seed-key DLL.

[LucianM]

I receive the same error with the new ECU software and a2l file. Why do I receive a seed-key mismatch error if the ECU does not use a seed-key access restriction?

[JefeL]

Does the A2L file contain an entry for a seedkey.dll?

You can check by opening the A2L file in the A2L Viewer utility that installs with ECUMC. The A2L file for the shipping examples is shown below and I would expect your SeedKey DLL entry to be blank or an empty string.

If your A2L file has an empty string then we will need to look at the communications with the ECU. Per the XCP standard, after a connect message is sent the ECU will inform the master that it does or does not require a seedkey. The log below was taken with our shipping examples and shows the Resource Protection byte indicating a seed key is required:

Since you are using a cRIO, you will not be able to utilize the CCP/XCP Trace utility as shown in the picture. Instead, you will need to use the XNET bus monitor to log the CAN frames. Let me know how the ECU responds to the first 0xFD command sent and I can interpret the flags set by the byte.

[LucianM]

Protocol section in A2L Viewer is empty. Seed Key dll returned by MC Get Property.vi is also empty.

I added another cRIO (9068) for tracing like in the image below:

Example shown in the first post which return the "access denied" error is executed on the 9035.

I launched the XNET Bus Monitor by right clicking on the XNET CAN interface under cRIO9068 remote system in MAX and configured in listen only mode. I set the file format for logging to TXT as if I set TDMS the file remains empty for some reason.

I made three attempts to connect and I could see that the request parameters are not always the same - see attachment.

CRO ID is set to 0x6A2 and DTO ID to 0x6A0. 0x1B000013 is sent by ECU all the time - please ignore it.

[JefeL]

Extra bytes in the CAN frame should be ignored per the XCP spec and ECUMC often leaves them set to whatever value that byte last used. If we ignore the extra bytes the three logs are identical.

The log indicates that there isn't a problem with the seed-key. We request the status from the ECU and it correctly reports that the ECU is not locked (0xFD). We then send a few more commands that would otherwise be locked and receive a positive response. Thus the ECU is unlocked and we are interfacing with it as expected.

Later we then try to upload some data to an area of the ECUs memory (0xF5) and the ECU reports "Access Denied".

We haven't discussed many details of the application you are running so this could be a bug in the ECU or a problem with the A2L. Some ECUs required memory page management and will error out if accessing the wrong page. We will need to know more about what you are doing and the expected behavior before we can proceed.

[LucianM]

In the first step we would like to make measurements from the ECU (similar to Multiple Measurement example with cRIO) and send them to the UI for analysis and logging. Some ECU that we are measuring work in CCP and other on XCP and we would like to implement functionality for both.

The system already includes different C series modules with analog inputs like NI9234 and NI9222 for other types of measurements. Data is sent to the UI using STM - this is implemented and working. We just need to add the XCP/CCP component.

I compared the trace from the other application which is able to communicate with the same type of ECU and I could see that the parameter used for 0xF5 is 0x04 instead of 0x07 used by M&C Toolkit. Can we do it in the same way using perhaps low level VIs from the toolkit?

[JefeL]

CCP and XCP are very different so please make sure to be explicit as to which protocol we are working with. 

The toolkit is designed to abstract away the lower levels of the OSI model. As such, we do not provide the ability to directly manipulate the CCP/XCP messages on the transport layer and below. For some troubleshooting purposes, you could use the XNET examples to log a stream of frames, modify a few frames for testing, and then replay those frames back to the ECU. This approach is somewhat limited though because it removes any type of intelligence in the responses to the ECU.

MC ECU Connect.vi is called first when working with a ECU. It performs various operations including seed-key management and polling the ECU for capabilities which is what we are seeing in the log. Initial capabilities (addresses ect) are initially taken directly from the A2L file and then verified with the ECU during this handshake process. If the ECU reports a value that contradicts the A2L file, the value from the ECU is typically used.

When the previous command, GET_DAQ_EVENT_INFO, executes the ECU should move the MTA pointer to the event channel name upon completion. The XCP UPLOAD command (0xF5) is simply trying to read the name (at the MTA memory location) of the event and the 0x07 is how many bytes to read.  My guess is that your A2L file specifies a event channel name length of 7 bytes and the toolkit then tries to read it back. Curiously, your ECU reports a name length of 1 byte which doesn't match with either the working on non-working setup. 

Check the A2L file to see what it specifies as the event channel name length and verify that it is correct for your ECU. 

It may also be worth verifying that the ECU is in fact moving the MTA pointer to the appropriate address.