DME Tuning - TUNERPRO

Originally Posted by TerraPhantm

You've succeeded in using winkfp to flash a custom tune? What'd you do, convert the binary to intel hex and tell winkfp to ignore checksums? Or do you know how to calculate the checksums?

Im sure HakenTT used winols to calculate the checksums.

I truly question whether or not he actually did it. Guy makes one post in here about having tuning experience but doesn't give any specifics. Then he claims success again without any specifics other than the brief mention of a software program. This is the same person who made an entire thread based on a short paragraph or two about how his E46 isn't fun to drive... on a fanatics website. Things just don't add up correctly.

If he's going to leave the community and actually made it work then why doesn't he make a cliffnotes about how he overcame the common obstacles?

Originally Posted by sunnyjay

Im sure HakenTT used winols to calculate the checksums.

Well I'm talking about different checksums. I'm sure winOLS can calculate the ones the DME cares about. I'm referring to the ones winkfp looks at. At the end of all the winkfp data files, there's a checksum that it presumably uses to verify that the tune is from BMW. It's not in the actual binary. Since most tuning shops wouldn't be using winkfp to flash, I don't see why winOLS would have that ability

Originally Posted by TerraPhantm

:100000006335363636353038343330303636303185
:1000100031313134333030303636303130303030C9
:1000200031313134333030303636303130303030B9
:1000300031313134333030303636303130303030A9
:1000400063613433303036362E444154FFFFFFFFB6
:10005000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB0
:10006000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA0
:10007000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF90
:10008000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF80
:10009000FFFF000000000000000000000000000062
:1000A000000080808080808080FFE001FF7F3E0034
:1000B00011002E0073002E0019003200F401F4012B
:1000C0001B090000800164220C00FD2C28000800A0
:1000D00000FF000048010000CD0CCD0C00180018F6
:1000E0002001CD0006014200CD0C3D0A0020FFFF9B
:1000F000270133F34801370A8901CB010C0267E677
:100100000100010058199A19900139007B009A19D1
:100110009A09000000000080FE7F000014000A0021
:1001200020033804581B0300C40F4E00C8003C00D5
:10013000140014001400140011001100110011002B
:1001400029222822282228227105710571057105AE
:1001500044034403440340036903690369036503DB
:1001600091209020311531158920882025152515DD
:1001700010161016101610162084200420042004D7
:10018000308430043004300421042104210421048B

In each line the colon and the 8 characters after that identify the offset. I'm not sure what the last 2 digits in each line represents, but it's not code. Seems to be some kind of checksum for each line.

Each of those lines and the end byte is an XOR checksum calculation.

Flashed a custom tune with winkfp? really? don't think so ?!

HakenTT - please tell us something... :o

Don't expect anything out of him. HakenTT is notoriously disliked on pretty much every other BMW forum.

he could prove me wrong, of course - I'd be happy if he did. But don't hold your breath..

come on guys, don´t let this fell asleep

i have a spare dme, programmer, time, money and dumps to test

all i need is some smart guy who´s able to unlimit my 330 from 225 to its original topspeed of 245

And you didn't ask me? Come on Daniel!

Hello. I am new to this forum and this will be my first post.
Regarding the topic, flashing modified sp-daten file to the dme with winkfp.
I doubt this is possible with success. I have looked alot to this possibility in the last months. I have even been in contact with EVC in Germany regarding this since I already have a fully licensed WinOLS. It is correct that WinOLS recognise these files, but the problem are the checksum calculation. I have several checksums plug-ins in my WinOLS, and when I open a file which I have the correct chk.sum plug-in to, it recognise the file, but says that the chk.sum are incorrect and want to correct it even though it obviously are correct. The winkfp program can be configurated to not test the checksum, and I assume it will actually make the programming, but as I say, I doubt it will be success in make the engine start. I know that WinOLS have plug-ins for correcting checksum in update-files from manufacturer to Jaguar/Ford/Volvo, and such plug-in could be nice to have also for BMW. See link from EVC. http://www.evc.de/en/product/ols/import.asp

Originally Posted by FritzP

Hello. I am new to this forum and this will be my first post.
Regarding the topic, flashing modified sp-daten file to the dme with winkfp.
I doubt this is possible with success. I have looked alot to this possibility in the last months. I have even been in contact with EVC in Germany regarding this since I already have a fully licensed WinOLS. It is correct that WinOLS recognise these files, but the problem are the checksum calculation. I have several checksums plug-ins in my WinOLS, and when I open a file which I have the correct chk.sum plug-in to, it recognise the file, but says that the chk.sum are incorrect and want to correct it even though it obviously are correct. The winkfp program can be configurated to not test the checksum, and I assume it will actually make the programming, but as I say, I doubt it will be success in make the engine start. I know that WinOLS have plug-ins for correcting checksum in update-files from manufacturer to Jaguar/Ford/Volvo, and such plug-in could be nice to have also for BMW. See link from EVC. http://www.evc.de/en/product/ols/import.asp

That's good to know!

Which checksum are you saying there will be issues with? The WINKFP files last two values are a checksum WINKFP uses within itself. Did you remove this and take those into consideration? Basically run the checksum file against the finished .bin lets say for a 5k rpm rev limit to test. Then convert to Hex16 and apply a XOR calculation at the end?

Originally Posted by hybridNz

Each of those lines and the end byte is an XOR checksum calculation.

Going back to your WINOLS exporter/importer link. If I am reading it right it is an import that can take .0da parse them in correctly and export them correctly for plug and play flashing through WINKFP (BMW lingo example)?

It would be neat to make it work. For now a GALLETO tool WINOLS, and checksum file is all that's needed. Along with knowing the address locations. I think at this point it would be best to start identifying the correct address space for things like euro 2 emmissions etc etc so it can be ported across the e46 range.

Originally Posted by hybridNz

Each of those lines and the end byte is an XOR checksum calculation.

Yeah I realized that much later on. The whole thing is actually just in the "Intel Hex" format... though there are a couple non-standard headers found towards the end of the file IIRC. Still, after realizing that, it was trivial to just convert these into straight binaries.

Originally Posted by FritzP

Hello. I am new to this forum and this will be my first post.
Regarding the topic, flashing modified sp-daten file to the dme with winkfp.
I doubt this is possible with success. I have looked alot to this possibility in the last months. I have even been in contact with EVC in Germany regarding this since I already have a fully licensed WinOLS. It is correct that WinOLS recognise these files, but the problem are the checksum calculation. I have several checksums plug-ins in my WinOLS, and when I open a file which I have the correct chk.sum plug-in to, it recognise the file, but says that the chk.sum are incorrect and want to correct it even though it obviously are correct. The winkfp program can be configurated to not test the checksum, and I assume it will actually make the programming, but as I say, I doubt it will be success in make the engine start. I know that WinOLS have plug-ins for correcting checksum in update-files from manufacturer to Jaguar/Ford/Volvo, and such plug-in could be nice to have also for BMW. See link from EVC. http://www.evc.de/en/product/ols/import.asp

Have you tried flashing a tune with WinKFP, dumping the binary from the DME, and then comparing? If WinKFP "changes" the checksum during the flashing process, we should see it then. Otherwise I would hazard that WinOLS isn't parsing the ihex format properly (perhaps the non standard bit at the end confuses it). Converting to binary beforehand and then loading it may be sufficient. I cannot really test any further since I don't have a licensed copy of WinOLS

The link I posted to evc is for a plug-in for WinOLS to be able to open update-files for Ford/Jaguar and Volvo and can not be used for the 0da files for BMW.
But, however the 0da files for updating/programming with winkfp opens fine in WinOLS and you will find the same structure as if you make a readout with a common tuningtool like Galletto. I have not been working alot with petrol ecu's for BMW, but I have some experience with tuning BMW diesels. I have used the 0da files in winOLS alot for comparing different engine powerlevels, and I have also maked good tuningfiles for ex. Bosch EDC16. But to state it right, for the actual tuning I make a readout and flashing with my BDM100. I always work with the original file for the ecu to avoid problems with EWS for example.
The XOR checksum calc. mentioned here, I am not familiar with that. I have to gain some more info about this. I have checksum plug-in in my WinOLS, and the chk.sum are corrected aotomaticly every time I make an altering of a map.

Originally Posted by TerraPhantm

Yeah I realized that much later on. The whole thing is actually just in the "Intel Hex" format... though there are a couple non-standard headers found towards the end of the file IIRC. Still, after realizing that, it was trivial to just convert these into straight binaries.




Have you tried flashing a tune with WinKFP, dumping the binary from the DME, and then comparing? If WinKFP "changes" the checksum during the flashing process, we should see it then. Otherwise I would hazard that WinOLS isn't parsing the ihex format properly (perhaps the non standard bit at the end confuses it). Converting to binary beforehand and then loading it may be sufficient. I cannot really test any further since I don't have a licensed copy of WinOLS

I have not tried to alter 0da files for then flashing it with winkfp, but it could be interesting to try.
I have tried to export a 0da file without altering, but if I then make a comparing with a hex-viewer the file are not identical as the original file. It looks like winols are doing something when it imports the file.
If I then import the already exported file from winols, it looks the same in winols like the original imported file, based on that I think winols are changing something when it imports.
You mentioned converting 0da file from hex to bin, that could maybe be a solution before import to winols. What tool/program are you using for such convertion, it also have to be converted back to hex after export from winols.
It could be interesting to try this, I have used winkfp for flashing update files in the past, so I am familiar with the process.

Originally Posted by FritzP

I have not tried to alter 0da files for then flashing it with winkfp, but it could be interesting to try.
I have tried to export a 0da file without altering, but if I then make a comparing with a hex-viewer the file are not identical as the original file. It looks like winols are doing something when it imports the file.
If I then import the already exported file from winols, it looks the same in winols like the original imported file, based on that I think winols are changing something when it imports.
You mentioned converting 0da file from hex to bin, that could maybe be a solution before import to winols. What tool/program are you using for such convertion, it also have to be converted back to hex after export from winols.
It could be interesting to try this, I have used winkfp for flashing update files in the past, so I am familiar with the process.

I used something called hex2bin - seems to work fine on most MS43 files. Just have to pad it to the right size (missing data seems to just be filler). Haven't tried it with any of the DDEs.

With the MS45, it seems to spit out mostly junk. And the MSS54 seems to confuse it a little bit since the MSS54 has two processors

Not terribly difficult to write an application that can decode the intel hex to binary. These are the rules: http://en.wikipedia.org/wiki/Intel_HEX - But BMW doesn't seem to follow the rules perfectly. I've come across a number of instances of a record type "10" which isn't defined.

I am now looking at a 0da file opened in winols, and you are right, the two bits at the end of each line are missing, and ofcourse, when exporting, these 2 bits will not be there. I am away at work, and I dont bring my tuningcomputer where I have the licensed winols so I just use the demoversion now.

Those 2 bits of each line in the 0da file, so this is a checksum for that particular line? What about the chksum in the end of the file, is that a chksum for the entire file? If so, how can these chksums be calculated after an altering in the 0da file.

Originally Posted by FritzP

Those 2 bits of each line in the 0da file, so this is a checksum for that particular line? What about the chksum in the end of the file, is that a chksum for the entire file?

The 2 bits at the end are checksums for each line, yes

I am not sure about the checksum at the end. I assume it's for the whole file, but i haven't investigated it. Or it's perhaps more likely to be for the file without the comments

OK, I found a calculator where I tried to make a calculation for each line, but it doesn't seems to get the right chksum for this line..
Calculator: http://www.hhhh.org/wiml/proj/nmeaxor.html

Originally Posted by new//M3fan

You are correct. Euro 3 keeps cat monitoring on and sap off. I passed emissions with that tune.

Euro2 deletes all emissions and you can set the idle mixture manually through dis.

To me it looks like MS43 partial read 64kb, has the "boot ID string" at the start of the file, like 0000 hex to 000B hex. I suspect that this is used for booting versions of components like, CAN detection, climate control version, exhaust version, fuel system version, idle control version, knock adaptation version, emission version, ews version...

And it looks like one hex byte determines if that option is used or not, for example 30 to 36 hex is components is booted, and 60 to 66 means components is not booted.

I just speculate on this, because I compared many different versions of MS43 software.

Hello,

I have a e46 330xi.

I want to write out the version 430055.

What "ZBNumber" I need?

430037 = 7510535
430066 = 7545566
430055 =??

I need this version because of the 430055 can assign the maps.

Thanks in advance

nice greeting