NefMoto

Have BMW made a mistake!? I can’t quite believe it. I have double checked this from a fresh flash of the whole DME using the WinKFP BMW tools and a new installation of the stock binaries.

Here is the KFMIRL map:

(http://www.reeve.org.uk/NetMoto/KFMIRL_7533623.jpg)

Here is what it looks like when I have moved those 6 entries:

(http://www.reeve.org.uk/NetMoto/KFMIRL_7533623_Fixed.jpg)

I doubt you would get to those map points on a drive which is why I haven't noticed it on the road! Presumably at very light throttles; high rpm; a lot of fuel would get dumped in?

Here is KFMIOP by the way; looks like I would expect:

(http://www.reeve.org.uk/NetMoto/KFMIOP_7533623.jpg)

Sign the Z?

If the map was infact like that, the ECU would not dump fuel. It would request alot of load.

Agreed. Looks like a sign issue.

Here is the raw hex: Just looked like they have rolled three map points. This can't be intentional can it?

(http://www.reeve.org.uk/NetMoto/KFMIRL_7533623_data.jpg)

How accurate is the definition?

I actually think the map is 13x20 instead of 16x16, you can verify the map size by looking at the byte before the axis. If we assume 760 is the first value of the rpm axis in 8bit, then the byte before is 0D, 0D x 40 =520 :)

The definition is from the same DME but a different firmware version; so the location of the maps and the axis are in different memory locations. How I found the new location of the maps was to perform a hex search of the map data from one .bin to another .bin. The maps are unique and all found only one instance. Apart from this KFZIRL map.

Here is the rpm axis; starting at 0x5722

(http://www.reeve.org.uk/NetMoto/KFMIRL_7533623_axis.jpg)

The map data is identical between the files apart from those last three columns. The map in the original firmware is a 16 x 16.
The KFZIOP map is also 16 x 16 and identical in both versions of the firmware.

If I upload the .bins and some addresses would you mind having a look? I can't believe that BMW would mess up.

My definition lists the rpm as 16bit (LoHi) and 0.25 * Eprom

Why don't you post your file here?

I take back my post. definitely not a sign issue.

would need to see bin.

Here is the full story!  It’s a long(ish) story! Car is a BMW 4.4i V8 fitted in a 5 series. The 4.6i V8 fitted to the X5 communicates oil temperature via the CAN bus. The wiring diagram is identical. Both use the same DME (ECU). The 4.6i runs the latest version of the DME firmware.
DME running old version of firmware. Data area OLD.Bin. Car ran like this for years!
I needed the latest version of firmware to get a CAN message for oil temperature transmitted. This only happens on the 4.6 litre version of the engine! However there is a 4.4 litre tune for this firmware with the CAN message disabled. That 4.4 litre tune is also for the X5.
No problem. Flash the latest version of the firmware and the data area for the 4.6 litre version and swap over the map areas from the 4.4 litre tune.
Problem: No CAN message.
Solution: Find the map/data which controls the CAN message and copy that from the 4.6 tune to the 4.4 tune.
Done. Works fine. Car drives fine. So I have the latest firmware; the 4.4i maps but tuned for the X5 and not the 5 series. Throttle response is different to the 5 series maps; presumably to compensate for the extra weight!
Problem: Curiosity got the better of me and I looked at the maps; there isn’t much difference between the 5 series and the X5 tune. All look very similar apart from KFMIRL which has that strange hump.
If anyone has time to have a look for me I would appreciate it.
Here is what I attach:
GF11286 7533623 NEW.xdf = This is the TunerPro file with locations from the new firmware.
GF11268 E39 OLD.xdf = This is the TunerPro file with locations from the old firmware.
E39 OLD.Bin = The original tune for the E39, old firmware.
X5 NEW.Bin = The tune for the X5, new firmware.
So my question: What is happening to KFMIRL in the NEW files? Is it correct or should I “correct it” to look like the OLD files?
At the moment I have “corrected” the map in NEW.Bin to look like the map from OLD.Bin.
Car runs and drives superbly. But have I messed up?

http://www.reeve.org.uk/NetMoto/E39_OLD.Bin (http://www.reeve.org.uk/NetMoto/E39_OLD.Bin)
http://www.reeve.org.uk/NetMoto/X5_NEW.Bin (http://www.reeve.org.uk/NetMoto/X5_NEW.Bin)
http://www.reeve.org.uk/NetMoto/E39_OLD.xdf (http://www.reeve.org.uk/NetMoto/E39_OLD.xdf)
http://www.reeve.org.uk/NetMoto/X5_NEW.xdf (http://www.reeve.org.uk/NetMoto/X5_NEW.xdf)

0261204620

Matches the Bosch number of your NEW file, so I assume it's what you want :)

If this one isn't suitable, Let me know what Bosch numbers would be better, I'll see if I have any of them!

I looked, KFMIRL looks normal. Nothing like what you posted.

Thanks. Just looking though some maps. The IRL at least looks 16 x 16.

But as if things weren't confused enough :-).

0261204620 is the ECU number of my old ECU. I have flashed in the software and tune from a 0 261 207 106 Bosch number. The ECU in the car is still the 0261204620 hardware but I have forced in the firmware from a 0 261 207 106. To be honest I didn't think it would work but it is running fine! The hardware differences must be very minimal.

The reason I did this was it's only the latest firmware which contains the code to transmit oil temp via CAN.

What is very interesting is that hardware number (the 0261204620) isn't in the file I flashed so the BMW flash program (WinKFP) must add it automatically; along with the VIN number.

Maybe I should buy a 106 DME from eBay and run that but I don't believe it will help the strange map identification. If you have a 106 .ols file I would love that.**


** It would also shed some light on the Oil Temperature CAN bus message map I have found; at the moment it's just a few bytes which appear to allow the oil temperature to be transmitted via CAN. I can't find these bytes in any other firmware version.

Just out of interest, if you walk into a dealer and buy a DME you get a 0 261 207 106 so I know it runs all the engines! But they cost about £400! More than the car is worth!

I don't think it's possible to read the entire flash memory without desoldering the chip. I assume the Bosch number is stored in the part not readable. I'll see if I have 106!

Are you 100% sure that the X5 file is original? It contains resized maps, such as kfkhfm or kfpu resized to 2x2 but retaining all the other values the same as the E39 file? Sounds like a bad joke to me. KFMIRL in the X5 file is 13x16 by the way, not 16x16 like the E39.

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 :)

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:

(http://www.reeve.org.uk/NetMoto/WinKFP.jpg)

“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/PC180977.JPG)
http://www.reeve.org.uk/NetMoto/G7533632.0DA (http://www.reeve.org.uk/NetMoto/G7533632.0DA)
http://www.reeve.org.uk/NetMoto/G7533624.0DA (http://www.reeve.org.uk/NetMoto/G7533624.0DA)
http://www.reeve.org.uk/NetMoto/G7529055.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/E39_4.4i_7539055.Bin)
http://www.reeve.org.uk/NetMoto/X5_4.4i_7532623.Bin (http://www.reeve.org.uk/NetMoto/X5_4.4i_7532623.Bin)
http://www.reeve.org.uk/NetMoto/X5_4.6i_7532632.Bin (http://www.reeve.org.uk/NetMoto/X5_4.6i_7532632.Bin)

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

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:

(http://www.reeve.org.uk/NetMoto/Oldarea.jpg)
This is the OLD data

(http://www.reeve.org.uk/NetMoto/Newarea.jpg)
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?

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.

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 :-)

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?

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.

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!

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...

Thanks IanwhoIam. I am from a science background; like explanations and if you had just said look before the maps I could have verified  :) 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.

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?

Any updates?