Pages: 1 [2]
Author Topic: Q: Stock tune: has BMW messed up the KFMIRL map on my Motronic ME7.2 DME? A: No!  (Read 19921 times)
IamwhoIam
Hero Member
*****

Karma: +52/-115
Offline Offline

Posts: 1070


« Reply #15 on: April 04, 2013, 05:08:16 PM »

Me, or him? I know very little about the OLS. I checked a few maps and they looked reasonable.

Him of course, sorry for not being more precise Smiley
Logged

I have no logs because I have a boost gauge (makes things easier)
wreeve
Newbie
*

Karma: +1/-0
Offline Offline

Posts: 23


« Reply #16 on: April 05, 2013, 01:21:53 AM »

100% sure they are as BMW intended. How the BMW system works is you use WinKFP which is a BMW software utility to flash two files into the DME. A .0PA file. This is the 512kb (ish) firmware file. The program code as it were. And a 64kb (ish) tune file (the maps). BMW call these hardware number and assembly number respectively.

As far as I can understand the hardware number ties in with the Bosch number on the can of the DME. The 7532675 being used with Bosch number 0 261 207 106.

BMW use the ME7.2 used on the while range of vehicles, X5, E39, E38 or even the Alpina 4.8! The hardware file is the same and you choose the tune file depending on your application. I've attached a few here for you to look at.

So for example if you own an E39 540i from the US you would flash in the G7529055.0DA file along with the 7532675A.0PA file. Own a X5 4.6i you use the same .0pa file but use the G7533632.0DA file.

These are text files; so if you open them you can see which program version they are designed for; the tyre size; its transmission etc. etc.
Here is a screen shot of this process on my bench set-up using a spare DME:



“we” pull those .0DA files out as binary files using MPPS for instance and get the 64kb .Bin files.

Now these allow you to quickly find interesting areas of the tune file. For example finding the VMAX is a case of loading two different .0DA files with different max speeds and performing a binary compare. Apart from the check-sum location the only bytes changed are those from the VMAX register!
I don’t have a damos or .ols for this later version of the .0PA file which is why I am struggling a little with matching up some of the maps.

The 0DA files I have attached are ALL for the 7532675A.0PA program file I need to use.
G7529055.0DA : File for a 540iA vmax=210 extracted as a binary (G7529055.Bin)
G7533624.0DA: File for a X5 4.4is vmax=237 extracted as a binary (G7533624.Bin)
G7533632.0DA: File for a X5 4.6is vmax=300 extracted as a binary (G7533632.Bin)
7532675A.0PA: Program area file for all of the above tunes.

So I think what you are saying is the maps in the 7529055 hardware version are, as well as being in a physically different location, actually different dimensions to the maps in the previous version?

The KFMIRL map was the only one which “looked” strange. KFZQx look the same, KFZWOP looks the same.

I don’t have a damos or .ols for this later version of the .0pa file which is why I am struggling a little with matching up the maps.

Here is what all the effort is for BTW. This is an instrument cluster which has a number of LEDs around the rev counter; these are switched off by a CAN message from the DME. This CAN message is only sent from the latest version of program file in the DME. I have found the map which I will start a new topic about! The switch off points are controlled by that map and are loosely based on oil temperature and water temperature and some fairy dust!

The car drives fine by the way; over 300 miles; everything works. I am just want to clear up that KFMIRL issue so I can sleep easy!


http://www.reeve.org.uk/NetMoto/G7533632.0DA
http://www.reeve.org.uk/NetMoto/G7533624.0DA
http://www.reeve.org.uk/NetMoto/G7529055.0DA
http://www.reeve.org.uk/NetMoto/E39_4.4i_7539055.Bin
http://www.reeve.org.uk/NetMoto/X5_4.4i_7532623.Bin
http://www.reeve.org.uk/NetMoto/X5_4.6i_7532632.Bin
« Last Edit: April 05, 2013, 01:24:07 AM by wreeve » Logged
IamwhoIam
Hero Member
*****

Karma: +52/-115
Offline Offline

Posts: 1070


« Reply #17 on: April 05, 2013, 03:40:45 PM »

Did you read the part where I said the KFMIRL that looked weird to you was selected as the wrong size, by you?
Logged

I have no logs because I have a boost gauge (makes things easier)
wreeve
Newbie
*

Karma: +1/-0
Offline Offline

Posts: 23


« Reply #18 on: April 06, 2013, 02:54:58 AM »

Hi Ian, I didn't quite understand where you were coming from is your idea just an observation from the graph? I can see a 13 x 16 looks much better and fits the data but I understood that the KFMIRL and KFMIOP should be the same size for ME7.x? Can I ask why you think it’s a 13 x 16 map please?
For ease of discussion I will refer to the OLD tune and the NEW tune to distinguish between the old version of firmware data area and the new version. This is more technically correct as both versions are used across different vehicles with the same engine.
All the maps I have found in the OLD tune so far can be found in the NEW tune with the same values; apart from KFMIRL.
Some questions (thinking out loud here; also questions to me and everyone!):
13 x 16 does look fine but the rpm axis only goes to 4520 (unless hopefully I have the axis data located incorrectly?); the rpm axis data is 16 wide and goes to 6200.00 as in the older firmware. Again if I have the axis incorrect then that explains it.
Why does the map size change between OLD and NEW versions of the same engine when the other maps stay the same?
What is the strange data which looks like a map just after a 13 x 16 map; a 3 x 16 area? I've extended it a little here:


This is the OLD data


This is the NEW data

I’ve not seen this pattern after other maps. And it matches exactly the end of the KFMIRL data in the OLD tune. The data circled in blue is only found in this IRL map on the OLD tune. This same data is found in the NEW tune but is for some reason shifted; or not used if the map is 13 x 16…if so why is this data found in the NEW tune at all? It is only found at this location.
The green circled data is the “next” map. This starts after the 0x0010 entry. This map is the FPWDKAPP-Throttle curve dep. of the accelerator pedal map. This map is identical in size shape and location (i.e. after the KFMIRL map) between the OLD and NEW tunes. So it’s the data before the green box we are interested in.
Some interesting observations which I have circled (duplicated entries) in red. The blue arrow is the suggested 13 x 16 map end. What is interesting is the yellow ringed area. One can very nearly cut a 13 x 16 area out of the OLD tune and it becomes the beginning of the NEW tune (or indeed the whole new map if we assume 13 x 16).
Ian you don’t happen to have the .ols for this firmware do you?

« Last Edit: April 06, 2013, 03:04:12 AM by wreeve » Logged
Axis
Full Member
***

Karma: +4/-4
Offline Offline

Posts: 91


« Reply #19 on: April 06, 2013, 04:09:04 AM »

Why don't you take a look in old E39 file @ 2E9c and you will find axis lengths of 0x10 and 0x10 = 16x16
You might also notice that y-axis start @ 0x2ea0 and x-axis follows @ 0x2ec0.
Values start @ 0x2ee0.

In new file x5 you should look @ 0x2efc and you will find axis lengths of 0x0d and 0x10 = 13x16
y-axis follows at @0x2f00
x-axis follows @ 0x2f1a
Values start @ 0x2f3a

Where did your problems start? What got you to believe that you could copy the map like you did?

listen to IamwhoIam when he gives you a solution!

btw. please edit OP and update with the solution that map size differed between the two ecus.
« Last Edit: April 06, 2013, 04:15:11 AM by Axis » Logged
wreeve
Newbie
*

Karma: +1/-0
Offline Offline

Posts: 23


« Reply #20 on: April 06, 2013, 04:49:23 AM »

Thanks Axis; I didn’t realise that is how the axis are laid out with the dimensions and values in front of the data area. This makes more sense now and ties into my work in the good old days of M1.5 tuning (amazingly the page is still up for nostalgia http://www.carlton24v.co.uk/m15.htm).
I have been working with an .ols file from an even different version ME7.2 firmware. So map identification has been via a search between these! I was also searching for axis definitions; hence why I had got the initial rpm axis pointing at the incorrect data.
What does make sense is the 360,440 and 520 rpm columns of the old 16 x 16 map are identical; as is the first column of the now correctly known as 760rpm! So the system can easily interpolate down for the low rpms!
Thanks guys for the help in this. This info Axis will hopefully help me understand the “new” maps which control the oil temperature calculation. I can also go back and check all the axis info is correct in my tuner pro definition for other maps.
What I don’t understand is the blue area highlighted above; is that just junk data; it seems like it should be IRL data as its only occurrence is in the previous versions 16x16 IRL map! That was really confusing me; why is that data in the new files?
Thanks also to IamwhoIam, I was listening just didn't understand without more detail :-)
« Last Edit: April 06, 2013, 04:52:46 AM by wreeve » Logged
wreeve
Newbie
*

Karma: +1/-0
Offline Offline

Posts: 23


« Reply #21 on: April 06, 2013, 05:11:31 AM »

I am confused a little now.

I have defined KFMIOP as:
The 16 x 16 KFMIOP map starts at 0x2CBC and has axis definitions at 0x2EBE and 0x5722 ? I also can not see a 00 10 00 10 indicating a 16 x 16 map before the data? The same for the KFZWx maps.
Is there an old fashioned table index is the new ME system? I was led to believe there wasn't?
Logged
Axis
Full Member
***

Karma: +4/-4
Offline Offline

Posts: 91


« Reply #22 on: April 06, 2013, 06:19:03 AM »

Axis does not always have lenght prefix. And axis are not always together with map data. Sometimes you need to check in IDA to find axis and/or length.
Logged
wreeve
Newbie
*

Karma: +1/-0
Offline Offline

Posts: 23


« Reply #23 on: April 06, 2013, 07:11:56 AM »

Thanks.

Concur. Disassembly is the only 100% sure method; but the cost of IDA rules it out. Araxis Merge and Hex Workshop has used up my software budget!

This project has done what it set out to do. Have a well running tune of the firmware which sends the Oil Temp info to the cluster correctly. I'm sill not sure why the data at the end of the new IRL map area appears junk before the next map starts.

Results are that by comparison between the new 4.4i X5 tune and the old 4.4i E39 tunes the maps are all the same apart from the KFMIRL which is now a 13 x 16 map; reason probably being low rpm values not needed and were all the same for the original tune anyway!

« Last Edit: April 06, 2013, 07:26:39 AM by wreeve » Logged
IamwhoIam
Hero Member
*****

Karma: +52/-115
Offline Offline

Posts: 1070



You like to blah-blah don't you? I told you from the beginning your map had the wrong size and that's why it looked weird to you. Sometimes it's good to open your eyes and to look a little before the maps, not just the values in them in hex. If you have tuned M1.5 you should know about axis signatures and so on...
Logged

I have no logs because I have a boost gauge (makes things easier)
wreeve
Newbie
*

Karma: +1/-0
Offline Offline

Posts: 23



Thanks IanwhoIam. I am from a science background; like explanations and if you had just said look before the maps I could have verified  Smiley M1.5 was easier as you get the axis with each map! Again working with raw data; never disassembled. I admire people who have the time to.

Can you explain the data circled in blue or red? I still find that data strange.
« Last Edit: April 07, 2013, 01:04:18 AM by wreeve » Logged
e39bmw
Newbie
*

Karma: +0/-0
Offline Offline

Posts: 9



I have had same problem with KFMIRL map before. The solution was to re size the definition map in Winols and that fixed the problem. I dont remember the exact size, but it was something like 14x16 or something close to that.

Now, so as an update, did you end up actually getting the can bus temperature  to work on 6speed manual software or only auto?
Logged
supra94tt
Newbie
*

Karma: +0/-3
Offline Offline

Posts: 11



Any updates?
Logged
Pages: 1 [2]
  Print  
 
Jump to:  

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