Pages: [1] 2 3
Author Topic: MED9.1 Create your own Measuring Blocks and log RAM locations with VCDS  (Read 47960 times)
Basano
Full Member
***

Karma: +90/-3
Offline Offline

Posts: 192



Whilst working on a ram logger for MED9.1, it struck me that it could also be useful to use VCDS to read ram locations as well. To be totally accurate, add ram locations to spare measuring blocks and then read these new measuring blocks with VCDS. I've posted some worked examples of exactly how to do this, but first a bit of background to explain.

Ram logging is my preferred option, but needs bespoke hardware and software. This alternative needs only VCDS and some changes to the MED9.1 bin. I wouldn't suggest changing every bin you work on! But it could help if you are looking at something non-standard or want a value that isn't already in the standard measuring blocks. YMMV.

You are making changes to your bin. Make sure you have a full backup (preferably BDM) before you start. Better yet, use a spare ecu. Also ensure that your flashing tool does a good job of checksums. If your ecu turns into a pumpkin, I am not responsible!

Background

In the MED9.1 bin, there are two tables relating to measuring blocks. In my flash, the first table is located at 0x001C 58C8 and consists of four columns. These are the four values you see in VCDS Measuring Blocks. The table doesn't contain actual values (it's flash after all), rather numerical pointers to a second table which has the flash memory addresses where the actual values are calculated.

The second table has just one column which contains the flash memory address of the assembly code that actually calculates the measured value. This second table is laid out in the same order as the section describing the internal ECU variables in the FR - Section 29.210.2 Testerkommunikation; Meßwerte lesen on page 4452. I've shown just the first ten entries of each table below. The full tables are in the attached spreadsheet. Also attached are a couple of pages from the FR showing what I'm talking about.

Table 1
VCDS Measuring Blocks
Table 4x255 KFMWNTK
Starts at address 0x001C 58C8


|Column|1|2|3|4|
|Start|0x001C 58C8|0x001C 5AC6|0x001C 5CC4|0x001C 5EC2|
|End|0x001C 5AC5|0x001C 5CC3|0x001C 5EC1|0x001C 60BF|
|Length|0x01FE|0x01FE|0x01FE|0x01FE|

|Measuring Block|1|2|3|4|
|0|0x0000|0x0000|0x0000|0x0000|
|1|0x0001|0x0050|0x001C|0x000D|
|2|0x0001|0x0002|0x0253|0x000A|
|3|0x0001|0x000A|0x0007|0x0009|
|4|0x0001|0x023B|0x0050|0x0055|
|5|0x0001|0x0002|0x0056|0x0057|
|6|0x0001|0x0002|0x0055|0x0044|
|7|0x0001|0x0002|0x0050|0x01F7|
|8|0x0000|0x0000|0x0000|0x0000|
|9|0x0472|0x0473|0x039A|0x0399|
|10|0x0001|0x0002|0x0007|0x0009|

Table 2
Internal ECU Variables
Table 1x2200
Starts at address 0x000A 7904


|Column|1|
|Start|0x000A 7904|
|End|0x000A 9B63|
|Length|0x2260|

|Decimal|Hex|1|
|0|0x0000|0x0003 931C|
|1|0x0001|0x0003 95B4|
|2|0x0002|0x0003 95C4|
|3|0x0003|0x0003 95D4|
|4|0x0004|0x0003 931C|
|5|0x0005|0x0003 931C|
|6|0x0006|0x0003 931C|
|7|0x0007|0x0003 95DC|
|8|0x0008|0x0003 95F8|
|9|0x0009|0x0003 9614|
|10|0x000A|0x0003 962C|

For example, let's say you read Measuring Block 3 with VCDS. From the VCDS label file 06F-907-115-AXX.lbl, you know that Measuring Block 3 contains:

003,1,Engine Speed
003,2,Intake Air Mass
003,3,Throttle Drive,Angle Sensor 1,for EPC (G187) | Display Range: 0...100 %
003,4,Ignition,Timing Angle

Looking at Table 1 in the MED9.1 bin, Measuring Block 3 looks like this:

3   0x0001   0x000A   0x0007   0x0009

This measuring block contains internal variables :

0x0001 (dec 1)
0x000A (dec 10)
0x0007 (dec 7)
0x0009 (dec 9)

Checking against the FR (Section 29.210.2 Testerkommunikation; Meßwerte lesen), you can see the correlation.

1 nmot (Motordrehzahl / Engine Speed)
10 mshfm_w (Luftmassenfluß / Air Mass Flow)
7 wdkba (Drosselklappenwinkel / Throttle Angle)
9 zwout (Zundwinkel / Firing Angle)

The second table, Table 2, points out the flash memory location of the code that calculates the internal variable:

0x0001 -> 0x0003 95B4
0x000A -> 0x0003 962C
0x0007 -> 0x0003 95DC
0x0009 -> 0x0003 9614

In the above example, Air Flow Mass 0x000A (dec 10) is calculated at 0x0003 962C:

Code:
ROM:0043962C                 lhz       r6, word_7FEE48
ROM:00439630                 cmplwi    r6, 0x3333
ROM:00439634                 bge       loc_439640
ROM:00439638                 mulli     r6, r6, 5
ROM:0043963C                 b         loc_439648
ROM:00439640 # ---------------------------------------------------------------------------
ROM:00439640
ROM:00439640 loc_439640:                             # CODE XREF: ROM:00439634j
ROM:00439640                 lis       r6, 0 # 0xFFFF
ROM:00439644                 ori       r6, r6, 0xFFFF # 0xFFFF
ROM:00439648
ROM:00439648 loc_439648:                             # CODE XREF: ROM:0043963Cj
ROM:00439648                 sth       r6, word_7FCD6E
ROM:0043964C                 extrwi    r5, r6, 8,16
ROM:00439650                 addi      r4, r6, 0
ROM:00439654                 li        r3, 0x19
ROM:00439658                 b         sub_43930C

The codes of interest for us are the first and last lines (lhz and b). The code starts by loading ram location 0x7FEE48. This is the actual ram location that contains the Air Mass Flow. The last line jumps back to the main code where the measuring blocks are processed by the various functions that output the Measuring Blocks when requested by VCDS.

You may have spotted that the flash memory location is 0x0003 962C, but the snippet from IDA starts at 0x0043 962C. That's just the way my IDA is configured and won't make a difference. All the address jumps are relative anyway.

IDA Settings
ROM @ 40 0000 size 20 0000
RAM @ 60 0000 size 30 0000
File at 40 0000 size 20 0000
TOC at 0x5C9FF0
SDA (r13) @ 0x7FFFF0
« Last Edit: April 29, 2014, 06:09:26 AM by Basano » Logged
Basano
Full Member
***

Karma: +90/-3
Offline Offline

Posts: 192



To make our own measuring blocks for ram locations we need a few things.

1) An unused entry in Table 1 to point to Table 2
2) An unused entry in Table 2 that can point to a flash memory location
3) A block of unused flash memory that can contain some assembly code
4) Some assembly code to pass the ram location we want to log to the various functions that handle the measuring blocks

Example 1 - Logging lambts_w (LambdaPartProtection) and lamfa_w (TargetAFRDriverRequest)
We've already worked out the ram locations of the above variables. I'm going to assume you can work this out yourself Smiley

lambts_w 0x802BFC
lamfa_w  0x802F7C

1) VCDS is already logging the Actual (lamsoni_w) and Specified (lamsbg_w) Lambda. In the VCDS label file, this is in Measuring Block 31 - Entries 1 and 2. Conveniently the 3rd and 4th entries are free, so we'll use these for our values.

031,1,Lambda Sensor,Current Value
031,2,Lambda Sensor,Specified Value

2) Look up this Measuring Block 31 in Table 1

31   0x002D   0x002B   0x0000   0x0000

3) Find some free entries in Table 2. Actual Lambda (lamsoni_w - 0x002D/45dec) and Specified Lambda (lamsbg_w - 0x002B/43dec) are in Table 2 already, so I picked some free pointers around that area. Free pointers is anything that points to flash memory location 0x0003 931C (the assembly at this location 0x0003 931C just sends 25 00 00 back to VCDS which means 'not used'). It's also handy to check against the FR to see that the pointers are not mentioned in the FR either. It doesn't matter, but it keeps it neat.

I've picked 36 and 37 in Table 2. The FR steps over these as well

34 fra2_w Lambda-Adaption fra (Bank 2)[0.5 ... 1.5] % 20 50 -50 ... <50 %
SY_STERVK=1
39 ushk_w Sondenspannung 1 hinter Kat Volt 66 10 0 ... 3.98 V

36   0x0024   0x0003 931C
37   0x0025   0x0003 931C

3) Find a free part of the flash. Free flash is normally a big block of FF FF FF FF FF FF FF FF ... In my flash, I've got unused space at 0x0007 C650. You could also check in IDA that there is no code or cross references in the area you think is free.

4) Now in this case I'm going to copy the assembly that's already used for Specified Lambda (lamsbg_w) since that will have the right scaling etc. So we just need to locate that assembly. Specified Lambda (lamsbg_w) is the second entry in Measuring Block 31 (0x002B/43dec). Looking up this entry (0x002B/43dec) in Table 2 gives me the flash memory location of the assembly code:
43   0x002B   0x0003 9A48

5) The assembly code at 0x0003 9A48:

Code:
ROM:00439A48 # ---------------------------------------------------------------------------
ROM:00439A48                 lhz       r5, word_7FCFE6
ROM:00439A4C                 srawi     r11, r5, 5
ROM:00439A50                 cmplwi    r11, 0xFF
ROM:00439A54                 bge       loc_439A60
ROM:00439A58                 srawi     r5, r5, 5
ROM:00439A5C                 b         loc_439A64
ROM:00439A60 # ---------------------------------------------------------------------------
ROM:00439A60
ROM:00439A60 loc_439A60:                             # CODE XREF: ROM:00439A54j
ROM:00439A60                 li        r5, 0xFF
ROM:00439A64
ROM:00439A64 loc_439A64:                             # CODE XREF: ROM:00439A5Cj
ROM:00439A64                 stb       r5, byte_7FC42F
ROM:00439A68                 li        r3, 0x1F
ROM:00439A6C                 li        r4, 0x14
ROM:00439A70                 b         sub_43930C

We'll copy this twice (once for lambts_w and again for lamfa_w) and substitute our own ram locations. Luckily we don't need to modify all this assembly! We're just interested in the first and last lines. The first line loads the ram variable and the last line jumps back to the main program that takes care of outputting the values to VCDS.

First line: lhz r5, word_7FCFE6
Last line: b sub_43930C

lhz
All the lhz references are relative to the SDA (r13) address (0x7FFFF0). You either add an offset for ram entries bigger than 0x7FFFF0 or subtract an offset for ram entries smaller than 0x7FFFF0. Negative numbers use two’s complement. Fortunately our two ram locations are both bigger than 0x7FFFF0 so we can just worry about positive numbers

lambts_w 0x802BFC
lamfa_w  0x802F7C

0x7FFFF0 + 0x2C0C = 0x802BFC
0x7FFFF0 + 0x2F8C = 0x802F7C

This works out to be
lhz r5, word_802BFC
A0 AD 2C 0C

and
lhz r5, word_802F7C
A0 AD 2F 8C

To get these opcodes (A0 AD 2C 0C and A0 AD 2F 8C), look at the attached MPCxxx Instruction Set. Look up the LHZ instruction. The last 16 bits are the offset (0x2C0C and 0x2F8C for our two variables respectively)

b
We need to branch back to 43930C, since that's where the main program is. However, all the branch instructions are relevant to our current address. Now that we've copied our code to 47C678/47C6A4, our current address where we jump back from will be different and we need to recalculate the branch instruction accordingly.

Current address 0x47C678/0x47C6A4 and we need to jump back to 0x43930C.
We need to subtract an offset from our current address. Two complement binary maths actually means we don't subtract, instead we add a negative number...

0x47C678 - 0x4336C = 0x43930C
0x47C678 + (-0x4336C) = 0x43930C
0x47C678 + 0xFFFBCC94 = 0x43930C

0x47C6A4 - 0x43398 = 0x43930C
0x47C6A4 + (-0x43398) = 0x43930C
0x47C6A4 + 0xFFFBCC68 = 0x43930C

This works out to be
b sub_43930C
4B FB CC 94
010010 111111101111001100100101 00

and
b sub_43930C
4B FB CC 68
010010 111111101111001100011010 00

To get these opcodes (4B FB CC 94 and 4B FB CC 68), look at the attached MPCxxx Instruction Set. Look up the B instruction. Bit 6 - 29 are the offset (0xFFFBCC94 and 0xFFFBCC68 for our two variables respectively).

I'm now going to work in hex since I found this easier. I'm sure there are other ways to go about this, this is just the approach I took.

Code we are going to copy:

Address        Opcode
0x00439A48 A0 AD CF F6
0x00439A4C 7C AB 2E 70
0x00439A50 28 0B 00 FF
0x00439A54 40 80 00 0C
0x00439A58 7C A5 2E 70
0x00439A5C 48 00 00 08
0x00439A60 38 A0 00 FF
0x00439A64 98 AD C4 3F
0x00439A68 38 60 00 1F
0x00439A6C 38 80 00 14
0x00439A70 4B FF F8 9C

Paste the copied code twice (x1 for lambts_w, x1 for lamfa_w) at the free space and modify the first and last lines of each copy

Address        Opcode
0x0047C650 A0 AD CF F6 first line A0 AD 2C 0C
0x0047C654 7C AB 2E 70
0x0047C658 28 0B 00 FF
0x0047C65C 40 80 00 0C
0x0047C660 7C A5 2E 70
0x0047C664 48 00 00 08
0x0047C668 38 A0 00 FF
0x0047C66C 98 AD C4 3F
0x0047C670 38 60 00 1F
0x0047C674 38 80 00 14
0x0047C678 4B FF F8 9C last line 4B FB CC 94
0x0047C67C A0 AD CF F6 first line A0 AD 2F 8C
0x0047C680 7C AB 2E 70
0x0047C684 28 0B 00 FF
0x0047C688 40 80 00 0C
0x0047C68C 7C A5 2E 70
0x0047C690 48 00 00 08
0x0047C694 38 A0 00 FF
0x0047C698 98 AD C4 3F
0x0047C69C 38 60 00 1F
0x0047C6A0 38 80 00 14
0x0047C6A4 4B FF F8 9C last line 4B FB CC 68

Now we need to apply all this to our bin. We need to change it in several places

1) The modified entries in Table 1
original
31   0x002D   0x002B   0x0000   0x0000
new
31   0x002D   0x002B   0x0024   0x0025
0x00 at 0x1C5D02
0x24 at 0x1C5D03
0x00 at 0x1C5F00
0x25 at 0x1C5F01

2) The modified entries in Table 2
original
36   0x0024   0x0003 931C
37   0x0025   0x0003 931C
new
36   0x0024   0x0007 C650
37   0x0025   0x0007 C678
0x00 at 0xA7994
0x07 at 0xA7995
0xC6 at 0xA7996
0x50 at 0xA7997
0x00 at 0xA7998
0x07 at 0xA7999
0xC6 at 0xA799A
0x78 at 0xA799B

3) The extra hex code at the free space 0x0007 C650
original
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
new
A0 AD 2F 8C 7C AB 2E 70 28 0B 00 FF 40 80 00 0C 7C A5 2E 70 48 00 00 08 38 A0 00 FF 98 AD C4 3F 38 60 00 1F 38 80 00 14 4B FB CC 94 A0 AD 2C 0C 7C AB 2E 70 28 0B 00 FF 40 80 00 0C 7C A5 2E 70 48 00 00 08 38 A0 00 FF 98 AD C4 3F 38 60 00 1F 38 80 00 14 4B FB CC 68

Then use a hex editor to paste this new hex into your bin.
« Last Edit: April 28, 2014, 06:12:35 AM by Basano » Logged
Basano
Full Member
***

Karma: +90/-3
Offline Offline

Posts: 192



I recommend that you load this patched binary in IDA again and disassemble. Double-check that the new assembly jumps back to the correct place. You must get the branch back to the main program correct! If you get it wrong and it jumps back randomly, some very funny things could happen. You have been warned

Here I've loaded my modified bin back into IDA and disassembled again. Looks OK and the first and last lines are as I'd calculated.

Code:
ROM:0047C650 # ---------------------------------------------------------------------------
ROM:0047C650                 lhz       r5, word_802F7C
ROM:0047C654                 srawi     r11, r5, 5
ROM:0047C658                 cmplwi    r11, 0xFF
ROM:0047C65C                 bge       loc_47C668
ROM:0047C660                 srawi     r5, r5, 5
ROM:0047C664                 b         loc_47C66C
ROM:0047C668 # ---------------------------------------------------------------------------
ROM:0047C668
ROM:0047C668 loc_47C668:                             # CODE XREF: ROM:0047C65Cj
ROM:0047C668                 li        r5, 0xFF
ROM:0047C66C
ROM:0047C66C loc_47C66C:                             # CODE XREF: ROM:0047C664j
ROM:0047C66C                 stb       r5, byte_7FC42F
ROM:0047C670                 li        r3, 0x1F
ROM:0047C674                 li        r4, 0x14
ROM:0047C678                 b         sub_43930C
ROM:0047C67C # ---------------------------------------------------------------------------
ROM:0047C67C                 lhz       r5, word_802BFC
ROM:0047C680                 srawi     r11, r5, 5
ROM:0047C684                 cmplwi    r11, 0xFF
ROM:0047C688                 bge       loc_47C694
ROM:0047C68C                 srawi     r5, r5, 5
ROM:0047C690                 b         loc_47C698
ROM:0047C694 # ---------------------------------------------------------------------------
ROM:0047C694
ROM:0047C694 loc_47C694:                             # CODE XREF: ROM:0047C688j
ROM:0047C694                 li        r5, 0xFF
ROM:0047C698
ROM:0047C698 loc_47C698:                             # CODE XREF: ROM:0047C690j
ROM:0047C698                 stb       r5, byte_7FC42F
ROM:0047C69C                 li        r3, 0x1F
ROM:0047C6A0                 li        r4, 0x14
ROM:0047C6A4                 b         sub_43930C

The final thing we need to do is update the VCDS label file to add an entry for these new values. Open up the label file 06F-907-115-AXX.lbl and edit it to include the following.

031,0,Lambda Regulation (Constant Operation of Lambda Probes)
031,1,Lambda Sensor,Current Value
031,2,Lambda Sensor,Specified Value
031,3,TargetAFRDriverRequest
031,4,LambdaPartProtection

Here's what it looks like when you read the Measuring Block. You can see the new values that you have created (TargetAFRDriverRequest and LambdaPartProtection).



I've included a log where you can see the Lambda values. The Specified Lambda starts by following the Driver Requested Lambda and then changing to follow LamdaPartProtection.


Logged
Basano
Full Member
***

Karma: +90/-3
Offline Offline

Posts: 192



Example 2 - Logging rl_w

What if you can't find a similarly scaled measuring block or you want the raw value? In this case, there's a useful item in the Measuring Blocks called 'count'. It's simply (a*256 +b). So if you want to monitor a 16 bit value, you can use this assembly:

Code:
ROM:00442AF0 # ---------------------------------------------------------------------------
ROM:00442AF0                 lhz       r5, word_80299C
ROM:00442AF4                 li        r3, 0x36
ROM:00442AF8                 srawi     r4, r5, 8
ROM:00442AFC                 b         sub_43930C

How did I derive this?

1) Look in the VCDS label file for anything called 'count'. For example:

085,4,Ignition Cycle,Counter

2) Find this entry in Table 1 (it's the 4th column - 0x05F0)

85   0x05ED   0x05EE   0x05EF   0x05F0

3) Look up this pointer (0x05F0) in Table 2. This gives me the flash memory location (0x0004 2AF0)

1520   0x05F0   0x0004 2AF0

4) We know that this assembly is just going to do this (a*256 +b) and send it out. So we'll be able to copy / paste the assembly at 0x0004 2AF0 into an unused part of the flash and modify it to read the ram location you are interested in.

In this example I'm going to log rl_w. I know it's a 16 bit value, but I can't really spot an existing similar measuring block that would already have the correct scaling. I'm going to output the raw value and process it later in Excel. This is straightforward since the scaling values are already present in WinOLS. Find a map with load (e.g. KFMIRL), right click to look at the properties and the scaling is right there (0.023438).

Just like in the first example, I've already looked up the ram location containing rl_w (0x7FEE58)

1) Find a free measuring block entry in Table 1. In this case, it looks like the whole of Measuring Block 8 is free, so we'll use the first entry in that.

8   0x0000   0x0000   0x0000   0x0000

2) Pick an unused pointer from Table 2. Unused is anything pointing to 0x0003 931C (the assembly at this location 0x0003 931C just sends 25 00 00 back to VCDS which means 'not used'). I've decide to use 11 since it is free in both Table 2 and also the FR. The FR steps right over it:

10 mshfm_w Luftmassenfluß SY_HFM>0 g/s 25 var 0 ... 364 g/s
13 XXXXXXXX Flagregister: Bits 16 FFh

11   0x000B   0x0003 931C

3) Find a free part of the flash. Free flash is normally FF FF FF FF FF FF FF FF ...In my flash, I've got unused space at 0x0007 C6A8. You could also check in IDA that there is no code or cross references in the area you think is free.

4) As explained before, I'll copy the assembly used for the 'count' function and modify it to use my ram location of rl_w (0x7FEE58)

Code:
ROM:00442AF0 # ---------------------------------------------------------------------------
ROM:00442AF0                 lhz       r5, word_80299C
ROM:00442AF4                 li        r3, 0x36
ROM:00442AF8                 srawi     r4, r5, 8
ROM:00442AFC                 b         sub_43930C

Same as before, we'll need to modify the first and last lines.

First line: lhz r5, r5, word_80299C
Last line: b sub_43930C

lhz
All the lhz references are relative to the SDA (r13) address (0x7FFFF0). You either add an offset for ram entries bigger than 0x7FFFF0 or subtract an offset for ram entries smaller than 0x7FFFF0. This time we are subtracting so we'll need to calculate the two's complement value

rl_w 0x7FEE58

0x7FFFF0  - 0x1198 = 0x7FEE58
0x7FFFF0  + (-0x1198) = 0x7FEE58
0x7FFFF0  + 0xFFFFEE68 = 0x7FEE58

This works out to be
lhz r5, word_7FEE58
A0 AD EE 68

To get this opcode (A0 AD EE 68), look at the attached MPCxxx Instruction Set. Look up the LHZ instruction. The last 16 bits are the offset (0xFFFFEE68 for our variable)

b
We need to branch back to 43930C, since that's where the main program is. However, all the branch instructions are relevant to our current address. Now that we've copied our code to 47C6B4, our current address where we jump back from will be different and we need to recalculate the branch instruction accordingly.

Current address 0x47C6B4 and we need to jump back to 0x43930C.
We need to subtract an offset from our current address. Two complement binary maths actually means we don't subtract, instead we add a negative number...

0x47C6B4 - 0x433A8 = 0x43930C
0x47C6B4 + (-0x433A8) = 0x43930C
0x47C6B4 + 0xFFFBCC58= 0x43930C

This works out to be
b sub_43930C
4B FB CC 58
010010 111111101111001100010110 00

To get this opcode (4B FB CC 58), look at the attached MPCxxx Instruction Set. Look up the B instruction. Bit 6 - 29 the offset (0xFFFBCC58 for our variable)

Code we are going to copy:

Address        Opcode
00442AF0 A0 AD 29 AC
00442AF4 38 60 00 36
00442AF8 7C A4 46 70
00442AFC 4B FF 68 10

Paste the copied code at the free space and modify the first and last lines

Address        Opcode
0x0047C6A8 A0 AD 29 AC first line A0 AD EE 68
0x0047C6AC 38 60 00 36
0x0047C6B0 7C A4 46 70
0x0047C6B4 4B FF 68 10 last line 4B FB CC 58

Now we need to apply all this to our bin. We need to change it in several places

1) The modified entries in Table 1
original
8   0x0000   0x0000   0x0000   0x0000
new
8   0x000B   0x0000   0x0000   0x0000
0x00 at 0x1C58D8
0x0B at 0x1C58D9

2) The modified entries in Table 2
original
11   0x000B   0x0003 931C
new
11   0x000B   0x0007 C6A8
0x00 at 0xA7930
0x07 at 0xA7931
0xC6 at 0xA7932
0xA8 at 0xA7933

3) The extra hex code at the free space 0x0007 C6A8
original
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
new
A0 AD EE 68 38 60 00 36 7C A4 46 70 4B FB CC 58

Then use a hex editor to paste this new hex into your bin.

I recommend that you load this patched binary in IDA again and disassemble. Double-check that the new assembly jumps back to the correct place. You must get the branch back to the main program correct! If you get it wrong and it jumps back randomly, some very funny things could happen. You have been warned

Here I've loaded my modified bin back into IDA and disassembled again. Looks OK and the first and last lines are as I'd calculated.

Code:
ROM:0047C6A8 # ---------------------------------------------------------------------------
ROM:0047C6A8                 lhz       r5, word_7FEE58
ROM:0047C6AC                 li        r3, 0x36
ROM:0047C6B0                 srawi     r4, r5, 8
ROM:0047C6B4                 b         sub_43930C

Again, the final thing we need to do is update the VCDS label file to add an entry for these new values. Open up the label file 06F-907-115-AXX.lbl and edit it to include the following.

008,1,Engine Load (rl_w)

Here's what it looks like when you read the Measuring Block. You can see the new values that you have created (Engine Load (rl_w)).



I've also included a log where you can see the standard Engine Load entry that is capped at 191.7%. Our new Engine Load entry that we have created now passes this ceiling and gives us the actual load (just remember to scale it by 0.023438).


« Last Edit: April 28, 2014, 06:23:18 AM by Basano » Logged
ddillenger
Hero Member
*****

Karma: +641/-21
Offline Offline

Posts: 5640



This is excellent.

Would you be willing to share your IDA project? Feel free to say no. No pressure here.
Logged

Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your experience!

Email/Google chat:
DDillenger84(at)gmail(dot)com

Email>PM
technic
Full Member
***

Karma: +18/-5
Offline Offline

Posts: 227



Although I haven't digged in to it yet, I can just say : Wow! Amazing writeup.
Logged
Beaviz
Full Member
***

Karma: +8/-4
Offline Offline

Posts: 190



Amazing writeup! Will definitely be looking more into the details the next couple of days.
Logged
TCSTigersClaw
Sr. Member
****

Karma: +15/-6
Offline Offline

Posts: 353




Applaud ! Great work ! thank you  Smiley
Logged

VAG cars newbie tuner Smiley
prj
Hero Member
*****

Karma: +1067/-476
Offline Offline

Posts: 6004



I love it. Give you a little bone and lots of good things come out of it.
Well done, very well done indeed! Keep it up!
Logged

PM's will not be answered, so don't even try.
Log your car properly - WinOLS database - Tools/patches
Basano
Full Member
***

Karma: +90/-3
Offline Offline

Posts: 192



Would you be willing to share your IDA project? Feel free to say no. No pressure here.

Yes, of course! I've attached the IDB files to the first post.

All, thank you for your encouraging words Smiley Hopefully this can be of use for all (make it a sticky if you think it's worthy)
Logged
BenR
Jr. Member
**

Karma: +2/-1
Offline Offline

Posts: 38



This is amazing work! Well done, absolutely excellent!
Logged
Nottingham
Full Member
***

Karma: +13/-1
Offline Offline

Posts: 204



Super job here Basano, however regarding your share .idb projects...
Could you please check the version as it appears to be blacklisted and therefore your projects cannot be opened.
Logged
dream3R
Hero Member
*****

Karma: +18/-8
Offline Offline

Posts: 1194



Keep up the good work, very interesting reading Smiley

The file you asked for was found on this forum when I searched (someone sent me it though)

http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=1085.0;attach=2764

HTH
« Last Edit: July 07, 2014, 05:07:27 AM by dream3R » Logged



How to work out values from an A2L Smiley

http://nefariousmotorsports.com/forum/index.php?topic=5525.msg52371#msg52371


Starting Rev's http://nefariousmotorsports.com/forum/index.php?topic=5397.msg51169#msg51169

noobs read this before asking http://nefariousmotorsports.com/forum/index.php?topic=9014.0title=


ORGORIGINAL 05 5120 creator for Volvo
ORIGINAL Datalogger (Freeware) Author
ORGINAL finder of the 'extra' torque' limits
I don't have ME7.01 A2L I just use ID
Basano
Full Member
***

Karma: +90/-3
Offline Offline

Posts: 192



Super job here Basano, however regarding your share .idb projects...
Could you please check the version as it appears to be blacklisted and therefore your projects cannot be opened.
I had a look at the IDA version - it's 6.1

I run it in it's own little vitual machine (using Oracle VM Virtual Box).

If necessary, I can always post up the bin plus my IDA settings (SDA, TOC, ROM and RAM) and if you disassemble in another version it should come out the same.

Keep up the good work, very interesting reading Smiley

The file you asked for was found on this forum when I searched (someone sent me it though)

http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=1085.0;attach=2764

HTH
Thanks  Grin
Logged
de_Fre
Jr. Member
**

Karma: +7/-2
Offline Offline

Posts: 25


« Reply #14 on: October 26, 2014, 01:53:48 AM »

Putting my first steps in Assembly / Disassembly.

I used the steps provided by Basano, above, to find the raw variable for engine load. Then I made a little function that scales the Engine Load. It is pretty accurate, and allows to log above 191,7%

This was made for software version 1K0907115K , 0261S02332 , 386821

7FEDE9 is the raw variable for Engine Load in my software version, and the free space i used was at position 0x7c710

ROM:0047C710                 lhz       r5, word_7FEDE9
ROM:0047C714                 srawi     r5, r5, 5
ROM:0047C718                 srawi     r4, r5, 1
ROM:0047C71C                 add       r5, r5, r4
ROM:0047C720                 srawi     r5, r5, 1
ROM:0047C724                 li        r3, 0x36 # '6'
ROM:0047C728                 srawi     r4, r5, 8
ROM:0047C72C                 b         sub_43930C

Code in Hex

A0AD   EDF9   7CA5   2E70   7CA4   0E70   7CA5   2214   7CA5   0E70   3860   0036   7CA4   4670   4BFB   CBE0


Thx Basano for the good info on here.
Logged
Pages: [1] 2 3
  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Page created in 0.093 seconds with 17 queries. (Pretty URLs adds 0s, 0q)