XCP ECU M&C Toolkit: error -301073

[LucianM]

As I mentioned in the first post and in the title of the topic, we are working now with XCP. Everything that we discuss here and all the posted traces are related to XCP communication and "access denied" error. In the end I will need to have the possibility to use XCP or CCP depending on the ECU that I am measuring but now I am focusing on XCP over CAN.

I don't think that the event channel name length is specified in my A2L. Where exactly should it be? The value however is returned by the ECU in the reply of the 0xD7 command in the byte at position 3 which is 0x0F not 0x01. So the question is why is the toolkit trying to read 7 bytes and why is it important for the toolkit to get the event channel name when establishing connection? It's also not clear for me why is the MC ECU Connect.vi sending so many commands when it should only send the CONNECT 0xFF command as stated in detailed documentation of the VI.

Access denied error should indeed not be returned if the MTA is at the location of the event channel name but how can I check if it is?

[JefeL]

You are correct, I was decoding the log by hand read the wrong byte position. The ECU does respond that the name length is 0x0F and ECUMC then tries to read the full 16 byte name. The problem is that on CAN, the UPLOAD command (0xF5) is limited to reading back 7 bytes at a time. ECUMC would normally attempt to read 3 times (7+7+1=0x0F) but the ECU reports the access violation and a disconnect ensues.

Is the ECU still in development and under your control or is it a 3rd party OEM device?

[LucianM]

The ECU is still in development by the company I work for and it is used in vehicle brake systems.

[JefeL]

On Windows machines, we have the option to use only the information in the A2L file and not query the ECU for validation. If that was the case we were working with we could try using the A2L alone. We do not currently have that capability on RT targets so our options are rather limited.

Are you able to discuss the access violation with your ECU dev team? Ideally we would modify the ECU to either report 0x4 bytes as the event name length or to not report an access violation when reading the memory it claims is available.

[Minions]

Lucian,

Do you have that variable defined as a characteristic as shown?

    /begin CHARACTERISTIC ECU.VersionID "" VAL_BLK 0x10000222 __UBYTE_Z 0 NO_COMPU_METHOD 0 255
      BIT_MASK 0xFF
      BYTE_ORDER MSB_FIRST
      NUMBER 32
      MATRIX_DIM 32 1 1
    /end CHARACTERISTIC

This creates a one dimensional array of 32 characters.  We want all of the bits and therefore do not mask any out of the byte. The byte order implies the endian for how the processor works.  I have found that using VAL_BLK rather than ASCII works better in most cases.

[LucianM]

All my variables are defined under CHARACTERISTIC structure in A2L. VAL_BLK is not used.

[K1372]

Hello,

I also have just the same problem as yours. Could you solve this problem yet? And if yes, how did you do it?

Thanks alot