Map offsets for 32bit SUBARU DENSO ECUs (DBW & NON-DBW)

[New2Scoobs]

Again, which cars have a 32bit denso ECU?

if it matters so much, if rom size is 512kb or 1024kb then it is 32bit

Cool, 1 thing less for me to worry about

[Freon]

I believe "2.5L Turbo," "DBW/ETC," and "32bit SH2 processor" are all tied to one another. 2.0L Turbos are all 16bit and 160/192kb, cable throttle.

Basically, there are only two basic architectures for the 2.0L and 2.5L Subaru H4 turbo engines. I don't think there are any 2.0L DBW 32bit models, nor any 2.5L cable throttle 16bit models.

I think this applies to pretty much all markets. Maybe there are some exceptions or I'm missing a group of models, but that's the majority of it.

XSwrx: Awesome work. This is exactly what I need, as someone who can't decompile the ROMS, to actually finish out the XML for my car. I'll try to find some time over the next few days to get my ROM mapped out a bit to help serve as an example.

[Freon]

I played with it a bit on some 3D maps I found (where I could only find the data). It sorta makes sense. I'm doing searches on data with the data offsets I know and found a portion of the rom that seems to have all the map definitions. I think I may scrap my whole XML and try to work down this portion of the ROM and use it directly to do all the mapping.

Odd thing is I'm not sure the row and column offsets are right. I checked a 15x18 map, and it seems the column data offset has the 16th, 17th, and 18th value after it that are of a pretty consistent increment as if they were supposed to be there. As if that offset could be the row offset as well. Both the row and column offsets are 18 32bit values long, or at least appear to be.

The row and columns all seem to be 32bit values so far, even on the 8bit data maps.

Before when I was analysing, I often found 2 or 4 copies of the same map. But now looking for the indicating map defintion, it seems some of these maps must be completely unused since I see no pointer to the data map even though 3D data is there.

[qoncept]

Freon, which tables? Fuel and timing (at least) likely have at least a few for different cam angles.

[NeverLies]

struct2D :
rowcnt :2bytes Rows count
databits :2bytes Type of data (0=32bit,4=8bit,8=16 bit)
rowofs :4bytes Rows offset
datofs :4bytes Data offset
if databits <> 0x0000 (32bit data dont have scalings, this is strange....)
mult :4bytes Multiplier for data
add :4bytes Addition to data

struct3D :
colcnt :2bytes Cols count
rowcnt :2bytes Rows count
colofs :4bytes Cols offset
rowofs :4bytes Rows offset
datofs :4bytes Data offset
databits :4bytes Type of data (0=32bit,4=8bit,8=16 bit)
mult :4bytes Multiplier for data
add :4bytes Addition to data

The mult and add must be interpreted as floating point numbers (4byte single)
Expression for data in XML: [data]*mult+(add)

2 things remaining
find the axis scalings (if they are in there)
match map definitions to map names

One thing remaining:

Axis scalings is IEE 754:

Conversion: The value of a IEEE-754 number is computed as:

sign * 2exponent * mantissa

The sign is stored in bit 32. The exponent can be computed from bits 24-31 by subtracting 127. The mantissa (also known as significand or fraction) is stored in bits 1-23. An invisible leading bit (i.e. it is not actually stored) with value 1.0 is placed in front, then bit 23 has a value of 1/2, bit 22 has value 1/4 etc. As a result, the mantissa has a value between 1.0 and 2. If the exponent reaches -127 (binary 00000000), the leading 1 is no longer used to enable gradual underflow.

Epifan, it would be nice if we could write such formula in EcuEdit

[xswrex]

I played with it a bit on some 3D maps I found (where I could only find the data). It sorta makes sense. I'm doing searches on data with the data offsets I know and found a portion of the rom that seems to have all the map definitions.

yes that is a good one.
actually there is an "index table" with the single offsets and right after that the map definitions follow.

[xswrex]

One thing remaining:

Axis scalings is IEE 754:

Conversion: The value of a IEEE-754 number is computed as:

sign * 2exponent * mantissa

The sign is stored in bit 32. The exponent can be computed from bits 24-31 by subtracting 127. The mantissa (also known as significand or fraction) is stored in bits 1-23. An invisible leading bit (i.e. it is not actually stored) with value 1.0 is placed in front, then bit 23 has a value of 1/2, bit 22 has value 1/4 etc. As a result, the mantissa has a value between 1.0 and 2. If the exponent reaches -127 (binary 00000000), the leading 1 is no longer used to enable gradual underflow.

Epifan, it would be nice if we could write such formula in EcuEdit

32bit mystery is revealed! Now we can interpret axis and 32bit data!
kudos to you NeverLies

[xswrex]

may i proudly present.....(sorry for the formatting)

MY06 STi Main Ignition map

3D MAP
Offset 7C3B0 508848
Col count:19
Col offset:000CA26C 828012
Row count:18
Row offset:000CA2B8 828088
Data offset:000CA300 828160
Data type:8bit 04000000
Data multiplier:0.3515625000000000 3EB40000
Data addition:-20.0000000000000000 C1A00000

LOAD/RPM 0.25 0.40 0.55 0.70 0.85 1.00 1.15 1.30 1.45 1.60 1.75 1.90 2.05 2.20 2.35 2.50 2.65 2.80 2.95
800.00 20.08 31.68 28.87 25.35 17.62 9.88 4.26 -1.37 -3.13 -3.13 -3.13 -3.13 -3.13 -3.13 -3.13 -3.13 -3.13 -3.13 -3.13
1200.00 29.92 41.17 38.01 34.49 30.27 19.02 12.70 8.48 4.96 1.45 -2.07 -2.07 -2.07 -2.07 -2.07 -2.07 -2.07 -2.07 -2.07
1600.00 34.84 45.74 42.23 39.41 35.90 30.27 21.84 14.80 8.48 3.55 1.80 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04
2000.00 40.12 49.26 49.26 42.93 38.71 34.49 30.98 23.95 14.80 10.94 7.07 3.55 0.04 0.04 0.04 0.04 0.04 0.04 0.04
2400.00 49.26 49.26 49.26 46.45 43.63 40.82 33.79 26.76 21.13 15.51 9.88 4.26 0.04 0.04 0.04 0.04 0.04 0.04 0.04
2800.00 49.26 49.26 49.26 46.45 43.63 40.82 35.90 28.87 23.24 19.02 16.21 13.40 10.59 7.77 4.96 2.15 0.04 0.04 0.04
3200.00 49.26 49.26 49.26 46.45 43.63 40.82 37.30 32.38 26.05 20.43 16.91 14.10 11.64 9.88 8.13 6.37 4.61 2.85 1.09
3600.00 49.26 49.26 49.26 47.50 43.63 40.82 38.01 33.44 27.46 23.24 20.43 17.62 14.80 11.99 10.23 8.48 6.72 4.96 3.20
4000.00 49.26 49.26 49.26 47.50 43.63 40.82 38.01 33.79 28.87 24.65 20.43 17.97 15.51 13.40 11.99 10.59 9.18 7.77 6.37
4400.00 49.26 49.26 49.26 47.50 43.63 40.82 38.01 33.79 29.57 25.35 21.13 19.02 16.91 14.80 13.75 12.70 11.64 10.59 9.53
4800.00 49.26 49.26 49.26 47.50 43.63 40.82 39.77 37.66 34.49 31.33 28.16 25.35 22.89 20.43 17.97 16.21 14.45 12.70 10.94
5200.00 49.26 49.26 49.26 47.50 43.63 40.82 39.77 37.66 34.49 31.33 27.81 24.65 22.89 21.13 19.73 18.32 17.27 16.21 14.45
5600.00 49.26 49.26 49.26 47.50 43.63 41.88 40.12 37.66 35.20 32.03 28.87 26.76 25.35 23.95 22.19 19.73 18.32 16.91 15.51
6000.00 49.26 49.26 49.26 47.50 44.34 42.93 41.52 38.36 35.20 31.68 29.92 28.16 25.70 23.95 22.19 19.73 18.32 16.91 15.51
6400.00 49.26 49.26 49.26 47.50 44.34 42.93 41.52 40.12 38.71 36.60 33.44 30.27 28.16 26.05 23.95 22.19 20.43 18.67 16.91
6800.00 49.26 49.26 49.26 47.50 44.34 42.93 41.52 40.12 38.36 36.60 34.14 31.68 29.22 26.76 26.05 23.24 21.48 19.73 17.97
7200.00 49.26 49.26 49.26 47.50 44.34 42.93 41.52 40.12 38.36 36.60 34.14 31.68 29.22 26.76 26.05 23.24 21.48 19.73 17.97
7600.00 49.26 49.26 49.26 47.50 44.34 42.93 41.52 40.12 38.36 36.60 34.14 31.68 29.22 26.76 26.05 23.24 21.48 19.73 17.97

All we need now is a datatype in the map editing tools which interprets 32bit entries as single real number

[Freon]

Looks good so far.

For the mult and add bytes as xswrex describes, I see lots of 3F800000 (+1.0) for the multiplier, no addition, and in those circumstances the conversion expressions already known (toIgn, frIgn, toBoostBar, etc) work.

For the axis, IEEE 754 seems to result directly in the unit of measure expected. Air load g/s, rpm, etc. require no further expression to convert the value. IEEE754 supercedes the need for any expression for axis information. A checkbox in ecuedit that disabled (grey out) the sign, mul, byte order power, etc., and disabled the value via 754 would be perfect.

edit: or just add offset to map type functionality with the supplied information.

More visual aid for those



Note that all the map defs in the hex viewer are all in a row, you can just practically read up and down and see the patterns for all the map defs. Also, the mult and add values are also stored in IEEE754, you can see I manually converted 3B800000 to .00390625, and the WGD map values look spot on.

[cboles]

I've added support for float and double types in EcuFlash for the next release. Here's an example for an Ignition map based on what was presented here. The scalings for the map look like this:

Code: Select all

   <scaling name="Timing" units="degrees" toexpr="x*90/256-20" frexpr="(x+20)*256/90" format="%.1f" min="-20" max="70" inc="1" storagetype="uint8" endian="little"/>
   <scaling name="RPM" units="RPM" toexpr="x" frexpr="x" format="%.0f" min="0" max="10000" inc="50" storagetype="float" endian="little"/>
   <scaling name="Load" units="" toexpr="x" frexpr="x" format="%.2f" min="0" max="4" inc="0.05" storagetype="float" endian="little"/>


[xswrex]

also in ecuedit should be fairly easy to implement. I suppose it is coded in delphi, so "single" is the specific coding type. As is it implemented now [value] is an integer type. Add a [valuesomething] in the expression parser which is "single" and it is done

[ev8siv3]

also in ecuedit should be fairly easy to implement. I suppose it is coded in delphi, so "single" is the specific coding type. As is it implemented now [value] is an integer type. Add a [valuesomething] in the expression parser which is "single" and it is done

I smell XMLWrite v5 with EcuEdit/Enginuity output on 32-bit coming very soon! Great work guys!

[FrSTi]

Axis scalings is IEE 754:

Conversion: The value of a IEEE-754 number is computed as:

sign * 2exponent * mantissa

The sign is stored in bit 32. The exponent can be computed from bits 24-31 by subtracting 127. The mantissa (also known as significand or fraction) is stored in bits 1-23. An invisible leading bit (i.e. it is not actually stored) with value 1.0 is placed in front, then bit 23 has a value of 1/2, bit 22 has value 1/4 etc. As a result, the mantissa has a value between 1.0 and 2. If the exponent reaches -127 (binary 00000000), the leading 1 is no longer used to enable gradual underflow.

You rock !

[cboles]

There still needs to be endian support for floating point as well. x86 is big endian, SH2 is little. EcuFlash obeys the endian setting even when you use "float" and "double"

also in ecuedit should be fairly easy to implement. I suppose it is coded in delphi, so "single" is the specific coding type. As is it implemented now [value] is an integer type. Add a [valuesomething] in the expression parser which is "single" and it is done

[gregsachs]

I've added support for float and double types in EcuFlash for the next release. Here's an example for an Ignition map based on what was presented here. The scalings for the map look like this:

Looks good, i guess the question is when we'll get ecuflash w float support?
(i know, we're pushy; I was all set to sit down and do the 05sti definitions and ran into that wall;-)
thanks for all the work, should be ordering my cable shortly.