Automotive and Embedded Networks
ECU Flashing Using ADCS Toolkit
Hi,
I have encountered some problems in the process of using ADCs toolkit to implement ECU program brushing. I hope to get your professional guidance here.
I have correctly resolved the file of S record that should be downloaded to ECU, divided the data into blocks according to whether the data address is continuous or not, and calculated the length of each data block. I will discuss the problem with you based on the picture below.
After the program starts, the program in front of service 34 works fine (I'm not sure if it's correct), but every time it starts at service 34, it starts reporting consecutive errors, including services 36 and 37. The error code is "-8000"（The handle passed to the function is not valid）.
For the 34 service, "0x00600000" is the starting address of the first data block, and "0x94" is its length. The block data information is not encrypted or compressed, and the address and length of the block data to be stored are represented by 4 bytes.
For the 36 service, the one-dimensional array you see in the loop structure is the first piece of data parsed out, and of course, the size of the one-dimensional array matches the length of the data block. "512" (0x200) is the number of bytes the 36 service should transfer each time, so I did a For loop that called the 36 service multiple times based on the size of the data block. However, the results were disappointing, and the use of all three services reported errors.
It is difficult to find examples for the use of the ADCs toolkit. It is the first time for me to contact relevant programming, so THE editing of data transmission program is completed by myself. If there are some low-level mistakes in the figure above, I hope you professionals can help point out. Thank you!
What you showed looks very similar to the type of work I've seen in the past. One thing I'd comment on is how you can't see if the values for those numerics are in hex or decimal. If you right click and go to Visible >> Radix, you can then verify that it really is 0x96, and not 0d96.
Anyway here is a screenshot of something similar I've done in the past for UDS flashing. This uses the 34, 36, and 37 routines.
There are a few optional things, like updating a progress by using a queue which can be ignored. I also added 3 tries if there were flashing errors but honestly I think this is left over from debugging and if it fails once it should probably just give up.
Also you might notice that the Block Sequence Counter in my case goes from 1 to 0xFF, then 0 to 0xFF over and over, and it downloads data in 0xF00 size chunks. I think with your 0x600000 bytes to download, at only 0d512 at a time, you'll have your block values go up past 0d12288, which is larger than the one byte the block sequence allows. Although now that I'm thinking about it, it would probably just roll over just fine. I can't really give much other advice, other than it looks like you are on the right track. If you can log traffic from a successful flash, maybe reviewing what was sent can help you figure out what is wrong.
Thank you for your reply. I think it has helped me a lot to some extent. I'm going to share with you some of the new problems I've encountered, and I look forward to your continued guidance.
The data transfer phase program involves 34,36 and 37 services. The array in the loop is the data to be uploaded copied from the S19 file after parsing. The loop stop parameter 2 is limited to the small size of the block data and is only used for experiments.
Packet monitoring is as follows:
Problem 1: The message shows that THE ECU rejected Tester's request 34, but according to the message, data can be transmitted. It is not clear why the rejection is 7F 11 solution.
Problem 2: The block 1 data transmission packet is not displayed. The error code is "8257" (the transport layer receives out-of-order frames), but the start address of the second block is based on the size of the block 1 data. The second block of data transmission is not complete, the error is reported because the receiving flow control frame timeout.
Okay lets try this one at a time
10 0B 34 00 44 40 00 10
This is saying: I have 0d11 bytes of data to send you, the first 6 bytes are 34 00 44 40 00 10.
The ECU then replies with: 30 00 0F
This is saying I'm ready to get the rest of the data from you, send as many frames as you want, but they need to be separated by 16 ms.
Then you send the remaining bytes which are: 21 00 00 00. There are more but we said we were only sending 0xB bytes (0d11) and since we already sent 6, we only need to send another 5.
The ECU then replies with a negative response. I think it is either saying "Service not supported in active session" or "Service not supported". Is your ECU in the programming session? Does it need to be unlocked with a Seed/Key? Most ECUs won't let you program them unless they are in programming, and after going into programming most need an unlock routine.
After that I do still see another issue.
10 FA 36 02 54 00 07 B8
If this is the first frame in a series of them, then we are saying we have 0xFA bytes (0d250) to send, and the first 6 is 36 02 54 00 07 B8. The next step is to wait for the flow control message telling us how many to send, and what kind of delay we should have. But instead I see it starts sending data 7 bytes at a time. Each frame that starts with a 0x2[0-F]. Later there is the 30 08 0F which tells us you can only send 8 frames at a time, with a 16ms wait between them. Looking at the state machine for the ISO-15765, after we send a first frame, we should then go to the reading state looking for that flow control. We shouldn't send more data until we get that flow control.
I worry that the core of this code comes from me. If so is it possible you have an older version of the code that didn't handle flow control?
Ah yes another challenge. So for me the calculation is a CRC 32, using a calculation found here. First you will probably want to figure out the LabVIEW implementation of the CRC just for performance reasons. Calling external code for the calculation is likely going to be slower then just doing it in LabVIEW. If you do find the LabVIEW code is slower, then you can post the code here to see if there are any optimizations that can be made, like precalculating the CRC lookup tables.
But even with this I've also found that the CRC calculating part of the code is a bit slow. In the past I've often been asked to flash many parts one at a time. Here I'll be flashing the same file over and over, with the same CRC. So I have code that will look at the flash file, then calculate the CRCs, then store that somewhere in a temp folder. If that file is ever flashed again I can look at the temp folder and see if the CRC has already been calculated and just use that.
A third option that I haven't tried yet, but is probably the best, would be to calculate the CRC, in parallel to the flash taking place. Spawning an asynchronous process, or having a parallel loop controlled by a channel wire might be a good idea. If this is slower than flashing, then you can still cache the result in a temp location, then read it again next time.
