m box XDF error?

Pages: [1] 2 3 4

« previous next »

Author

Topic: m box XDF error? (Read 56438 times)

spen

Full Member

Karma: +43/-0
Offline

Offline

Posts: 112

	m box XDF error? « on: November 05, 2010, 11:00:23 AM »

A curious anomoly has arisen when comparing my output with Nyets m box data:

I'll use KFZW2 - ignition map.

   address   x axis   y axis
Spen   0x811d32   0x8100ff   0x8100c2
Nye   0x11D32   0x100FF   0x12B04

As you can see we disagree on the Y axis. Y axis in the xdf is RPM.

I offer up the following as evidence of why I am right:

Looking at the larger window at the back. r12 is loaded with 0x11d32. The scanning routine called by calls 0, unk_78B8 just looks in address range 0x81 + r12. This is the map itself being loaded.

Just under the map being loaded r13 is loaded with 0xfe. The routine at unk_78B8 treats r13 as a scale for the map. Again it looks at 0x81+r13 as before. This scale is the % load. The scale contains it's own length as the first byte, so the actual scale starts at 0x8100ff.

Now I differ on the remaining scale, the RPM scale. You can see the unk_78B8 routine being primed with the RPM by loading it in to r14. The ram address is 0x380f46.

Searching for writes to 0x380f46 reveals only one write. This is shown in the other window. Following the same logic as above we can see r12 loaded with 0xc1 before the scanning routine at unk_75d2 is called. This corresponds to a search at 0x8100c1 (and taking care of the byte for length gives 0x8100c2)

Therefore I assert that the remaining scale is at 0x8100c2 and is in bytes. In some other roms this scale is in words and has a different scanning routine.

There is a nice scale at 0x8100c1, of length 0x10. This scale is in bytes. It all seems to fit to me, but it would mean the M xdf is incorrectly scaled in some ignition maps.

What do you think? Have I missed something?


	Logged

iznogoud

Full Member

Karma: +13/-0
Offline

Offline

Posts: 104

Learning junkie

	Re: m box XDF error? « Reply #1 on: November 06, 2010, 05:51:54 PM »

(Why do you and he have an offset of 0x800000 ?)


	Logged

Audi S4 B5 2000 6sp Cactus Green
Audi A4 B6 Avant 1.8T 2001.5 5sp Santorin Blue

Tony@NefMoto

Administrator
Hero Member

Karma: +132/-4
Offline

Offline

Posts: 1389

2001.5 Audi S4 Stage 3

	Re: m box XDF error? « Reply #2 on: November 07, 2010, 12:32:31 PM »

Here is what I have from my definition:
address: 0x811D32
X axis: 0x8100FF
Y axis: 0x8100C2

Spen is right, Nyet is wrong.


	Logged

Remember you have to log in if you want to see the file attachments!
Info or questions, please add to the wiki: http://www.nefariousmotorsports.com/wiki
Follow NefMoto developments on Twitter: http://twitter.com/nefmoto

spen

Full Member

Karma: +43/-0
Offline

Offline

Posts: 112

	Re: m box XDF error? « Reply #3 on: November 07, 2010, 01:42:20 PM »

Cheers Tony. That was driving me mad. It also means that everyone is using the wrong RPM scales on a number of maps Shocked

I'll be able to output a number of XDF files soon enough and they'll be right in this department.

Iznogoud, My 'offsets' are not offsets, they are memory addresses as written / read by the ecu. Just take away 0x800000 to arrive at the file offset. Tunerpro works in file offsets, but I work in IDA.


	Logged

iznogoud

Full Member

Karma: +13/-0
Offline

Offline

Posts: 104

Learning junkie

	Re: m box XDF error? « Reply #4 on: November 07, 2010, 05:45:25 PM »

OK I see.

Tony, can you point us to your Mbox XDF file? Also, is your bin the same or different than Nye's? (We have already established that Audi put out 2 different Mbox bins.)

I will email him.


« Last Edit: November 07, 2010, 06:02:48 PM by iznogoud »	Logged

Audi S4 B5 2000 6sp Cactus Green
Audi A4 B6 Avant 1.8T 2001.5 5sp Santorin Blue

Tony@NefMoto

Administrator
Hero Member

Karma: +132/-4
Offline

Offline

Posts: 1389

2001.5 Audi S4 Stage 3

	Re: m box XDF error? « Reply #5 on: November 07, 2010, 10:22:07 PM »

I don't have a file per se. All of my map definitions are in code inside my ECU editing software. I will see if I can put something together to release in the near future.

My maps definitions were found by reverse engineering the ECU code. Nyet's defintions were done by cross referencing other defintion files against the S4 mbox data.


	Logged

nyet

Administrator
Hero Member

Karma: +607/-168
Offline

Offline

Posts: 12268

	Re: m box XDF error? « Reply #6 on: November 08, 2010, 03:19:53 PM »

For the record, do not trust ANY of my XDFs to be canonical. spen is obviously on the right track.. as he (and others) have said, my locations are from crossreferencing map data from other sources.

At the end of all this, can somebody summarize the errors in my xdf so I can update it?


	Logged

ME7.1 tuning guide
ECUx Plot
ME7Sum checksum
Trim heatmap tool

Please do not ask me for tunes. I'm here to help people make their own.

Do not PM me technical questions! 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 ex

spen

Full Member

Karma: +43/-0
Offline

Offline

Posts: 112

	Re: m box XDF error? « Reply #7 on: November 09, 2010, 02:36:56 AM »

Hiya. It's the RPM axis in the timing maps. Some maps use 8bit axis and some use 16 bit rpm axis.

I'll put together a matrix of ME7 timing map name and the axis locations for the M box.

For starters, in the M ecu, KFZW and KFZW2 have axis at file offsets:

X axis: 0x100FF
Y axis: 0x100C2


	Logged

iznogoud

Full Member

Karma: +13/-0
Offline

Offline

Posts: 104

Learning junkie

	Re: m box XDF error? « Reply #8 on: November 09, 2010, 08:56:39 AM »

Well... I am having much less luck with Nye's files.

I started pulling out the axes maps from his Mbox file using his Mbox XDF. I wrote a little code that parses the XDF, reads the BIN and does the work. I verified that what my code picks up is correct -- but I am known to be stupid at times.

Here is an example of a discrepancy I found. In the MAF voltage linearization I see a lot of bad data by just looking at the raw hex data, not even plotting them. Let's see if I can paste it here:

Code:

 --> "Linearization of MAF voltage" <--
  Cols (X) = 512 , Rows (Y) = 1
  Xaddress = 0x0 (0)
  Xsize in bytes: 1024
  Xdata:  ffd8 ffe0 0010 4a46 4946 0001 0101 00f0 00f0 0000 ffed 160e 5068 6f74 6f73 686f 7020 332e 3000 3842 494d 0404 0000 0000 002c 1c01 5a00 031b 2547 1c02 0000 0200 001c 0219 0016 5072 6f66 6573 7369 6f6e 616c 2070 686f 746f 7320 5334 0000 3842 494d 0425 0000 0000 0010 44e6 b4a2 e3ba a66e e247 b86f 102a 57df 3842 494d 03ed 0000 0000 0010 00f0 0000 0001 0001 00f0 0000 0001 0001 3842 494d 0426 0000 0000 000e 0000 0000 0000 0000 0000 3f80 0000 3842 494d 040d 0000 0000 0004 0000 001e 3842 494d 0419 0000 0000 0004 0000 001e 3842 494d 03f3 0000 0000 0009 0000 0000 0000 0000 0100 3842 494d 2710 0000 0000 000a 0001 0000 0000 0000 0001 3842 494d 03f5 0000 0000 0048 002f 6666 0001 006c 6666 0006 0000 0000 0001 002f 6666 0001 00a1 999a 0006 0000 0000 0001 0032 0000 0001 005a 0000 0006 0000 0000 0001 0035 0000 0001 002d 0000 0006 0000 0000 0001 3842 494d 03f8 0000 0000 0070 0000 ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff 03e8 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff 03e8 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff 03e8 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff 03e8 0000 3842 494d 0400 0000 0000 0002 0001 3842 494d 0402 0000 0000 0004 0000 0000 3842 494d 0430 0000 0000 0002 0101 3842 494d 042d 0000 0000 0006 0001 0000 0002 3842 494d 0408 0000 0000 0010 0000 0001 0000 0240 0000 0240 0000 0000 3842 494d 041e 0000 0000 0004 0000 0000 3842 494d 041a 0000 0000 0345 0000 0006 0000 0000 0000 0000 0000 0a20 0000 0f20 0000 0008 005f 004d 0053 0050 0030 0030 0034 0038 0000 0001 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 0000 0000 0000 0000 0000 0f20 0000 0a20 0000 0000 0000 0000 0000 0000 0000 0000 0100 0000 0000 0000 0000 0000 0000 0000 0000 0000 1000 0000 0100 0000 0000 006e 756c 6c00 0000 0200 0000 0662 6f75 6e64 734f 626a 6300 0000 0100 0000 0000 0052 6374 3100 0000 0400 0000 0054 6f70 206c 6f6e 6700 0000 0000 0000 004c 6566 746c 6f6e 6700 0000 0000 0000 0042 746f 6d6c 6f6e 6700 000a 2000 0000 0052 6768 746c 6f6e 6700 000f 2000 0000 0673 6c69 6365 7356 6c4c 7300 0000 014f 626a 6300 0000 0100 0000 0000 0573 6c69 6365 0000 0012 0000 0007 736c 6963 6549 446c 6f6e 6700 0000 0000 0000 0767 726f 7570 4944 6c6f 6e67 0000 0000 0000 0006 6f72 6967 696e 656e 756d 0000 000c 4553 6c69 6365 4f72 6967 696e 0000 000d 6175 746f 4765 6e65 7261 7465 6400 0000 0054 7970 6565 6e75 6d00 0000 0a45 536c 6963 6554 7970 6500 0000 0049 6d67 2000 0000 0662 6f75 6e64 734f 626a 6300 0000 0100 0000 0000 0052 6374 3100 0000 0400 0000 0054 6f70 206c 6f6e 6700 0000 0000 0000 004c 6566

Too many FFFF in there. What am I doing wrong. (I have not even started with the disassembly of the assembly stuff.)


« Last Edit: November 09, 2010, 09:00:30 AM by iznogoud »	Logged

Audi S4 B5 2000 6sp Cactus Green
Audi A4 B6 Avant 1.8T 2001.5 5sp Santorin Blue

iznogoud

Full Member

Karma: +13/-0
Offline

Offline

Posts: 104

Learning junkie

	Re: m box XDF error? « Reply #9 on: November 09, 2010, 09:05:46 AM »

Hmmmm... I see what is going on. I am setting defaults to ZERO for addresses of XAddress and YAddress of the XDF file. For that particular map there is no XAddress or YAddress, so I am point up to the top of the file by default.

Something I am not understanding about the XDF format maybe...?

But I see garbage for data on other maps that do not suffer from my bad assumptions. An example is the "Minimum Ingition Angle" 2D map. Even within TunerPro it looks like the axes have garbage for data, as do the data of the map itself. Ideas?


	Logged

Audi S4 B5 2000 6sp Cactus Green
Audi A4 B6 Avant 1.8T 2001.5 5sp Santorin Blue

iznogoud

Full Member

Karma: +13/-0
Offline

Offline

Posts: 104

Learning junkie

	Re: m box XDF error? « Reply #10 on: November 09, 2010, 09:35:50 PM »

Oh, this phaquing thing... I am so sick of running into this problem.

Just tried it again on my 32bit linux box. There is a difference... So, there is some issue with the addressing, and it manifests itself in two different ways. When I read the same binary on the 32bit and 64bit machines I see different results on the X and Y map addresses that I am reading. That's one problem that I should be able to trace. But here is another. I was seeing garbage on the data itself, as I noted above, for various maps. It turns out I was running TunerPro on the 64bit machine over "Wine" the windows compatibility API for linux. Whether it was the 64bit-ness or the fact that I am running it over Wine, I do not know. But I know I have an issue that is not related to the files I am using, but rather to the environment I am using.

At least now I know and you know too. Sorry for the threadjack.


	Logged

Audi S4 B5 2000 6sp Cactus Green
Audi A4 B6 Avant 1.8T 2001.5 5sp Santorin Blue

spen

Full Member

Karma: +43/-0
Offline

Offline

Posts: 112

	Re: m box XDF error? « Reply #11 on: November 10, 2010, 01:51:15 AM »

I have the same problem with hex turning in to garbage if I have too much wine Cheesy

[/topic]


	Logged

Tony@NefMoto

Administrator
Hero Member

Karma: +132/-4
Offline

Offline

Posts: 1389

2001.5 Audi S4 Stage 3

	Re: m box XDF error? « Reply #12 on: November 10, 2010, 12:25:32 PM »

I find my code runs best when I run with beer on the couch.


	Logged

iznogoud

Full Member

Karma: +13/-0
Offline

Offline

Posts: 104

Learning junkie

	Re: m box XDF error? « Reply #13 on: November 10, 2010, 02:37:05 PM »

Quote from: Tony@NefMoto on November 10, 2010, 12:25:32 PM

I find my code runs best when I run with beer on the couch.

I cannot work with beer or vodka -- it is one or the other. I can do math fine, if not better, with vodka/beer in hand but not code. Women tend to distract me and it is a non-linear function of their amount of clothing and apparel.

I did some map searching with my hacked up codes and tried to match Nye's bin to the Abox bin that I got from this site (both for the B5 S4 ECU). Attached is an HTML tabulation of addresses for Abox matched to Mbox in terms of axes addresses (not the data). I find multiple matches for some of the axes. I have not looked into it, but I am guessing that there are duplicate axes maps for multiple tables. This makes sense since you could have the most generality by allowing all tables to have their own axes maps, but at the end some of them have exactly the same data (say RPM values, or load values, etc). How do I separate apples from oranges here without looking at the assembly parts?

attached are the HTML file and the code I used.


« Last Edit: November 10, 2010, 02:41:59 PM by iznogoud »	Logged

Audi S4 B5 2000 6sp Cactus Green
Audi A4 B6 Avant 1.8T 2001.5 5sp Santorin Blue

Tony@NefMoto

Administrator
Hero Member

Karma: +132/-4
Offline

Offline

Posts: 1389

2001.5 Audi S4 Stage 3

	Re: m box XDF error? « Reply #14 on: November 10, 2010, 02:53:58 PM »

Some maps do share the same axis data.


	Logged

Pages: [1] 2 3 4

« previous next »

Jump to:

Navigation

Personal Tools

November 22, 2024, 11:09:42 AM

Welcome, Guest. Please login or register.
Did you miss your activation email?