hello Thaniel,

i can try to help translate from the middle of the week

 

i can try to help translate from the middle of the week

Super. I've added a file to the google drive with a list of items to try and translate. Some may not make sense out of context. If you could have a look sometime that would be great.

Good work. Sucks that there isn't much info on MS42 despite the fact it is 17 year old system

Thanks. Yes It would be nice to see more.

Thaniel

 

Good work. Sucks that there isn't much info on MS42 despite the fact it is 17 year old system

 

Do you have the matching full dump from that MS42? I would like to add some of my things to that XDF and clean up the ones that are not needed.

 

Short answer is I don't have a full dump.

Long answer. I built the XDF from a A2L so the .bin file I've been using for data isn't matched. A person on another forum looked at my .bin and said the file I have isn't a full dump. More for me to learn on that front. I'm trying to verify that the xdf is correct but having difficulty without any know valid data points.

With that said I'm looking at the A2L in another program to try and validate. It allowed me to include the S19 file too. Attached is a screen shot of one of the maps using the S19 file and the A2L. My .bin won't load though. Says it has an error.

If you know of a valid full .bin let me know. I'll look into what it takes to get the full .bin. I've read conflicting information.

So much to know and so many variables. I go back and forth 10x a day with "I can do this" to "forget this I'm buying a standalone"

Thaniel

 

I guess it could be of any kind of help:

http://forum.e46fanatics.com/showpost.php?p=15699734&postcount=439

 

Results of todays work. I upgraded the MS43.A2L file from ASAP2 V1.2 to V1.6. It is apears the english translations must have been hand entered as some values were changed but not in all the places causing a diconnect. I corrected that. if wondering, most of the needed formatting changes I do in .xls so I can do in bulk then save it as an A2L file.

The MS42 and MS43 A2L files will now load. I've been using the ASAP2Demo program and I'm starting to like it. I may eventually make/remake the XDF for tunerpro but I'm not in a hurry at this point. I found how to load ECU dumps into ASAP2Demo and can view the values, curves and maps now.

The trick to loading the ECU dumps into ASAP2DEMO is that they MUST be in "Intel HEX, Motorola S, INCA DCM, CDFX and MATLAB (.m) file formats". Yes I resorted to reading the instructions "Intel Hex" isn't the .hex file that most things seem to be saved in. I convereted several files I found on the net and my partial ECU dump (using PA soft) into the Motorola S format and Voila. (used .s28 as .s19 didn't work for some reason) They load right in now and it's easy to compare between the files.

Not sure if everything is 100% right on yet. Need to find a way to validate the data.

All the files I mentioned are posted on my google drive (link in first post) if you'd like to have a look



Thank you for the link. I had read that earlier but could not remember where it was. The MS42 A2L I used is from that post I could not remember how to get the MS43 to open so I downloaded it from another source. But it looks to be the same.

Thaniel

 

I´ll have a look at Asap2Demo at the weekend.

 

Hello another update. In looking over the data it appears that the ECU dumps I'm looking at are in LSB first (MSB last) format despite the A2L stating Big Eddian. I read somewhere that depending on how the data is extracted from the ECU it could be either LSB First or MSB first. At the moment I'm extracting the data using a PA soft clone and the data is most definately LSB first. I've posted 2 versions of the A2L on the google drive. BUt atleast use the MSB_LAST version with PA Soft downloads. I have a different cable on order and will try some other downloads to compare.

On single byte data points byte order makes no difference. Only on data points that require 2 bytes or greater. Easiest way I've found to tell if the data is good or not is to look at the Disa map "tab_disa_tl__n_disa__lm" One axis is in RPM which is a Word length. In the attached picture the one on the left (MSB in this case) is obviously wrong. The RPM jumps around instead of flowing steady in one direction. And RPM's of 24,000 aren't valid. The one on the right shows RPM's in range and in a steady increasing.

Today I'm downloading Bin's from my cars. That will give me some data that is all downloaded in the same fashion to compare with each other. My current download seems to fit the A2L quite well. Will see if the other MS42 downloads fit the same.

Thaniel

 

you would have to then fix your end result and make the XDF work only on part read, 32kb. Because you can't burn full flash into MS42 anyway.

 

Downloaded the bins. That took forever. And even with a 10 amp charger on while downloading, at least one of the cars wouldn't restart after the download finished. What in the world is the stupid car doing when the key is on. I download the bin from my spare ECU in the house on a less than 2 amp power supply that's running other things at the same time. Anyway....

I now have three bins from 323i's and a 328i that were downloaded all in the same way (and a 330i bin but that's a MS43). Should be able to make good comparisions. After comparing for good or bad ,the only one that really fits the A2L data is the 328i. The others appear to be similar to each other but the data seems to be offset or something. The header data appears to be in the same places but the map data is shifted or something. I spent some time trying to sort it out but didn't get far. Then I realized my whole point of all this is to learn to tune a car for a turbo project. If I can use the 328i ECU then perhaps I have what I need.

In looking at the data and starting on making a MS43 xdf I noticed some errors in the MS42 XDF. Reworked it this morning. Latest version on the google drive (link in post 1).

Improvements are:
TunerPro doesn't seem to handle scientific notation in the formulas. Modified formulas to all use standard notation. Reworked the scaler output type from integer to floating point so it will show the decimal places. Fixed an error in the values that required longs (had mistakenly set them to Byte). Moved the axis points to visibility level 10 and curves to visiblity level 5. (Set the visibility settings to show up to 1 and it'll hide the curves and axis point tables). Added 2 tables to pull out "ECU-no" and "build" from the .bin. maybe should have called them ECU version and type or something. Still need to make some adjustments on the map display units and add some better descriptions. It's a work in process.




Glad to hear I don't have to flash the whole thing as it takes so long. Limiting the .XDF down doesn't look like a problem. I just need to know what area to limit it to.

Thaniel

 

partial read starts at 48000 and ends at 4FFF0

 

Hello All,

Sorry for being away so long. Went away for a bit of vacation. No cell phone service or internet and no computer. Was a nice holiday though sometimes I found myself wishing I could work on ECU maps.

I did spend a little time on it since I've been home. In comparing my three 323i hex dumps they all are are very similar. But they are all very different from the 328. Digging in a bit more much of the data is similar but in different locations. I started with the axis points and was able to match up new addresses for all the axis points. Though there were some additional axis points in the 323i and a couple that the 328 had that aren't in the 323i.

Matching the maps might be more difficult. The axis points were all preceded with a byte or word (depending on if the data was a byte or word) stating the length of the following data. So i broke it all up in excel and easily matched. But the maps do not appear to start with an identifier. Think I read some other BMW ECU's do but guess I'm not that lucky. It may be more manual to match the map data up.



Looking over the hex dumps I have and comparing to the XDF data it appears that 99% all of the addresss referenced by the XDF is in that range.

The exceptions are the following 37 (out of a total of 2875)

DES_VERSIONC0D
DES_VERSIONC1D
DES_VERSIONC2D
DES_VERSIONC3D
DES_VERSIONC4D
DES_VERSIONC5D
ebw_as
nwsoll_as_a
nwsoll_as_e
sz_as
tallfs_erg_as
talsh_as_nkat1
talsh_as_nkat2
talsh_as_vkat1
talsh_as_vkat2
tate_as
zw_as_0
zw_as_1
zw_as_2
zw_as_3
zw_as_4
zw_as_5
n_proz_el_as
ti_as_0
ti_as_1
ti_as_2
ti_as_3
ti_as_4
ti_as_5
tab_zw_ad_0__n__lm
tab_zw_ad_1__n__lm
tab_zw_ad_2__n__lm
tab_zw_ad_3__n__lm
tab_zw_ad_4__n__lm
tab_zw_ad_5__n__lm
tab_tah_ad_van_e_sam__tmag
tab_tah_ad_van_a_sam__tmag

 

Added an MS43 xdf to my google drive.

 

Updated and corrected the MS42 XDF. (version 5 is the latest). Creating the last XDF helped me understand how things translated to TunerPro from the A2L things better.

 

Created a MS42_323i .xdf and A2L. The 328i Bin I have matches the A2L file, that is found on the internet, well. The three 323i's I have however do not. But the 323i's all seem similar to each other even though differing years. In comparing the 2 bins the data is very similar but it is stored in different addresses as there is the number of maps, curves etc. are different. I'd say about 60% of the maps and curve values were identical between the 328 and 323. This allowed me to realitively easily find the addresses in the 323i bin. With those matches some of the differing data is also aligned. There are some areas where the maps were not the same. Those could use some extra tweaking. But took the big wide cut and got a huge amount of what appears to be good data aligned. I'm particuarly pleased with these XDF's and A2L's as I want to "tune" a 323i.

Oh. I also purchased another 323i DME to have something to playwith without fear of bricking my driving cars.

Thaniel

 

the MS42 XDF is all in alphabetical order and because of that its all a mess. Should be going down based on address location and not on description order. The MS43 XDF looks better but in constants when the value is 00 it displays nothing in the screen it is blank. I have to change it to 'hex digit' to display. All single or dual byte constants should be set to 'hex digits'

Some translation from English MS43 damos file:

c_ = constant
dmtl= fuel tank diagnostic pump
hdmtl = heater of fuel tank pressure monitoring pump
cru main sw = cruise main switch or cruise control unit
conf ecf = configure the electrical condenser fan
conf cf = configure electrical fan for radiator
conf bts = configure brake test switch or brake switch version
conf tq lim gear= configure torq limit per each gear

others are more obvious like:
mas= misfire
crk= crankshaft
mas= air mass meter
lam= lambda
dtc= diagnostic trouble codes
mil= malfunction indicating lamp
plaus= plausibility
imob= immobilizer or ews system
tps= throttle position sensor
chk= check
st= status
vdmtl= voltage of diagnostic fuel tank pressure pump
poti= potentiometer

etc..................

if you can unput this automaticly, this would make it a killer XDF, changing all of the names manualy would take some time. Let me know, then we can work together

 

if you can unput this automaticly, this would make it a killer XDF, changing all of the names manualy would take some time. Let me know, then we can work together

Yah I can do it in bulk with "vlookups" in .xls reasonably easy. I don't make my changes to the xdf in tunerpro. I would be happy to work together on it.

I still don't see the benefit of putting the map names in address order. Does BMW put them in a particular order? i wasn't following it and couldn't find a thing. When i look at things by address I use other tools which actually list the address, name and some attributes in the list and can sort by name or address or type or..... Id like to see that feature added to tunerpro.

Thaniel

 

Got my Galletto chord the other day. I gave it a try and in only a few min it downloaded a 32kb file. Pulling into the XDF was no problem. In the header of the xdf just set "base offset (Hex)" to 48000 and check Subtract. Like in the attached screen shot.

Thaniel

 

Oh forgot to add. I took the full download and in a hex editor copied out the section from 48000 to 4FFFF then compared it to the partial dump (from the same DME) and they were 100% exactly the same. Perhaps everyone already knew that. But to me this is good news as either full or partial can be looked at easily.

 

can you make the XDF to work with partial 32kb only? That would be great.

 

Hello Everyone....Is anyone besides Haken reading this stuff??? if no one else has input Haken and I can just work through e-mail

I have been matching the 323i bin to the 328 bin. In doing so I look at any maps that aren't identical and determine what's going on. On some the actual table size is different. Say 16 bytes vs 32 bytes. But is it because the x axis is shrunk or the y axis is shrunk or both? In the axis point data there is a byte that tells the length of each particular axis point set. Which I had used to match up the axis points. In taking that data and combining with the map sizes I could tell which axis needed to be shrunk. After doing this and looking at the maps to check my work I noticed a the data that seemed to be filling incorrectly. Looked like it should be filling "ROW" wise but was doing Column wise. A simple click in tuner pro to check how it'd look. Yes it looked much better Row wise. I check the A2L and it clearly states column. Strange. I try a few more maps. Rectangular maps show this issue dramatically (say a 2x10) where in a square map (6x6) it only essentially switches the axis. But after more looking it is most definately ROW wise. Which like MSB first or Last is in direct contrast to the A2L. Is this perhaps some miss information added to the A2L's do trip us up. Or is it a result of using a different data reader than what the A2L's were designed for? Probably the latter. But either way I'm guessing this descrepancy applies to more than just this A2L. Eveyone likes visuals so here it is.

Graph on the left is with Column wise as specified in A2L. Graph on right is Row wise.

And another just for example.

Seems to me the winner is ROW wise. I've already bulk changed one of my XDF's and one A2L. Want to do a bit more checking and I'll post on my drive. But I have some landscaping work to attend to this morning.

In other news I've mapped out practically where every byte from the A2L is in the "partial read". Thought I'd give a go on looking for the Immo off feature that is mentioned by some. Honestly I don't need it as I'm not swaping engines but It would be convient to be able to swap in my spare ECU's. AND....this is the most interesting part. It seems like the white whale of ECU tuning. I love puzzles and challenges so it drew me in. If it is in the partial read I've narrowed it to probably a dozen possible bytes. But not sure how to proceed from there. Trial and error? I've probably spent too much time on this as it doesn't help me with my original project of turbo charging my car. But it was educational. I'll post up some detail of my findings later. Will take a bit to make them coherent.

Speaking of my original project. I also bought a checksum corrector program (was $16 USD). It appears to work but I've not done any flashes yet. I have maps and values, and flashing tool and checksum corrector. The realization hit me. Looks like I'm about ready to start trying to modify the ECU parameters.

Next steps....
-Finish tweaking the XDF's and A2L's based on new knowlege.
-Translate the abreviated and german titles or comments into something I can understand.
-Look at eng-ine logging so I can tell what the changes do to the engine
-Add turbo charger :bow:
-Break engine :facepalm:
-Rebuild engine
-repeat last 2 steps until bored :loco:

If anyone has any input let me know.


Yes, It does work with the 32Kb. Just make the adjustments in the XDF header as shown above.

 

I´m still reading all your posts but acutally you are much beyond me I ´ll have to digg into that stuff later, as i´m really busy the next weeks.

keep up the awesome work and don´t forget MS43 :thumbsup:

 

I looked over the Data a bit more and concluded that Row wise for all items appears to be correct. I'll Rebuild the XDF with it row wise. I'd have it done but I was trying to resort it by Address

Thaniel




Thanks for the comment. I went ahead and looked at the MS43 and found the same thing. I'll post in the MS43 thread.

I have been playing with my ms42 since i will be using it in my Ti. Im translating it but its taking a while. I have the conf switches and the big maps. Also ISN location. Hit me up. Btw look into the correction factor on the damos....... It will tell you all the good stuff.

Thanks I'll drop you a note

 

I have been playing with my ms42 since i will be using it in my Ti. Im translating it but its taking a while. I have the conf switches and the big maps. Also ISN location. Hit me up. Btw look into the correction factor on the damos....... It will tell you all the good stuff.


Sent from BimmerApp mobile app

 

:bow:

Stunning work. And by all means hack the checksum too if you can.. This world has really been waiting for this stuff to be free and available to all.

 

Updated XDF and A2L posted. I found the original A2L is not sorted in Address order. Did sort the XDF by address within the values, axis, curves, maps. The way my XDF .xls builder sheet is structured they are on separate tabs and sorting the MAPS and curves together is not convenient.



Thanks.

Personally I'm not going after the checksum as I have no idea how to incorporate that into TunerPro (not sure I'll even use TunerPro as I'm liking ASAP2Demo and it is free as well). I'm not a checksum expert (barely know what they are). But from what I read the MS42 is one of the simplest algorithms to reverse engineer. For now the $16 program for me is good enough. I need to move on to making changes to the ECU.

Thaniel

 

Nice work Thaniel

For checksum correction you cold have Used Winols. Have you taken a look at the project file i sent you?

Also hi jony787. Díd the MS42 project file tune help you?

Nice to see the hard work to make this tuning knowledge available to everyone.


Regards

Mark


Sent from BimmerApp mobile app

 

Nice work Thaniel

For checksum correction you cold have Used Winols. Have you taken a look at the project file i sent you?

Thanks,

Yah probably could have made Winols do the checksums. Don't have a good handle on Winols at the moment.

I did take a look at the project file. It helps me a bit to understand how Winols Works. Also I was able to use the english descriptions to help with the decoding some of the german abreviated titles. However there are only 34 maps identified and labled in the Winols project and 249 maps in the A2L :yikes: And then there are all the curves and values. But the definitions you've provided unlocked a few popular abreviations that I hand not figured out (ZW for instance). I haven't gotten to comparing the actual map values or anything yet.

Oh and the offsets in the 328i map you have is different from the 328i map I have. I guess there is a software variation? I expect that means the A2L values will need to be remapped (like I'm doing for the 323i) to read that file complete.

Speaking of translations does anyone know what these stand for?
Zyka
EPZ
KR
FAK
There are tons more but those seem to be abreviations used often. The descriptions with the translations provided and others I've grabbed from other sources are making the descriptions more and more usable. Soon i'll make an XDF with the attempted translated values.

Learning more all the time.

Thaniel

 

I'm reading as well, but I don't have any useful input. I'd love to see this working on an MS43. If anyone needs some favors from a mechanical design standpoint, I'd be happy to exchange favors.

 

Thanks for commenting. It inspires me to continue working if I think others might use the results.

KR should be klopfen regler = knock control

FAK should be = factor

Added these to the translation tables. Also picked through some other sources that had some abreviation definitions. The titles are starting to make more sense. Some are probably wrong and there are some things that still need translated but we can fix them as we go? Guess I need to see how big the field limits are for titles and descriptions.

I'd post the list of new titles but with axis points and all its 2875 lines long. But it's on the google drive if anyone want's to look and provide input.

FYI
Here's a link to a project I did for a year or so. Decoding the E46 can bus messages. http://forums.bimmerforums.com/forum/showthread.php?1887229-E46-Can-bus-project

In truth I've yet to implement any of the can bus information on my own project cars (but have helped others to implement). It was interesting and fun to do even if I never use the information. I feel the same about this A2L decoding XDF creation. I'm learning things and having fun. My satisfaction is increating something useful. If others help it goes faster but I'll keep poking at it. That's what hobbies are about. (yes I know my idea of fun is odd)

Thaniel

And I'm starting to wonder if my can bus knowlege can be used for data collecting to see how well a tune is working. using the OBDII monitoring packets are comparatively really slow. Just not sure how much engine data is passed over can bus (Throttle position, RPM, Engine temp are). Will have to look at that later.

 

KR should be klopfen regler = knock control

FAK should be = factor

Were is Daniel_f der Deutches Jude when we need him? All he does is just milks someone else's hard work, you can't blame him he is a jude

 

Hi all, i have just started reading into all this stuff and have a KWP2000 on the way. I would love to help in anyway but a lot of the stuff your saying is flying over my head.


Subscribed and look forward to your progress!

 

on a side note i have a spare DME from a 318ci, any chance you can give me tips on how i hook it up to the KWP bench style? less chance of bricking my daily driver i have a fair range of tools and a little experience with pcbs etc.

 

Very interested in this as well, but like has been said, I likely can't be a ton of help. You know more than I.

 

Well, you probably could be even more help you could imagine

Its just up to you guys to make a list of things you would like to be able to tune :thumbup:

With the discovery of the function description, MS42 is much easier to handle from now.

As stated, its just up to you guys


(edit) VIN is positioned at 0x3C4A (13x1)

 

I don´t know if its up to anyones interested currently, but the Flashcounter at MS42 starts at 0x3C4A and its 46 bytes for each flash. :hi:

e.g.

32 44 163 89 24 16 8 1 7 4 0 96 134 0 21 226 0 114 113 56 3 74 0 21 209 4 0 114 113 55 0 48 48 48 48 48 0 0 36 0 0 0 0 173 1 0

Where the first 13 bytes are the VIN