CAN Connection timeout error

[Dan 55]

I am currently trying to connect to a third party ECU via the ECU toolkit. I am running V8.2 of labview and V2.1 of the toolkit with a series 2 hi-speed PCI NI-CAN card. When I try to connect to the ECU I get a timeout error "-301096: Timeout ocurred while waiting for response from slave device".
When the A2L file is initially loaded, the individual characteristic and measurement tables load without a problem but the CAN settings do not load. As a result, I use the MC set property vi to manually set CRO id, DTO id, baud rate, byte order and command byte order (after using the hex string to number conversion vi). I also manually set the seedkey dll's but I don't think that the program is getting that far since I have also tried putting in non-existant seedkey dll's and this has no effect.
I have tried increasing the timeout by factors of 10 and 100 by using the "Set Prop Timing factor" Vi as this is given as a solution to problems with the series 1 boards but this does not help.
I am using extended (29 bit) identifiers and in one of the supplied examples, there is a multiplication by 20 million and I have also tried this (it changes the CRO id from 0CCCCCCC to 2CCCCCCC for example).
I have tried using an XCP type connection but I get the same error.
I have checked the physical state of the CAN bus by looking at the CAN0 channel in MAX and the bus monitor reports no errors and seems to have 3 distinct messages that keep repeating. When in 'listen only mode', the number of repeated messages returns to 1.
I have included here an excerpt from the A2L file I am using and I have been manually setting up the ECU properties as follows:
 
connection type CCP:CAN0
baud 250000
CRO id: 0CCCCCCC
DTO id: 0DDDDDDD
Station address: 100
Byte order/cmd byte order: 1
 
Is there a way to tell if the Exchange_id function in the CCP protocol is being called? It seems to me that it must be falling over somewhere in here as this is needed in order to compute a correct seedkey for any unlocking of parameters. I would be grateful of any suggestions to help get this up and running.
 
Note that I have changed the proprietary A2L information.
Dan
 


exampleCAN1.txt:
http://forums.ni.com/attachments/ni/30/3202/1/exampleCAN1.txt

[GrahamG]

If the problem is  with the A2l file have you tried creating your own as a constant or control, testing this and then reverting back to the one used by your client? 

You can generate .a2l files through various third-party utilities. For example:

<a href="https://www.vector-worldwide.com/vi_asap2_editor_en,,9656.html" target="_blank"> https://www.vector-worldwide.com/vi_asap2_editor_en,,9656.html</a>

best regards

[Dan 55]

Hi Graham,
I tried starting off from a completely blank A2L and added connection parameters one at a time until I was sure each line was being read correctly by the toolkit parser. This seemed to work fine but the connection would open, try to unlock ECU resources and then return an error that the resources were unavailable and I should try a different seedkey.dll. I captured the CAN frames that were being sent via a second CAN card to look at the exact command sequence. I then extracted the seed data from the get seed reply frame and used a call library node function to call the seedkey.dll. This returned a different key to the one that was being sent in the unlock command so I could only assume that the toolkit is not calling the seedkey correctly somehow but since this is all hidden in a dll, I could not look at the exact mechanics to see what was going wrong. I then built a&nbsp; VI using the frame API stuff that comes with the NI-CAN drivers cd to manually send the the frames required to connect then get seed. I use the same call library&nbsp;node function&nbsp;to call the seedkey.dll and then build another frame with the returned&nbsp;key. This all seems to work fine and I have an unlocked ECU. Unfortunately since I did all this with the frame API, there was no way to subsequently use the toolkit vi's as they are built around the channel API which is apparently incompatible. Feeling completely frustrated with the non-functional toolkit and having logged a couple of tech help requests with NI I have given up on the tooklit altogether, built my own A2L parser and&nbsp;I am almost finished with the&nbsp;communications interface using the frame APIs. Thanks anyway,
Dan

[DirkW]

Dan,
Sorry to hear that you could not get it running with the TK. Attached you can fin a CCP Logger example to log the CCP communication on a certain Bus. If you have a spare CAN port connected to the same Bus as your ECU communication is running, you could run this logger to log the low level CCP communication between your application and ECU.
Perhaps it helps fixing the seed Key issue if you see what the details are.
If you are still interested, please post the log file, so i could have a look to it.
DirkW


CCPLogger with A2L.llb:
http://forums.ni.com/attachments/ni/30/3310/1/CCPLogger with A2L.llb

[Colin hughes]

As the seed is different each time, there was no way to copy an old key code copied from Vision.
I dont think&nbsp;that the&nbsp;steps tacken&nbsp; to unlock the ECU was ASAM valid hence the Toolkit failed.
Some calls must be in Intel format even if the rest is Motoroler (ASAM2 specs).
The code reverses the four&nbsp;seed code bytes before getting the Key then reverses the four Key byte before Unlocking the ECU.
How would the Toolkit know that it needed to do this as I can not find anything in the ASAM spects that require this.
Am I missing something here.
&nbsp;
The a2l file was invalid and fails using the Vector a2l Editor, the first line was (version number) .
There was new and old ASAM Version formats mixed together.
I failed to fix all the problems.
&nbsp;
Our inhouse a2l files are also invalid as created by the tool used, but I have managed to fix all the problems with&nbsp;the file
so the it loads OK with the Toolkit except that the number of measurements are&nbsp; around 13,000 ( 19,500 with carateristics&nbsp;) which is slow to load and some time, times out loading.
As we are not using a seed key I forsee no problem but I am unable to test untill I have a test ECU.
The only problem I see is that there&nbsp;are some odd bits added&nbsp;by Vision to get there software working with our ECU.
If this proves to be&nbsp; a problem would NI do the same to&nbsp;get there Toollkit working with our ECU?
&nbsp;
Ta
Colin
Delphi
&nbsp;
&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

[Troy K]

Dan 55, you say you built your own .A2L parser? I was just about to do this myself. I don't suppose you would consider posting your vis? Thanks,&nbsp;:smileywink:Troy