Repair chronology of SRS ECU from Volkswagen Crafter
Hello! Our team has been repairing and researching automotive electronics (and more) for more than ten years. We are looking into a third party device BY, and develop utilities for interacting with firmware and programs. We are often faced with interesting problems. On the pages of this blog we plan to share interesting research and renovation stories. We hope that our experience can be useful to other professionals in this field. Today we want to share a case of block repair SRS from Volkswagen Crafterwhich helped us drill down into details and identify important points.
ЭБУ SRS
number 5QF 959 655 AH
. In order to make sure that the control unit needs to be repaired, in our company the equipment under test is first started on the table.
The control unit was diagnosed by CAN bus platform CantracerFD via interface Tactrix OpenPort 2.0. It could also be considered other car diagnostic tools VAG. As we can see, the block contains a current internal error B2000
. In cars of the group of companies VAG
such errors are indelible and can only be removed by modifying the dumps ЭБУ SRS
.
The control unit being repaired contains a processor Infineon Tricore TC233-32
series. Previously, we came across similar blocks, but there was a processor TC222-16
series. The dumps are very similar, but are slightly larger in size. Therefore, the first thing that was done was the analysis and comparison of dumps with analogues of donor ЭБУ
. Donor numbers:
5QF959655L
(TC22xx-16)
5QF959655A
5QF959655AA
An initial analysis of the dump showed that the block was divided into three sections. Sections are separated from each other by headings:
3A F5 AF AF F5 F5 AF AF
Initially, we turned to the forums for help, where we were offered to completely erase the third section. Cleaning the third section did not cause any changes in the control unit. Thus, it was determined that the internal error was in the second section and needed to be corrected. Changes in the second section caused many internal errors to appear in ЭБУ,
indicating a violation of the integrity of the dump. The next step was to conduct a more in-depth analysis of the dump. We looked at the signatures of data blocks, the fragments that make up the dump, where they start and where they end, where the block type is determined, where the block size is determined, where the block flags are determined, where the checksum is, and so on. Parsing such a large dump manually is a time-consuming task. We decided to automate the process; for this purpose, a script was written in the language Python. Before writing the script, we discovered the checksum algorithm, it is defined in the format:
CRC-16/CCITT-FALSE
The dumps were then processed with a calculator. We checked both the original dump, which contains an internal error, and the donor dumps, which do not contain it. During the process, it was discovered that the checksum did not match across three blocks. We did not edit them, because these same blocks on donor dumps have the same problems. Next, we carried out an analysis by comparing blocks from which everything unnecessary was removed, and there was only data. To do this, the script was modified to sort data blocks by type. A comparison was made of blocks of the same type. Below is a screenshot of a comparison of text reports from a script that determines block types. It can be seen that the block is of the type 0х400
size 0x468
and the size of the donor block is 0x5F0
it is on the left.
This method helped us allocate a block of data like 0хА00
the contents of which are radically different from the donor, and it has been assumed that for this reason an internal error is being recorded ЭБУ
.
After which this block of data was transferred from the donor entirely to our original dump. Replacing a block with a type 0xA00
caused the internal error to disappear. In addition, we modified the block in which errors are stored and recalculated the checksum so that ЭБУ
was fully functional.
As a result, it is important to note that analysis of the dump structure and identification of checksums are key stages in the process of repairing electronic components of cars. Using the program on Python
to analyze dump blocks makes an approach to eliminating errors and restoring the functionality of the block SRS
more efficient. In addition, copying data from the donor block and then removing errors with checksum correction is important for the accuracy and reliability of the recovery process. The steps taken in our research not only eliminate errors in the block SRS
but also guarantee the safety and reliability of the vehicle’s passive safety system. It is important to emphasize that the process of repairing electronic components requires high qualifications and a careful approach to each stage.