Automotive and Embedded Networks

Showing results for 
Search instead for 
Did you mean: 

Automotive Diagnostic Command Set USB Transfer Data Error

So I have the Automotive Diagnostic Command Set (ADCS), and things are more or less working well but am getting some errors occasionally.  My main use for this is to read some DIDs, PIDs, and program the ECU.  After using some commercial software I now understand the set of commands that needs to take place to program the device, and I believe I have it working right.  But when I go to use it with the cheapo USB 8473 I'm having some errors, that appear to be coming from the toolkit itself.


So after putting the device in the mode where it can be programmed, I will issue the UDS Request Download, giving it the address and payload I am going to be sending.  I then sit in a while loop sending chunks of data down.  So each UDS Transfer Data call will send 1016 bytes of payload at a time.  Then after sending all the bytes I issue the UDS Request Transfer Exit, and go on to the next block of data.  Here is an image of this part of the application.

UDS Transfer Error 1.png


The issue I am having is that the software will get error -8262 randomly.  This error is associated with not getting a flow control frame from the ECU.  So I put an independent CAN device on the bus to see what is going on.  Here is the part where communication stops on one log I took.


12.943998 1 7EF Rx d 8 30 20 00 FF FF FF FF FF Length = 241910 BitCount = 125 ID = 2031
12.945006 1 7E7 Rx d 8 21 74 60 30 33 74 64 20 Length = 223910 BitCount = 116 ID = 2023
12.945298 1 7E7 Rx d 8 22 37 70 68 E0 01 07 04 Length = 229910 BitCount = 119 ID = 2023
12.945580 1 7E7 Rx d 8 23 1C 63 38 36 7C 63 20 Length = 223910 BitCount = 116 ID = 2023
12.945858 1 7E7 Rx d 8 24 AE 00 04 74 60 30 33 Length = 225910 BitCount = 117 ID = 2023
12.946136 1 7E7 Rx d 8 2B D2 2F 48 0D 77 C3 20 Length = 225910 BitCount = 117 ID = 2023
12.946411 1 7E7 Rx d 8 2C 37 70 E8 E0 01 6C 2E Length = 223925 BitCount = 116 ID = 2023
12.946695 1 7E7 Rx d 8 2D 1C E7 4E E0 07 3E 7C Length = 227925 BitCount = 118 ID = 2023
12.946979 1 7E7 Rx d 8 2E 87 F0 6E C1 57 D0 4F Length = 229910 BitCount = 119 ID = 2023
12.947251 1 7E7 Rx d 8 2F D1 5F C2 47 D2 4F 78 Length = 223910 BitCount = 116 ID = 2023
12.947529 1 7E7 Rx d 8 20 09 D2 13 E8 0C 30 0D Length = 225910 BitCount = 117 ID = 2023

It starts with the ECU giving a flow control frame stating it can accept 0d32 (0x20) frames before needing to rest and send another flow control frame, then my tester sends out only 0d11 frames and errors out stating it never got a flow control message from the ECU.  The thing that is interesting about this is that there is a jump in the index (the first byte) in consecutive frames sent.  The toolkit should always send a 0x2B after a 0x2A frame, but in this case we see 0x24 then 0x2B skipping 5 frames.  But when I looked at the data not only did we skip 0x25 through 0x2A, we actually skipped another 0d16 frames and should have went all the way around again.  So it seems the toolkit thinks it sent 0d32 frames (10 it actually sent and the 22 that it didn't).  So the tester now waits for a flow control frame to come that never will because it didn't actually send the right number of frames out.


In my testing the software will get this error at various points in the software, but has yet to complete a programming session.


Has anyone used these low cost CAN devices for flashing of ECU hardware?  Are they ill-equipped for this task?  Is this an issue with the write buffer on the hardware?  I was thinking about re-writing the core VIs of this toolkit to get more control but I assume that will likely be less efficient than the NI made toolkit since it has low level hardware access.  Oh and one thing I haven't tried yet is a retry mechanizm, but if the issue is with the toolkit or hardware I don't really want to patch on fixes like this.

0 Kudos
Message 1 of 44

We use the cheap ones to program ECUs, but not using ADCS.  They should be fine, hardware-wise.


I've also never used ADCS.  Could you be in a single shot transmit mode?  Is anything else happening on the bus at the same time?

0 Kudos
Message 2 of 44

I was not changing the behavior of single shot (writing it one way or the other) but I can try to set it to false just in case.  There is no other devices on the bus (other than a 3rd device to log raw frames for this test).  And the only traffic logged is between these two devices in the serialized manor normal to XCP or ISO15765.


I did add a retry and I am able to successfully program.  Looking at the log I only saw one retry was needed.

0 Kudos
Message 3 of 44

Well since I didn't seem to get much attention from NI, and since I had nothing better to do over the 3 day weekend, I decided to rewrite the core of the Automotive Diagnostic Command Set to work with the NI-CAN Frame API.  With this you can see what frames go in and out and where an error comes from if there is one.  I haven't fully tested this but it seems to work in my situation.  Adjusting the write buffer, or ensuring the buffer doesn't get full when writing might be an improvement that could be added.


This VI and it's dependencies can be used to replace the Diagnostic that is found in each call of the ADCS VIs.  This also opens the door to using the ADCS VIs on other CAN hardware since all that is needed is the VI to read and write frames.

Message 4 of 44

Hi Hooovahh,

Do you have a test VI that duplicates the missing consecutive frames when run against our demo ECU? I would like to try and reproduce the issue in house with different hardware to see why the frames would simply dissapear without any type of error.

Jeff L
National Instruments
0 Kudos
Message 5 of 44

The useful part of the code is the screenshot posted.  I tested that code with the Demo ECU with virtual CAN 256 and 257 and there was no error (it just took forever).  I also wired two CAN USB devices together and had the Demo ECU on CAN0 and my code talk to CAN1 and that also worked without an error.  To make this work I did have to disable other parts of the flashing process like writing DIDs, and RoutineControls which caused errors, likely because the Demo ECU didn't have those functions implemented.

0 Kudos
Message 6 of 44

I try to use NI PCI-8512 with LabVIEW 2015 and ADCS 2015 of kwp2000,but when using to write 20 bytes data,the error of "-8262:ISO TP:timeout receiving a Flow Control Frame" popup.
so I try the vi you provide(ISO 15765 Read Write Diagnostic to replace the Diagnostic in But,no matter when I use the global reference of "Diag CAN Handle" or "Channel Diag CAN Handle" of the kwp2000 global Cluster as the input parameter of "CAN Ref In" ,I got the error said CAN Handle is invalid, although both of them have value. Am I use the vi correctly?


0 Kudos
Message 7 of 44



If you want to directly ask the person who posted that code, you an always send them a message directly. Otherwise, to troubleshoot your original issue, you should probably create a new forum topic and you may generate some more activity.

Nolan H.
Applications Engineer
National Instruments
0 Kudos
Message 8 of 44

@NoHeart43 wrote:


If you want to directly ask the person who posted that code, you an always send them a message directly. Otherwise, to troubleshoot your original issue, you should probably create a new forum topic and you may generate some more activity.

Please do not send me messages to help fix your problem, that's what the forums are for.  So a group of people can contribute together.  That being said this has little (if anything) to do with my original issue and you should make your own thread instead of polluting mine.

0 Kudos
Message 9 of 44

hi Hooovahh, I'm trying to send/receive multi-frame CAN via Vector. I contacted Vector and asked if they had any source code for 15765 and sadly they said they don't and I'll have to implement on it on my own.

I tried using your ISO 15765 VIs you posted in this post but the VIs are for 2015 and I have LV 2014. I tried to use LV 2017 Evaluation version on another laptop to try to convert the files but one of them is password protected.

I also tried the 15765 package you posted on your blog but I could not install the OpenG Toolkit as it gave errors about version compatibility so the Integer to Enum VI didnt work.

So I'm thinking I could try to understand the 15765 protocol and implement at least a basic version of it using the Vector VI's you've linked before on this forum. I'm able to get those to run and I can send a single CAN message. Alternatively would it be easy for you to convert the best 15765 package you have for version 2014 or earlier? Thanks so much.

0 Kudos
Message 10 of 44