M3.3.1 motronic (413 and 506) tuning and XDF update?

Hairyscreech · Post by **Hairyscreech** » Wed Jun 28, 2017 4:02 am

I have a bit of an odd set up with a M3.3.1 ECU running an M20B25 with the vanos disabled in the .bin (resistor replacing the solenoid to avoid fault codes) it's running and driving so I am now starting to get into the meat of the tuning.

I have been looking at the ECU and software for about 2 years now on and off while doing the conversion and car resto.

I have attempted to disassemble the binary file, I think I managed a reasonable disassembly but getting any useful info from that is currently a bit beyond me, maybe a discussion for another thread?

I have a fairly good understanding of the hardware and tuning side so I am not totally lost but there are a few things puzzling me:

1. It seems people are not adjusting the "transitional compensation" in anyway on these ECUs, standard wisdom for standalone systems is to get the VE tables right with any acceleration enrichment off and then add it after.
I understand that a lot of people are working with quite mild engine changes so maybe it is not needed for those. In my case I certainly need to work on it.
Do I minimise it in the 4x6 table so it is not messing up my part throttle tuning?
Would it be better to work with what I have, reduce the transitional fuelling to hit ~12:1 on acceleration and then tune the part throttle aiming for ~14.7-15.7 at cruise? looking at about 10:1 accelerating and 13:1 cruise at the moment on the slightly adjusted M50 map.

2. The new 506 XDF is really good, a huge thanks to evilM3666 for this.
I think from all the studying of this ECU I have done there are a few things that can be added:
- TPS voltage transfer map (32x1) - Based on the transition compensation map being 0.4 volts to 6 volts and the functional range of the TPS being .45v open and 4.5v closed, this table seems to be a map of throttle opening vs voltage.
Could the scale (Y axis) on this map be 6-0.4= 0.175 steps?
This would give the right volt values to match the throttle openings.
Charted in tunerpro it looks like this:

To me that seems to match the operation of the TPS but I am going to double check with the ADS diagnostic system VS the map trace on the ostrich.
Does that seem right?

Hairyscreech · Post by **Hairyscreech** » Mon Jul 17, 2017 4:08 am

Done some more on this, the TPS table does seem to be voltage, ADS scanner says that the throttle is shut at about 0.3v and fully open about 4.2v.
Ostrich does not trace that map when the TPS is opened though so no real way of confirming the result.

Had to plug in the standard Lambda sensor and leave it in free air or the ECU wanted to go to limp or jump around erratically, with the lamba flag unset and the closed/open loop tables in the new 506 XDF set to 0 it is staying in open loop and tracing smoothly.

I think I may be having trouble with one of my knock sensors, I also don't know if the M20 valve train is going to set off the sensors just from it's natural clatter.
Can anyone advise how to disable the knock sensing?
Does anyone know how the ECU responds when the sensors are disconnected or erroring?

The car is running fairly well (for an unmapped car) on the stock M50B25 map.
I have had to adjust the acceleration enrichment quite a bit to prevent it going very rich at low load (10:1)

Idle fuel wanted about 10% pulling out to get a happy idle at 14.3-15:1, very solid, lean idle on these for an old engine.

I have also had to decrease the fuel at low load by about 10% and up the fuel at high RPM and load by 10% to see sensible AFR readings. Before doing this I was getting 12:1 at cruise and 15-16:1 at higher RPMs.
This seems odd to me as the fuel table should be a Dec value of 128 for the theoretical 14.7:1 AFR right?
So for the sensed load and RPM 128 should=14.7 if all sensor readings and conditions are normal.
Can the M20 really be needing me to drop the cruise values to ~116 and up the high RPM and load values to ~140?
The stock M50 map is around 125-135 across the whole map?

For ignition timing I have some electronic Det cans which I can record on the laptop while hit tracing and viewing the WBO2 output.
I have been trying to get it to knock but these engines seem so knock resistant I did not want to push past 45 degrees of timing at low load so I have not been able to get it to knock. They seem to just stop making any power instead of knocking.

Others have said to keep the timing below about 32 degrees as they only make noise and no power past this point (95 ron UK fuel).

I put together a base timing map using the data from the 173 timing maps I have (stock, light tune and race tune) they do feel retarded and seem pretty safe to drive on but I think the engine and ECU are wanting more timing at a lot of sites as some areas really bog down.
Looking at the M50B32 and M50B25 maps says I am still retarded at a lot of load sites and suggests more timing could be tolerated.
Just got to keep working at that side of things.

I will post my current BIN later

olafu · Post by **olafu** » Mon Oct 09, 2017 2:46 pm

There are rpm dependent 32x1 knock threshold (or nominal engine noise) curves for every cylinder. In total 8 curves, but 2 of them are not in use. They starts from 0xE550 in 506/965BIN and all curves are in a row without any descriptors. I did 32x6 XDF Table for that, must set to "Column" in "Major Order"-setting and you get one column for each cylinder. RPM scale are from 1000 to about 6200rpm. If you want to trace, make one 32x1 XDF table for one cylinder. Tracing will not work with 32x6 table.

Setting bigger values will reduce knock detecting sensitivity. There are much more "knock stuff" in near, like 0xE51C 10x1 - i think it is amount of knock retard curve. When value is 0 there are no knock correction to ignition angle.
I think there are also load dependent threshold curve for knock control activation, but i didn't found it yet.

I did tests only by running ECU out of a car, with simulated signals. Be careful when trying these with a car.

olafu · Post by **olafu** » Wed Oct 11, 2017 10:41 am

More knock stuff found. Here is XDF for testing, use at your own risk.
https://www.dropbox.com/s/cfylzxjtg09r2 ... 3.xdf?dl=0 No checksums or anything else. Tested with 413/623 with simulated input signals. Use +12(dec) offset to 506/965.

EDIT:better version. Old version deleted. https://www.dropbox.com/s/7uj39x9h2581f ... 3.xdf?dl=0

olafu · Post by **olafu** » Fri Oct 13, 2017 8:42 am

And more knock stuff again. 0xE4F2 10x1 table: Knock window size in crank degrees. x*2.855.?

And 0xE4B8 10x2 D0xD5 - Knock window start timing. TDC is about 26(dec)..?

Hairyscreech · Post by **Hairyscreech** » Sat Oct 14, 2017 5:26 am

Thanks, helpful.

I have just been playing with this and I think the 32 value knock tables are actually a 16x2 map.

I was looking at them as possibly 16 bit values but digging through my excel master sheet of the code there is a D5 2 value axis below the D0 16 value axis. Wedged between the knock control and the D0 axis values.

D5 02 0E A6 in Hex

D5 2 14 166 in Dec

D5 2 76 90 in motronic counting. (256-first value, then first value-second value).

D5 would suggest load right?
If so that suggests the knock table has one curve for low load and one for high load.
76 and 90 for load values splits the normal load axis dead down the center, the PT ignition table would be cut dead down the center line with boxes on the first curve and 6 boxes on the second curve.

I will play some more and host my excel file, I am trying to get all known information on the 413 and 506 into one document with the maps highlighted and the code documented as much as is possible at this time.
Long term goal is to blow this ECU wide open as it really feels like the one to use for low buck BMW builds.
It also crosses the 8bit/16bit time line, a lot of the code comes from the older 8 bit ECUs with more modern 16bit areas, it has a lot in common with the VW vr6 and 1.8t ECU. It might open up a lot more info on some of the other ECUs.

Edit - and you are right about there being 8 tables, this ECU was first used as the M3.3 on the V8, the M3.3.1 is the 6 cylinder version, I expect that is legacy code from the V8.

Hairyscreech · Post by **Hairyscreech** » Sat Oct 14, 2017 5:44 am

Ok, here is the working document so far.

If you spot any mistakes then let me know where so I can check and update.

http://www.filedropper.com/413and506map ... s-17-10-14

olafu · Post by **olafu** » Sat Oct 14, 2017 8:51 am

Right, that clears why that axis data was 16 and tables 32. Thanks!

EDIT: Yes, thats right, they are actually 16x2 D0xD5. Now they looks more logical.

EDIT2: Experimentally i tried to run 413 DME with BIN from 404 DME, it runs, and when i checked ignition drivers with scopemeter, there was control pulses also in place of two missing ignition transistors.

Evil · Post by **Evil** » Sat Oct 14, 2017 10:53 am

O2 flag is D00A on the 413 and D00B on the 506, it should be the same on both? So wich one is the the good one?

Are the "lambda off" tables confirmed to work for disabling lambda regulation?
I did a try on my 403 with a 6x6 table RPM/load , with all values to 0 Lambda and adaptatives seems to be disabled...

Hairyscreech · Post by **Hairyscreech** » Sat Oct 14, 2017 11:31 am

Just been out in the car, I can 100% confirm that zeroing the 4 lambda off tables and unsetting the flag puts it in permanent open loop. I have been running like that for about 3 months with very consistent results. (14.7-15.2 at cruise where I set the fueling to, no changes regardless of conditions etc.)

The 506 lambda flag works, not 100% cast iron sure about the 413 one, it has been reported as being in a totally different location to the 506 before but also reported that people could not turn off the lambda properly with that location (so I am working on the theory it is bollocks).
The one on the excel sheet is what I have from checking and comparing the code.
Also just noticed I might have marked the wrong cell, could be a mistake, will check but it should be the same location on 506 and 413 as there are no differences in the data block upto that point.

Setting the "knock control on load" 0xE508 to FF made the car a dog, full retard once it was warm and nearly undrivable, lots of heat in the exhaust as well so I think that made it pull timing all the time.
Setting it to 00 turned it off, car is much better so the ECU is thinking the M20 tappets are knock.

Edit - we may as well use this thread as to compile the data we have onto that document, not being used for much else.

I will try to answer any questions ASAP as I am keen to get more info together.

The boxes marked in yellow are the active maps from the measurements of the 413 ecu in the other thread, I will try to do a confirmation of the active maps on the 506 tomorrow after I get back from mountain biking.
I can see from the known maps that the 413 measurement was taken with the ECU at low load as the advanced vanos tables did not activate. Maybe there is some more data we can find from the activation results at various conditions.

olafu · Post by **olafu** » Sat Oct 14, 2017 11:44 am

Setting load threshold to 255 will reduce advance for some reason. Try 254, by setting it 0 knock control is always on...
I was finding a flag from D000-> to disable knock control but haven't luck.

Evil wrote:O2 flag is D00A on the 413 and D00B on the 506, it should be the same on both? So wich one is the the good one?

Are the "lambda off" tables confirmed to work for disabling lambda regulation?
I did a try on my 403 with a 6x6 table RPM/load , with all values to 0 Lambda and adaptatives seems to be disabled...

In 413/623 0xD00B BIT2 is Lambda closed loop flag. But it turns also charcoal canister control off, and it's output stage goes continuously "ON" so remember to unplug it. In case of flag is set to "0" there is no fault code when charcoal solenoid is unplugged.

Hairyscreech · Post by **Hairyscreech** » Sat Oct 14, 2017 11:57 am

olafu wrote:Setting load threshold to 255 will reduce advance for some reason. Try 254, by setting it 0 it is always on...

That's how I expected it to behave, observed behavior is 255 = terrible, 0 = drove ok. I will test again tomorrow as the car is too loud to go out again for a test now. I am sure you are correct as you can bench test, 0 felt like off but maybe 0xFE is the ticket instead and 0xFF cause a fault. It was bad from the start with 0xFF.
0x00 did feel ok so maybe it was just placebo from it being so flat/bad?

Evil · Post by **Evil** » Sat Oct 14, 2017 12:38 pm

Thanks To both of you for your answers, and of course for your work, I follow this thread with many attention.

Hairyscreech · Post by **Hairyscreech** » Sat Oct 14, 2017 12:43 pm

Right, more updates then.

Did not know about the charcoal canister, as my system is installed on an E30 M20 I have one plugged in but just hanging out in the engine bay with no vacuum tubes, on or off would make no odds to me but would if it was connected.
I have added this note to the excel document.

I did highlight the wrong cell on the 413 binary tab for the lambda flag, corrected this now.

Added a note about not setting the knock on load table to 0xFF.

Will make a few more updates and reupload tomorrow.

Another edit - Just had to move the car so set the knock load to 0xC8 (200) which I believe translates to a load value of 10, vast improvement in higher load power so certainly in my case the knock circuit is working and probably against me. The car is on a very safe base map so knock retard would make it very retarded.
I was getting issues with the car bogging down at higher throttle but playing with the knock on point changes that. I could really do with a way to measure or record the actual timing while driving, not just the requested timing, but that may be easier said than done.

olafu · Post by **olafu** » Sat Oct 14, 2017 9:32 pm

https://www.dropbox.com/s/7uj39x9h2581f ... 3.xdf?dl=0 <- new. still, for experimental use and at your own risk. Not tested in a car by myself.

Hairyscreech · Post by **Hairyscreech** » Tue Oct 17, 2017 10:49 am

I will convert it over to the 506 XDF and have a play later in the week.

Just trying to get the updated xlsx sorted, the table of tables is not filled out correctly for the 413 yet, it was copied over from the 506 page and so the map names are not in the right places as I only adjusted the locations.

Will try to get that done in the next couple of days.

Oh and had a thought about the reason FF caused full retard, possibly an issue of the ECU seeing FF as equivalent to no data, I need to check the spec sheet and see how the microprocessor deals with FF but I notice there are no cases of FF in any mapped areas. Is FF the same as NOP on these?
Edit - Intel manual says FF is the opcode for reset on these microcontrollers?

olafu · Post by **olafu** » Fri Oct 20, 2017 10:10 pm

Hairyscreech wrote:Edit - Intel manual says FF is the opcode for reset on these microcontrollers?

I don't know about programming, but, in my opinion it's good to fill any "undefined" data areas with "FF" because if CPU program counter ever points opcodes from data tables or blank memory area, it's fatal error (e.g. from external electric interference) and reset can put CPU back to the right lane. Correct me if i'm wrong. In that case, using FF as load limit, buffer overflow or something can be reason for ecu acts like that.

Hairyscreech · Post by **Hairyscreech** » Sun Oct 22, 2017 8:19 am

Your right, any undefined space needs to be filed or the file size will not be correct and obviously everything would be in the wrong place as there would be nothing taking up the free space.

Its just a question of how the ECU treats an FF value, possible it just disregards it, which is why FF needs to be avoided at all costs in a map.

FF as an opcode implied returning to the start of the program so it is not reading them as an opcode, the data block must be treated differently.
I have a ton of programming info for these microprocessors (Intel 80196) from when I was trying to sort out a disassembly.
You noted in the other thread that the active maps seem to align with the IDA output, I would be curious to see what you have in terms of an IDA output. Every time I have run it I found that it all falls apart when the code seems to start doing "st" and "lb" from the zero register.
I don't quite get what the issue is there as I am not enough of a programmer to know. To the best of my knowledge the zero register should be hard wired to only show 0x00 in all zero register locations. Simply by making the transistors for the zero register dead and only report an off state.
Which leaves the problem of why would the code read and write to an effectively dead register. (unless this chip has that register active to screw up reverse engineering but then they would be killing their own guaranteed 0 point?).

Anyway, I have been plugging away on that file, wanted to upload a new version earlier this week but I have been up against it with work.

I added a change log to keep track of corrections (several), fixed a lot of things and added some stuff.

Two biggest things are I have added several notes in red/yellow that look significant to making further progress it might be worth trying to answer those as a higher priority before looking at the many other questions.

The second is I have also been trying to work out the factor and offset for the D7 coolant temp axis, I took a vid of the hit traces just after starting the car yesterday, I will upload the vid as well.
I am working on the assumption those traces show a coolant temp of around 20-35 degrees as it was cold and the car was only running for a few seconds.
My current suspicion is that it might be something like X*0.75-40 but I cannot be sure yet.
It would be a big help to find as we can put some axis to the unknown tables, most of which are D7 or XX*D7.

Link is here for the update: http://www.filedropper.com/413and506map ... s-17-10-22
And here for the video: http://www.filedropper.com/untitled64

olafu · Post by **olafu** » Mon Oct 23, 2017 10:47 am

Hairyscreech wrote:Your right, any undefined space needs to be filed or the file size will not be correct and obviously everything would be in the wrong place as there would be nothing taking up the free space.

Its just a question of how the ECU treats an FF value, possible it just disregards it, which is why FF needs to be avoided at all costs in a map.

I can be wrong, but: File size remains same, there is no matter if it is full of "FF" or "00" in every bytes. Hardware doesn't care if it is 00 or FF, or something between them, if they are part of "data tables". Program counter will never jump to read opcodes from that area.
But because software is using that data in calculations, it matters. It depends from a program, what happens, if two address contents are e.g. summed or multiplied with each other, and result is oversized for it's space. It can "leak" to wrong place and in best case that leads to reset or something other visible problems. Worst is hidden problems (in e.g. timing..

)

Hairyscreech wrote:You noted in the other thread that the active maps seem to align with the IDA output, I would be curious to see what you have in terms of an IDA output. Every time I have run it I found that it all falls apart when the code seems to start doing "st" and "lb" from the zero register.

IDA did "program tree"and showed start points of every subroutines. I traced those subroutines start points in BIN and saw was they running or not. If there was nothing "buzz" in start address, there was also nothing in about middle of that "subroutine". But i don't do anything with that information, because i don't understand code.

olafu · Post by **olafu** » Mon Oct 23, 2017 11:53 am

https://www.dropbox.com/s/2ilbupogqs7he ... s.xdf?dl=0

Some DTC triggering/limp stuff and Idle/PL/FL thresholds for 506/965 BIN. Mined from 413/623 bin and offset corrected to 506/965 . Need to be test in a car. Let me know if there is something wrong. Testing at your own risk, of course

I didn't found RPM axis for Idle/Part load/Full load tables yet. Those rpm.s are checked only with a scan tool...

Area between D22A-D28D is full of many fault codes triggering data.

Hairyscreech · Post by **Hairyscreech** » Mon Oct 23, 2017 12:32 pm

olafu wrote:
Hairyscreech wrote:Your right, any undefined space needs to be filed or the file size will not be correct and obviously everything would be in the wrong place as there would be nothing taking up the free space.

Its just a question of how the ECU treats an FF value, possible it just disregards it, which is why FF needs to be avoided at all costs in a map.
I can be wrong, but: File size remains same, there is no matter if it is full of "FF" or "00" in every bytes. Hardware doesn't care if it is 00 or FF, or something between them, if they are part of "data tables". Program counter will never jump to read opcodes from that area.
But because software is using that data in calculations, it matters. It depends from a program, what happens, if two address contents are e.g. summed or multiplied with each other, and result is oversized for it's space. It can "leak" to wrong place and in best case that leads to reset or something other visible problems. Worst is hidden problems (in e.g. timing.. )

Hairyscreech wrote:You noted in the other thread that the active maps seem to align with the IDA output, I would be curious to see what you have in terms of an IDA output. Every time I have run it I found that it all falls apart when the code seems to start doing "st" and "lb" from the zero register.
IDA did "program tree"and showed start points of every subroutines. I traced those subroutines start points in BIN and saw was they running or not. If there was nothing "buzz" in start address, there was also nothing in about middle of that "subroutine". But i don't do anything with that information, because i don't understand code.

Re the 00 or FF thing, yeah, totally.
File size would be the same but it could treat it differently.
It's possible depending on what it does with the data that it is forcing things over to a negative value

I found a note in one of the programming guides for this Micro-controller saying FF should be used to fill blank space as if it ever gets read it will trigger a reset for error recovery reasons.
Obviously in the middle of a table this is bad news.
"In addition the hardware reset instruction (RST) can cause a reset if the program counter goes out of bounds. This instruction has an opcode of 0FFH, so if the processor ever reads in bus lines that are pulled high it will reset itself."
"It is recommended that unused areas in the code be filled with NOP's and periodic jumps to an error routine or RST instructions."
"This is particularly important in the code surrounding lookup tables, since if lookup tables are executed then undesired results will occur".

^^Quoted direct from the manuals.

I see what you did with IDA, I think I have a reasonable disassembly going on and I found a couple of interesting things earlier today which I will have a pick at.
Those self references in the code are damn important, I have found them referenced further up in the code. I don't know what to make of them yet but I guess I would not be here if I already knew!

I will try to check out those triggers later this week.

I am going to push my M20 maps over to the 413 code base so we are all working off the same sheet will save the cross referencing and speed things up a bit.
In terms of running the car it will make no difference really.

Edit - Also the guy having problems with the Alpina ECU sent me his BIN over and I am going to take a look see if I can help out with the EWS on it, all the usual stuff is in there but the table of tables is moved around to the top of the map section. All still referenced with that short section of human readable hex at the bottom of the file though.
If I find anything I will feed it back into this project.

olafu · Post by **olafu** » Mon Oct 23, 2017 1:17 pm

Scalar names was crossed between "high" and "low" in TPS DTC trigger. Uploaded new XDF to dropbox.

Mykk · Post by **Mykk** » Tue Oct 24, 2017 1:12 pm

Thank you for figuring thsee things out. I've adapted most over to use in my 404xdf. Thanks!

Hairyscreech · Post by **Hairyscreech** » Tue Oct 24, 2017 11:10 pm

I was going to pick up your 404 file and add it to the excel document. As it is an 8 cylinder file and nearly identical hard ware I was hoping from some code examination that we could pick up where things like the cylinder angle offset, number of cylinders, firing order, injector sequencing etc is stored.

IIRC the V8 has a few additional features like ASC control etc as well.

99% of what we find in these 6 cylinder ECUs should apply to the V8.

olafu · Post by **olafu** » Thu Oct 26, 2017 8:58 am

I will check those injection timing tables (which are known as "vanos dwell tables" in 623 XDF in site

) at next. My test bench is based by looping crank sensor sound file played from computer soundcard in different speeds, but cam signal is bluffed by hooking a cam sensor signal wire to injector output. But i need to do an additional circuit board to modify individual pulses to square wave, because sound card can't push clear square as output. Second choice is using some multi purpose I/O board as signal converter, but that looping sample feels better... Real time gapless speed controlled WAV or MP3 or whatever sound file playback software please here. Now i'm using Audacity, but its not good for this.

Hairyscreech · Post by **Hairyscreech** » Thu Oct 26, 2017 9:13 am

For such a simple steup it's certainly provided some good data.

Are you not finding that you have every DTC code under the sun stored in the memory?

I have found a few more things so I am adding them to the excel file at the moment. Also discovered how to make a little text popup appear when you click a cell, so I have put a lot of the single bit notes into those to tidy things up.

So you think what was marked as vanos dwell is actually injection timing related?

I have been trying to get further with disassembling the code in IDA but cant seem to get anywhere. The disassembly feels incomplete and there are no references to the data section that I can make sense of at the moment.
I know/am sure they are using a offset+value to address the maps (extended addressing?) but I just can't find anything that seems to work or make sense in that application. There also seems to be several times that the code writes data to the same locations repeatedly, which seems self defeating as three writes to the same location in a row would just leave you with the last value written. The first two writes would be a waste of time.

olafu · Post by **olafu** » Thu Oct 26, 2017 9:36 am

Hairyscreech wrote:For such a simple steup it's certainly provided some good data.

Are you not finding that you have every DTC code under the sun stored in the memory?

I have found a few more things so I am adding them to the excel file at the moment. Also discovered how to make a little text popup appear when you click a cell, so I have put a lot of the single bit notes into those to tidy things up.

So you think what was marked as vanos dwell is actually injection timing related?

I have been trying to get further with disassembling the code in IDA but cant seem to get anywhere. The disassembly feels incomplete and there are no references to the data section that I can make sense of at the moment.
I know/am sure they are using a offset+value to address the maps (extended addressing?) but I just can't find anything that seems to work or make sense in that application. There also seems to be several times that the code writes data to the same locations repeatedly, which seems self defeating as three writes to the same location in a row would just leave you with the last value written. The first two writes would be a waste of time.

I've got 506/965 XDF from evilm3666 (very much thanks!), and those tables are marked as injection timing tables in it. It sounds and looks logical, because target to inject fuel is just next to intake valve is closed. By modifying data in those tables i can change injection timing, but because it's moving my "cam sensor signal" it is complicated

I think i can edit dwell tables and ignition timing tables to produce "cam signal" but it's better to do separate cam signal. Cam sensor fault code appears at immediatelly from wrong timing and ecu jumps to batch firing strategy. Knock control and many other features will switch off.
If i was understood right, it is better to use offset addressing instructions because they are more efficient than direct addressing. (like those "zero registers"- it sounds complicated, but in some cases it can be much powerful to point zero register vs. direct data) But again, i'm not a programmer, so that can be bullshit.

Mykk · Post by **Mykk** » Thu Oct 26, 2017 4:36 pm

Hairyscreech wrote:...Are you not finding that you have every DTC code under the sun stored in the memory?...

I too support finding all of / or the majority of DTC's in the code

Hairyscreech · Post by **Hairyscreech** » Thu Oct 26, 2017 11:47 pm

olafu wrote:
Hairyscreech wrote:For such a simple steup it's certainly provided some good data.

Are you not finding that you have every DTC code under the sun stored in the memory?

I have found a few more things so I am adding them to the excel file at the moment. Also discovered how to make a little text popup appear when you click a cell, so I have put a lot of the single bit notes into those to tidy things up.

So you think what was marked as vanos dwell is actually injection timing related?

I have been trying to get further with disassembling the code in IDA but cant seem to get anywhere. The disassembly feels incomplete and there are no references to the data section that I can make sense of at the moment.
I know/am sure they are using a offset+value to address the maps (extended addressing?) but I just can't find anything that seems to work or make sense in that application. There also seems to be several times that the code writes data to the same locations repeatedly, which seems self defeating as three writes to the same location in a row would just leave you with the last value written. The first two writes would be a waste of time.
I've got 506/965 XDF from evilm3666 (very much thanks!), and those tables are marked as injection timing tables in it. It sounds and looks logical, because target to inject fuel is just next to intake valve is closed. By modifying data in those tables i can change injection timing, but because it's moving my "cam sensor signal" it is complicated I think i can edit dwell tables and ignition timing tables to produce "cam signal" but it's better to do separate cam signal. Cam sensor fault code appears at immediatelly from wrong timing and ecu jumps to batch firing strategy. Knock control and many other features will switch off.
If i was understood right, it is better to use offset addressing instructions because they are more efficient than direct addressing. (like those "zero registers"- it sounds complicated, but in some cases it can be much powerful to point zero register vs. direct data) But again, i'm not a programmer, so that can be bullshit.

I'm no programmer myself either, at this point only someone willing to learn. Trouble is this is low level old school programming, a specialist job at the best of times and proving a little difficult to find anyone that can work at such a low level to advise. Thanks to the new research job I have taken I might be able to hassle the computer science department and get someone to help.
Your right, using the offset+value method is more efficient as you could set the start of the data as your offset and have all the addresses fore example ST INTMEM_24 D000 64h to address the bit value 100 after the start of the data (0xD100).
Means if your working on the code at quite a low level then its easier to debug and follow.
Whats grinding my gears is I cannot find these offsets.

You have a fair point about the injection timing. It is worth bearing in mind that the injection will switch to batch over a certain speed, simply due to time needed for injection.
The main point of the sequential injection is a smoother idle and lower emissions at low speed/low airflows. High air flows whip the fuel back into suspension if it sits in the port but at low speeds there's not enough airflow to do that, hence trying to inject close to IVO.
Curious to know how those tables are setup, I will try to take a look today and see if they pass plausibility as injection timing, I would think it more likely than them being vanos solenoid dwell times as that thing is on or off, nothing really to need a dwell time.

I see the problem you have with the cam signal. Would it be worth trying to hijack a megasquirt mega stim?
I thought about this a couple of times before, they are cheap and i believe programmable to match most of the signals the ECU would need.
My electronics is just not good enough at this point to build up a custom signal generator but it might just be worth putting the time/money in to make it happen.
Perhaps that's a project that needs starting, an open source ECU stimulator for reverse engineering?

olafu · Post by **olafu** » Fri Oct 27, 2017 8:09 am

Ardustim is Arduino based crank and cam trigger signal generator. I i was understood right, it can produce only square wave output. But Motronic runs also with square wave, because it's zero crossing sensitive. It's one possible way

Actually those ECU's will run with such ugly-looking crank signals. Chinese suppliers offers advanced or less advanced commercial products for ECU repairing shops. They are also equipped with o2 and knock sensor signal generators and much more. Those are available in ebay and price is less than 1000$ in some devices. If i'm doing this as my job, i would already have one. But, for me, the travel is often more important than the goal

Mykk wrote:
Hairyscreech wrote:...Are you not finding that you have every DTC code under the sun stored in the memory?...
I too support finding all of / or the majority of DTC's in the code

There is bite of fault code triggering data in that about 100 bytes area, what ends to MAF sensor voltage conversion table. In 413/623 code there is :
D267 = Supply voltage (54 from main relay) MAX (DTC 54)
D268 = Supply voltage (54 from main relay) MIN (DTC 54)

(I HAVE NOT ANYTHING WIRED TO 02 INPUT)
D271 = O2 sensor something DTC threshold?
D273 = O2 Frequency? Small values = more sensitive for O2 DTC.
D273 = 254 never get O2 DTC? in value "0" immediatelly O2 DTC.

D26B = Multiplexed output stages fault codes? (injectors, vanos, evap, relays, idle valve and whatever?)

D27B = DTC 42 (speed signal) 255 = no DTC 42?
D281 = DTC 15 (ignition "spark" current signal?) 255 = no DTC 15?
D288 = DTC 69 and 70 (knock sensors) 255 = no DTC 69 or 70?

EDIT:
40FF-4104 = IDA stuff? I can mess up ignition outputs by touching those area.

Mykk · Post by **Mykk** » Fri Oct 27, 2017 9:23 pm

Thank you olafu, I've adapted the DTC's that I could. Truly appreciate your leg work

Mykk · Post by **Mykk** » Tue Oct 31, 2017 6:16 pm

Have you guys discovered any more goodies in the code? I'm anxious in anticipation of the advancements you guys have been making

I wish I could help but you guys are figuring out bytes if data on an entirely different level then I'm capable of.

Hairyscreech · Post by **Hairyscreech** » Thu Nov 02, 2017 5:10 am

Here we go then.......

http://www.filedropper.com/413and506map ... s-17-11-02

Tons of little additions done to the sheet, I have put most of the things in the change log.

The Alpina BIN reveals a lot of interesting info. Key points:
- The code section is the same as the 413 silver label
- The table of tables is at the start of the maps not at the end
- The Maps are in the same order as the 506 and 413 silver label
- Only a few things are in the same location across all of the BINs.

This gives a few clues:
- Maps and the table of tables cannot be directly referenced as they were moved with no code changes.
- The Map section truly starts with the first map in the lookup table, by moving the table of tables they highlighted where they felt the start of the "maps section" was.
- Map order is important or they would have moved them around
- A lot more tables have been tuned than we currently have ID for, we need to look into those maps
- The EWS specific data stands out a bit now as we have EWS and non-EWS data that matches for all structures that are not related to the EWS.
- The data area is clearly broken into ~ 5 sections, We seem to have a Constants section, a DTC section, a transfer functions section, A maps section and a references section after the end of the check sum.
- The references section may be more important than it looks as it is always in exactly the same location across all the various BINs.
- Injector constant is not an injector constant at all. I does scale the injector pulses but not for the reasons we think, the 413, 506 and alpina all use the same constant with different injectors. (they do have identical MAF sensors though, is this figure actually a MAF constant?)
- The Alpina seems to turn on or off a host of trouble codes in the DTC section, maybe this will help puzzle out some more of those?

Mykk - While you may not be able to find things like we can it would be a huge help simply for someone to test things on a car and report back, even checking for errors, spelling mistakes and updates in the excel sheet would be awesome.
Some things are going to be hard for us to check and my M3.3.1 ECU is wired up onto an E30 M20 engine and I am not sure Olafu has a running car to test with at the moment?
We might see different behaviour than a running car sees.

Olafu - Would love a proper programmable signal generator, bit out of the budget at the moment though but I am tempted to see what I can get my hands on now I work in a Uni.

The trouble codes do have a frequency of occurrence associated with them, INPA reports the frequency when you scan the car.

I expect the DTC codes are going to have a format like the maps do, Something like 3 bytes giving the max trigger point, min trigger point, frequency.

For the 02 sensor - I have one fitted but just tied up to the side of the engine never to be used, if I get some time I will do horrible things to it and let you know how the codes trigger.

DTC 15 - You have this as "(ignition "spark" current signal?)" is this the one often reported as a knock sensor issue?
If so it is actually a secondary ignition circuit monitoring code.
The ECU has the secondary ignition coils wired back to one of the ECU earths via a big shunt resistor (240ohm) the ECU is looking for a 5v pulse on that earth for each coil firing. If it does not get the pulse then it thinks the coil has not fired or misfired and logs it. It is accurate and fast enough that the ECU uses it to find individual cylinder misfires.

It's always misreported as the info on the system is very poor on the net, I know because I had to do masses of digging to find the real issue. My E30 swap does it and I cannot get the voltage above 4.7 volts despite lots of work. I think it is due to the lower compression of the E30 no building up as large a resistance to the spark and thus less going back down the shunt.

If that is the trigger to turn that DTC code off then I will have to send you some local Cider!

Hairyscreech · Post by **Hairyscreech** » Thu Nov 02, 2017 5:17 am

Oh and I forgot one thing, I (badly) translated and added a M3.82 DAMOS for a VW/Audi 1.8t to the excel file.

This ECU used the same processor as the one we are working with. I would expect a lot of the programming to be similar, I have been wondering if it will give us some hints as to what might be lurking in the code or help us put correct names to functions that we currently do not understand.

Mykk · Post by **Mykk** » Thu Nov 02, 2017 4:35 pm

Impressive amount of work has gone into your spreadsheet.

While tearing apart my M3.3 404 code I've come up with axis descriptors:

D0 & CE = Engine RPM
D7 = Water Temperature
D3 & D4 = Intake Air Temp
D5 = Load
D6 & CC = Throttle Position Sensor
D7 = Water Temperature
D8 = Voltage
1C = Vehicle Speed/KPH

Unkown's:

CB, CF, D2, D9, 1D

They seem to coincide with your M3.3.1 and fill in a few unknowns in your .xlsx

Hairyscreech · Post by **Hairyscreech** » Fri Nov 03, 2017 4:26 am

Curious how you decided CE was RPM? Is there something in the 404 BIN that gives it away as so far it has been a mystery?

I have updated the 413 XDF to have all the same info as the 506 XDF that I was using and have moved my M20 mapping over to the 413 red label BIN so we can all work/test from the same BIN.

The XDF update is here: http://www.filedropper.com/bmw413redlab ... 17-11-02_2

Edit - updated to fix checksum error 5/11/17

It has some of the parameters corrected vs the old 413 or old 506.
I added the knock control and a few notes on how to use the lambda tables and axis.

Edit - All fixed. If anyone spots any errors in the XDF then let me know or do the fix and reupload it.

I also finally made my axis calculator usable for normal humans.
It can be found here: http://www.filedropper.com/loadaxiscalculator

It was made for the M3.3.1 load axis but could be made to do other jobs.
It is a little long winded as it is intended as a teaching tool as much as a calculator. I would much rather people understood the changes they were making and why they were needed than just poke and hope.

Mykk · Post by **Mykk** » Fri Nov 03, 2017 8:06 am

While I was watching the cell hit tracing via Ostrich, the tables with CE axis seemed to only follow RPM. Looking at the header info of CE it follows the same calc as RPM (x*40, subtract from next value ). Once the axis was labeled based on header info once again the cell hit tracing followed suit and changed at appropriate rpm of the labeling.

Same with D3& D4, while watching cell hit tracing on the tables with those axis identifiers I'd go unplug IAT while the vehicle was running and tables with those identifiers cell tracing would swing to one side of the table. Plug IAT back in and it would pull from cells in middle of map, or where it was previously drawing info from.

Hairyscreech · Post by **Hairyscreech** » Sat Nov 04, 2017 8:22 am

In that case by nature CE can only be RPM based.
It slightly begs the question why have 2 RPM values?
I could be wrong but I think the CE refers to location 0xCE which is a RAM location. Same for D0, C1 etc etc.

Which again begs the question why double up on the RAM locations?

My thinking is that the two RPMs are coming from different inputs to the microprocessor, hence storing them in different locations in the RAM.
Both values are RPM but from a different source?
Maybe from different signal processors on the board?
Maybe D0 is Crank sensor RPM and maybe CE is a calculated RPM? a cam sensor calculated RPM?

I have some high res photos of the ECU boards on my laptop so I will take a look and see if there is more than one place the signals for the crank sensor and IAT sensor are processed.

Hmm.

Mykk · Post by **Mykk** » Sat Nov 04, 2017 4:14 pm

In Red 413 soft 623 do you know what is the bit of data located between D19A-D20C?

Seeing as how it's sandwiched between DTC code, I'm assuming it's more DTC code?

olafu · Post by **olafu** » Sat Nov 04, 2017 11:04 pm

I think they can be CEL blink codes. Must to check...
EDIT: They are blink codes. (pedal test - 5 times accelerator floor and CEL will blink the fault codes).
Tested:
all values 0 = only long flashes occurs between fault codes.
all values 1 = long - short - short - short - short
all values F = long, 15 short at four times
and so on.

Mykk · Post by **Mykk** » Sun Nov 05, 2017 2:46 am

That's amazing. Thank you

Mykk · Post by **Mykk** » Sun Nov 05, 2017 4:55 am

One more request? Any way to pull apart the transfer functions and thresholds between D4C8-D598?

I recognize the 32x1 TPS transfer function @ D4F8
Also the Idle - PT and PT-WOT thresholds @ D53C & D540

The rest I don't have the ability to identify.

olafu · Post by **olafu** » Sun Nov 05, 2017 6:02 am

Mykk wrote:One more request? Any way to pull apart the transfer functions and thresholds between D4C8-D598?

I recognize the 32x1 TPS transfer function @ D4F8
Also the Idle - PT and PT-WOT thresholds @ D53C & D540

The rest I don't have the ability to identify.

Did you found RPM axis for those IDLE/PT PT/WOT tables?

I noticed interesting thing in MAF signal fail safe mode:
Idle actuator position change slightly changes LOAD signal. Where is "table" for that correction? I think there must be something RPM vs. idle duty cycle dependent map or something for it.

Mykk · Post by **Mykk** » Sun Nov 05, 2017 9:24 am

olafu wrote:Did you found RPM axis for those IDLE/PT PT/WOT tables?

I noticed interesting thing in MAF signal fail safe mode:
Idle actuator position change slightly changes LOAD signal. Where is "table" for that correction? I think there must be something RPM vs. idle duty cycle dependent map or something for it.

I have not found RPM header info for the TPS switching tables. There is a table just before Idle/PT table of 5 5 7 7. I made a separate table in my xdf to watch these figures, while running and cell hit tracing with ostrich my DME never pulled info from this table. I had hopes it was deceleration fuel cut off threshold. Perhaps that 5 5 7 7 has to do with RPM header info somehow?

Since I am working with 404 DME, I have two idle airflow maps. Both 5x5 maps of D0 vs D7 one is used during idle, part throttle & WOT. The other is used for engine overrun/decel/fuel cutoff. They have similar values in them with only minor changes in the decel map.

I have a feeling in your 413 it's the tables located at EB3C and E3F0.

While I experimented on my 404 in MAF fail mode, I would get AFR's dialed in perfect with lambda turned off running with MAF. Unplug the MAF and the AFR's went so rich it pegged my AFR gauge and the vehicle would fire up but stall from too much fuel. After tweaking the tune to get AFR's lean enough to idle the vehicle would not accelerate as it would go full lean.

Hairyscreech · Post by **Hairyscreech** » Sun Nov 05, 2017 10:00 am

Working on all of this.

The stomp code area works out, all the codes are little endian 0x12xx. This matches the known format for the stomp codes so I am tagging the spread sheet with all the known codes.

If these are the outputs then I expect there is an area that is laid out in exactly the same order showing the trigger points.

Should be 57 triggers to match these 57x 16bit codes.

Also - XDF updated to fix checksum error.

Hairyscreech · Post by **Hairyscreech** » Sun Nov 05, 2017 1:11 pm

Heeeeeeeeerrrrrrrrrrrreeeeeeeessssssss update!

http://www.filedropper.com/413and506map ... s-17-11-05

Just spent the last few hours going over DTC codes and adding clickable ID tags to the spread sheet.

Think we will be able to match this order up to the triggers in the code anywhere?

There are a few codes I am not sure about, mostly the ones above 1284 as they don't seem to be systems fitted to the E36. They might be US or E34 specific, I didn't check that yet.

I also popped the 404 code into the file. I highlighted a few areas I have already spotted. In some ways it is very similar but in some places the difference is drastic.

I tried to offset the code to match the 506 BIN to see if I could work out some of the trouble codes etc but its very different.
Some bits of code seem to match but the order is all over the place.
Think I found the RPM limiter and the "injector constant" though.

I swear we need to rethink this "injector constant" thing though, on 3 cars with different injectors the constant is the same but the 404 with a different maf and it is the only time it changes.

Mykk · Post by **Mykk** » Sun Nov 05, 2017 1:18 pm

I have a theory about those DTC on/off and flash tables, but no way to test it.

The DTC's on/off table is a 57x2 table that we recognize in hex format as "0 hex =no CEL" "16 hex = CEL on". The DTC's flash table is a 56x2 table with the flash code in little endian hex format all starting with 12xx.

The first 2 cells of the" DTC's on" table do not follow the format of the rest of the table. I bet that is your DTC's checksum. Which means there are remaining 56x2 cells of DTC on/off data

Line up in Tunerpro the two 56x2 tables side by side of the "DTC's on" with the "DTC's flash" and I bet we could line up which codes match the flash codes to the On/Off table.

1211 = DME Control Unit
1215 = Air Mass/Volume Sensor
1216 = Throttle Potentiometer
1222 = Lambda Control 1
1223 = Coolant Temp. Sensor
1224 = Intake Air Temp. Sensor
1225 = Knock Sensor 1

.... and so on.

EDIT: a quick test of my theory doesn't pan out because vital error DTC's that surely trigger a CEL are marked "0" in it's companion cells in the On/Off table....unless I'm missing a cruciall piece of info

Mykk · Post by **Mykk** » Sun Nov 05, 2017 1:55 pm

HairyScreech, I don't know how in-depth you want to get with the 404 in your spreadsheet. But you are welcome to my xdf if you truly want to label the majority of the tables & functions

Hairyscreech · Post by **Hairyscreech** » Sun Nov 05, 2017 3:22 pm

I see no reason no to include the 404 BIN, after all it is from the M3.3 base version of the ECU that the M3.3.1 came from.
Personally I am not sure how much time I will get to bash at the 404 maps but some work would probably be beneficial.

If you want to type the names into the sheet and highlight the cells (maybe with the green/light green I was using) then feel free, send it over and I will put those additions into the latest version.

The M3.3 on the v8 has no vanos control so it will be interesting to break down how the ecu deals with that, the euro M3 also uses the M3.3 but adds a vanos controller to deal with the dual vanos. This suggests that the M3.3 hardware or software cannot handle the vanos.
Maybe it will show me where to pull out the vanos code from the 413/506?

Regarding the DTC area, unfortunatly the first 2 cells/values are actually the self reference that starts the section. If you look you will see those 2 values are actually the location of the first cell in little endian format.
On the M3.3.1 413/506 there are 114 cells, 57 DTC codes, the area above it is also 114 cells or 116 cells if you include the 0x06D1 reference.
The 404 BIN has 112 check code cells and 112 cells above it, again 114 if you count the self reference at the start.

I don't think that is coincidence but what is giving me pause is that the 413/506 is said to have a speed limiter value in that area.
It does not align with the check codes as car as I can see?
Do we assume that speed limiter value is rubbish?

I am going to do the same check sum calculation on the error code section as the main code and see if I can find a check sum.

Edit - Also as a little trick if you ever want to overlay the popup notes or the colour coding then all you have to do it highlight the area you want, copy it, right click the first cell of the area you want to past the formatting and select "paste special" and then "formatting", it will copy over the popups and the colours etc to anywhere you want to put them.
Handy for overlaying things.

Mykk · Post by **Mykk** » Sun Nov 05, 2017 3:45 pm

I'm not familiar how to navigate excel to add my own info, notes & colors.

I totally see now the first two cells being it's own reference address. The MAF has it too...that's really crazy to me. Obviously a DPTR is already drawing information from that address, why load the hex address of the location it's referencing....

EDIT: That self describing hex address is at the beginning of each table referenced by the end of code addresses....

there's more addresses at the end of code data that point to the microcontroller side of the code. When you visit those addresses in the first part of code you get self describing hex addresses again.

...It seems the rest of DTC data similar to whats in 2nd part of code is hiding in the first part of code. There are alot of duplicates between DTC list in 1st part of code and DTC list in 2nd part of code.