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

Discuss Bosch (Porsche, BMW, Volvo, etc) tuning topics here. Request definitions, discuss parameters, etc.

Moderators: robertisaar, dex

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech » Sun Nov 05, 2017 4:57 pm

Just solved it by aligning my popup notes.

The first lot are the DTC codes. That 0xC9 10 is nothing to do with the speed limiter, it is as suggested INPA code 201, lambda.

See the list here and compare them to the numbers before the 0x00 or 0x10.
0 or 10 must be if it is active or maybe if it throws a check light.

http://realitypod.com/2012/06/08/bmw-co ... -and-more/

M3.3 is half way down the page.

Mykk
Posts: 99
Joined: Sat Sep 05, 2015 8:28 am

Post by Mykk » Sun Nov 05, 2017 5:41 pm

Nice find, really helpful. I think these tables are simply just for the human interaction of CEL and code flashing. By setting any one code to "0" doesn't tell DME to ignore the problem, it just tells DME to not let us know about it.

olafu
Posts: 141
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Post by olafu » Mon Nov 06, 2017 7:39 am

Mykk wrote: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..
I don't exactly know what ECU does with those own reference addresses. I think it never reads them, because it seems that ecu will work fine with anything written in those first two bytes..?!

Data section can be divided roughly to five parts:
- First one is for control bits, constants and scalars
- Second is fault codes, what ecu is storing in to SRAM for scanner, CEL triggering and CEL blink codes, and end of DTC part is for DTC trigger/thresholds for some DTC's.
- Third part is for transfer tables and other data strings without specific header data
- 4th is for 2D and 3D data tables with header data, these are linked from an index table
- 5th is index table for tables (4th).

All those parts are pointed from that data string at end of BIN.

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech » Mon Nov 06, 2017 9:48 am

All the sections start with those self references and your right I don't think they are for the ECU to identify the sections.

The copy of the DTC tables further up in the code gave me a hint so I did some more digging today.

That section at the bottom has 5 addresses in a human readable format. Under that are what seem like 5 more adresses but only the first two make sense:

D002 D106 D28E E67E E7B2
42EC 43F0 1A08 1E08 D002

The first is clearly the control bits, this is copied into the code completely and is visible in the code section.
The second is the fault codes, again copied into the code and visible.
The last is the end of the data section and the end of the code section.

The other 2 seem random as there is no data up that far to see.

Until you know that 0x00FF to 0x2000 is external RAM space.
Anything addressing the area between those two factors is addressing the RAM.

Now these addresses are written here for humans not for the ECU as they are not in little endian.

I think they are a remonder to the programmers or diagnostic guys where the data is offset to in the ECU RAM.
0x1A08 is the offset we need to find when the ECU addressed the transfer functions
0x1E08 is the offset we need to find when the ECU addressed the transfer functions

My reasoning is as follows...

At 0x4ECC there is a bit of code that checks if 0x1D12 is higher than 0x1A08. It obviously is and it is exactly 778 higher than 0x1A08, the exact number of bits in the transfer function table with the self reference included. :twisted:

It then proceeds to do another check on 0x1E08 using the value 0x1F34. I am not sure how this check proceeds but 0x1F34 would be the end address if the table of tables started at 0x1E08! :shock:

I think the ECU mirrors the transfer functions and the table of tables to the RAM on startup and then reads them from the RAM. The ECU can only directly access data in the 0x0000-0x2000 range and to get it there it needs to perform several OPs, if the data is already in the external RAM section then its much faster to process. Hence putting these critical functions into the RAM.

I think if you do find a way to spy on the RAM at this critical location we will see a mirror of the transfer functions and the tables of tables.

It explains why we have no direct code references to the data sections, it explains why the ostrich will not trace the transfer functions and it explains why the offset has been so damn hard to find.


Regarding the DTC stuff, I again think you may be right, the 0,10,etc is just marking if it should throw up a CEL or not for that fault. However now we know there is 2 copies of the data we might be able to see where the ECU accesses those codes from and thus actually turn them off.

olafu
Posts: 141
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Post by olafu » Mon Nov 06, 2017 10:37 am

Hairyscreech wrote:I think the ECU mirrors the transfer functions and the table of tables to the RAM on startup and then reads them from the RAM. The ECU can only directly access data in the 0x0000-0x2000 range and to get it there it needs to perform several OPs, if the data is already in the external RAM section then its much faster to process. Hence putting these critical functions into the RAM.
It doesn't. "table of tables" is always in use. Transfer functions are all in use. Even that table of tables location: ECU reads EVERY time at first that address for index table (end of BIN), then table location from that index table, and then the data table. All changes comes in to effect at immediatelly. there is not enough RAM to use it like self-evident, so ROM is used if it is possible. Like that CEL blink codes: ECU reads one code to RAM at time. Like 1244. it comes out from RAM as blink code "1 11 1111 1111". Then it reads next from ROM to RAM. If you are changing that data area in "flight" it comes in to effect at next DTC.

Mykk
Posts: 99
Joined: Sat Sep 05, 2015 8:28 am

Post by Mykk » Mon Nov 06, 2017 4:50 pm

I haven't looked at your 413 yet, but in the 404 the redundant DTC enable table in the controller code has every code enable set to "0" , only a couple of codes are different numbers then the DTC enable table in the maps section. The blink code table in controller side has only a couple of different numbers too. But not much difference

In fact the redundant parts in the controller code that I've found (Control Bits, DTC Enable, DTC flash codes and DTC entry and exit values) aren't redundant at all. They all have different values then the Maps & Tables side counterparts.

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech » Tue Nov 07, 2017 6:42 am

The DTC codes seem to be all off (0x00) at the top of the 404 data set, and all off bar the vanos warning for the 413 set.
Could this be the initial condition?
I know the vanos throws a code if it does not respond as expected on power up/start up.

I thought the blink codes were identical in both sections? Which ones have changed? (hex addresses and I will look).

Olafu - Of course, was tired and didn't think it through. We know the table of tables is addressed. I have not seen the ECU trace the MAF function or the TPS function myself though?

Is there a RAM emulator we could splice into the ECU to be able to watch what the ECU puts into the 0x0000-0x2000 section?

Your right there is not enough room for the maps to be copied to the RAM, The chip only has 488 bytes of RAM 0x0018-)x01FF but there is also an "external memory" 0x0200-0x1FFD that is where the processor keeps a series of registers that it can address like RAM. It is not really "RAM" like we would know on a PC but it is used like RAM, think of it like a swap file.
Intel call it a "Register RAM"

The processor is a register to register architecture, it cannot do anything with data from the ROM directly, it has to move it to a register and then do the operation on it.
It has to load a piece of data into the space from 0x0000 to 0x2000, then do the logical operation on it, then store the result in another location from 0x0000 to 0x2000.

In this external memory section there is room for the transfer functions and just the table of table addresses, which is what the code suggests by marking out areas big enough for them both?
Not sure what to make of that at the moment but the 404 code also does the same using the two addresses from that same location.

This external memory might be whats in that flash chip you located. I will take another look at the data sheets for the processors to see if I can learn anything more from there.

Your comments about the order the ECU reads in make sense when you consider the register to register architecture. The ECU has to read the offset, then read the location that offset results in after calculation, then read the next location, so on and so on.

Mykk
Posts: 99
Joined: Sat Sep 05, 2015 8:28 am

Post by Mykk » Tue Nov 07, 2017 8:49 am

Looking at the 413 Red, there are two differences in stomp codes between the two tables and two differences in DTC enable.

In tuner pro if you make two 56x2 tables viewing hex, one starting at address 4484 and the other starting at address D19A. Open both tables side by side you can see all the flash codes are the same until you get to flash code 1291 = 1245 and flash code 1245 = 1264

Same with DTC enable, 56x2 tables @ D108 & 43F2 set to floating point.

code 38 = 37
code 57 = 64

The data between 42EE - 43F0 vs D004-D106 are also riddled with discrepancies. You can side by side the hex code by either using a new TunerPro instance or by using the compare .BIN option in HxD

...probably isn't useful information to help decipher processing info on these systems. Just something I've noticed.

Just as a test I wanted to see how the vehicle would behave if all of the companion tables matched so I copy & pasted the info from the 2nd half of all of the tables listed above into the 1st half. When I tried to load the .BIN on the emulator I received an error message from TunerPro:

"You messed up (I think) FAILURE: Bin is larger than emulation RAM: Perhaps you meant to use bank 8?"

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech » Tue Nov 07, 2017 9:43 am

Odd, did you do that in tuner pro or in HxD?

If it was HxD then you need to watch that you overwrite the section you wanted to edit and not add it.

PM me both your BINs and I will see if I can solve that. I wont be able to test it though, it's pitch black here and half the Irish sea is falling from the sky.

Also I understand what you mean now, it is not that the blink codes are different to the INPA codes, it is that the two versions of each of them do not match the other.

I am wondering if the INPA codes may pop up somewhere else in the code section?

Mykk
Posts: 99
Joined: Sat Sep 05, 2015 8:28 am

Post by Mykk » Tue Nov 07, 2017 1:13 pm

Stay safe & dry. I'm going to experiment some more on my end this evening.

Mykk
Posts: 99
Joined: Sat Sep 05, 2015 8:28 am

Post by Mykk » Tue Nov 07, 2017 5:10 pm

Just did a few experiments regarding the companion tables in my 404DME.

I must have done something screwy when I received error message earlier.

In my test:
Copy the data from tables in the 1st section and paste into 2nd section: Vehicle would fire up and run but was super pig rich and wouldn't respond to the "Injector Constant" value to lean out.

Copy the data from tables in the 2nd section and paste into 1st section, vehicle would fire up and run like normal with AFR's exactly where they were tuned too previously.

olafu
Posts: 141
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Post by olafu » Wed Nov 08, 2017 10:50 am

RAM dump is coming for curious buddies... :) i will try to read out that SRAM chip which is underside of PCB. Don't ask how, but i have the plan. :twisted:
ECU stores in that SRAM at least DTC:s with freeze frame, long term fuel trim tables and maybe knock adaptation tables. Maybe other adaptation values. And i think it is used as normal RAM also.

Mykk
Posts: 99
Joined: Sat Sep 05, 2015 8:28 am

Post by Mykk » Wed Nov 08, 2017 1:03 pm

Very curious for your findings and developments.

Evil
Posts: 133
Joined: Tue Jul 18, 2017 12:53 pm
Location: France

Post by Evil » Wed Nov 08, 2017 4:43 pm

Many of these stuffs (DTC codes, min/max thresolds, self-references are very similar in my 403 bin :D

Not very useful for you anyway, that was just to tell you that I pay a lot of attention to your work, it's very interesting!!! :P

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech » Thu Nov 09, 2017 2:41 am

The 40x non vanos ecus should be very similar, the layout of the data looks the same but the processor is the older 8051. Perhaps there is some milage in looking at the code of the 40x ecus to find the function of a few more maps? The 8051 code is better understood and easier to disassemble.

I have some high res photos and was meaning to trace the circuits back from the processor bto show what is on each input.

I think you are correct and that SRAM chip is the "external memory" as well as the adaption data. That was what I wanted to confirm by tracing the circuits.

olafu
Posts: 141
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Post by olafu » Sat Nov 11, 2017 12:45 am

I did some tests and get few RAM dumps.
https://www.dropbox.com/sh/n71udyq6nkl6 ... Bksla?dl=0

Those can be "noisy" because write enable is forced off by mechanical switch. But if i write bin which have DTC's, and fit it in the ECU, scanner shows all DTC's as original situation. Read "information.txt".

Those RAM dumps can help in disassembly (if you are thinking "seems like it does that..." and quick seeing in RAM: yes it does.), but i think they are quite useless for other things. Something high speed data logger what is reading values directly from ram?

Same address- and databus is shared for ROM and RAM, so all that data is possible to read from ROM socket (much more easier way than solder anything wire spaghetti on to the PCB . :lol:) Only few addition wires needed. In Ford ecus, Moates Quarter Horse can read RAM through J3 socket?

Mykk
Posts: 99
Joined: Sat Sep 05, 2015 8:28 am

Post by Mykk » Sat Nov 11, 2017 5:31 pm

Very cool. Just read the .txt.

Am I misunderstanding this or is the info you're reading off the external ram the same info that you would get from Rx & Tx serial communication used by CarSoft diag software?

olafu
Posts: 141
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Post by olafu » Sat Nov 11, 2017 11:46 pm

Mykk wrote:Very cool. Just read the .txt.

Am I misunderstanding this or is the info you're reading off the external ram the same info that you would get from Rx & Tx serial communication used by CarSoft diag software?
Diagnostic tool reads parts of this ram through K-line. But i don't know can it read whole memory.

EDIT: Fault codes starts from 0x1038. First byte is fault code itself, then comes 5 bytes of freeze frame data.

Example: blank_start_full_load_6200_we_off.bin
starts from 0x1038 like this: 45 68 9B A1 32 00

45= DTC69, 68= ??, 9B= 6200RPM, A1= ??, 32= ??, 00= ??

I have scanner what doesn't show any freeze frame data, but there is maybe TPS, MAF and CLT in it. Third byte is certainly RPM. (x*40)

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech » Sun Nov 12, 2017 7:43 am

BMWs INPA software can read this all "live", it has a section in the fault diagnostic section that allows you to read a section of the RAM from specifed address to specified address.

Not the most helpful though as you cannot take a snap shot of the data, which is what you need really if you want to spend any meaningful time analyzing it.

I think I need to go through and see what data on those dumps matches up with the register locations in use in the disassembly. That might point us to the code that triggers various things.

Question - Are you sure the fault code ID needs to be converted to decimal?
Fault code 69 does not seem to be present in the 413 data while 0x45 would indicate a knock sensor error (number 2 to be specific).
I believe all the INPA/BMW codes are in pure hex.

I am not sure I uploaded a sheet with all the codes put on and clickable.
If not then see this weeks update here: http://www.filedropper.com/413and506map ... s-17-11-12


I have also noted something odd.
I created that XDF for the 413 with all the same maps as the 506 XDF.
I ported all of my tuning over to the 413 BIN, made sure everything was exactly as it was for the 506 using the available maps in the XDF.
What I have found is the car was/is ~5% richer with no other changes.

There has to be something, either in the unknown maps or in the unknown constants area, that affects the global fueling. It goes some way to explaining why the "injector constant" is the same on 3 BINs with different injectors, different CC capacities and the same MAF.

Olafu - Do you have the ability to test the speed limiter (in a controlled way), the 0xC9 10 marked on the XDFs and 413 BIN is in the DTC section and I think its actually a lambda DTC. I have heard complaints before that the one on the XDF does not work.
There is a 0xC9 (0xD0E7) just above in the constants section that seems a more viable candidate. It is also set to 0xFE in the Alpina BIN, I believe Alpinas are not restricted like a stock car?
Last edited by Hairyscreech on Sun Nov 12, 2017 8:24 am, edited 1 time in total.

olafu
Posts: 141
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Post by olafu » Sun Nov 12, 2017 8:12 am

Hairyscreech wrote:Question - Are you sure the fault code ID needs to be converted to decimal?
Fault code 69 does not seem to be present in the 413 data while 0x45 would indicate a knock sensor error (number 2 to be specific).
I believe all the INPA/BMW codes are in pure hex.
All fault codes for motronic inputs/outputs are pin specified. Knock sensors are wired to pins 69 and 70, MAF 41, TPS 73, and so on. So i think they are intended as a decimal numbers.

In DTC table with fault code and on/off flag it only affects to a malfunction indicator lamp. 0=no light, 1=light is on, when fault is active. Fault codes are stored in RAM at any case. So you can choose faults what switches light on. But the fault code in that fault code table is code, what ECU stores in RAM.

Need to get INPA. :)

Very good finds !

EDIT:
Olafu - Do you have the ability to test the speed limiter (in a controlled way), the 0xC9 10 marked on the XDFs and 413 BIN is in the DTC section and I think its actually a lambda DTC. I have heard complaints before that the one on the XDF does not work.
There is a 0xC9 (0xD0E7) just above in the constants section that seems a more viable candidate. It is also set to 0xFE in the Alpina BIN, I believe Alpinas are not restricted like a stock car?
i can try.

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech » Sun Nov 12, 2017 8:33 am

Your right, I am being dense, strange morning.
I even used a list that gave both the Hex and Dec values to check the DTC and INPA codes.

The blink codes are written exactly as the ECU would spit them out to the dash but the INPA codes are turned into Dec values before being used.

I have not considered that a lot of them were pin specified, it makes sense as the vanos is on pin 7 and the INPA code is 7.

Worth noting though that we know the ECU will be using those HEX values for the fault codes, so they can be what we go looking for in the code sections.

I colour coded a lot of the code section further up based on my disassembly of the code.
I also added a red gradient to the columns of decimal numbers, I was surprised how clearly this highlights when there is structures in the data/code and also how closely this aligned with the disassembly.

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech » Mon Nov 13, 2017 10:35 pm

Confirm codes are 6 bits long.
Disassembly says there is only one reference to register 1038, at 0x4693.
The first 2 bits come from register 54, the second two from register 56 and the last two from register 26.

Edit - Can we assume from that the data is coupled into 3 pairs?

I note the first number seems to always be followed by a 68 or a B1. Can we assume the trouble code ID is coupled to this 68 or B1 in some way as it is provided by the same processor register?

Also the same for the next two bytes? The 56 (for 3440 RPM) is the first byte, can we assume the second byte is RPM related?
Last edited by Hairyscreech on Tue Nov 14, 2017 6:09 am, edited 1 time in total.

Mykk
Posts: 99
Joined: Sat Sep 05, 2015 8:28 am

Post by Mykk » Tue Nov 14, 2017 2:34 am

Pretty cool. You guys are going where no obdI motronic tuner has gone before. :-p

olafu
Posts: 141
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Post by olafu » Tue Nov 14, 2017 9:26 am

Next to faultcode itself comes flags what tells what is wrong with input/output: signal high/low, short to b+, short to ground, no signal and whatever, maybe flag, if fault is triggered by more than one times/limits?
01110010 signal low, 01110001 signal high, 01101000 no signal, tested: 11110010 signal was first low but then high, fault code (6 bytes) is stored only once, but MSB in second byte switched from 0 to 1.

Mykk
Posts: 99
Joined: Sat Sep 05, 2015 8:28 am

Post by Mykk » Tue Nov 14, 2017 4:15 pm

olafu wrote:Next to faultcode itself comes flags what tells what is wrong with input/output: signal high/low, short to b+, short to ground, no signal and whatever, maybe flag, if fault is triggered by more than one times/limits?
01110010 signal low, 01110001 signal high, 01101000 no signal, tested: 11110010 signal was first low but then high, fault code (6 bytes) is stored only once, but MSB in second byte switched from 0 to 1.
Does that lead to be 01110011 would be no fault detected?

olafu
Posts: 141
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Post by olafu » Tue Nov 14, 2017 8:21 pm

when i get inpa i will check those.

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech » Wed Nov 15, 2017 12:13 am

If you need any help getting hold of INPA or setting it up then let me know, its a fussy thing as it was only meant to work on an IBM T40 with the BMW Diag head set up.

You will need an ADS signal converter for these ECUs (and all obd1) the best/most economical for what we do is the tiny ADS from the US.

http://openlabs.co/projects/Tiny-ADS-Interface

From the things you have suggested you may be able to put together the converter from the open source info on the site though.

I have a couple of codes that the E30 threw while I was still getting it sorted out, and I know the cause and resolution, these might get us started.
Certainly I still have the ignition monitoring fault that is persistent due to the nature of the M20 install.

Edit - Here you go, a few captures of some INPA errors, the secondary ignition monitor is the 5v reference issue I mentioned before which is present on the RAM dumps you posted, speed and load etc is different.

Mykk
Posts: 99
Joined: Sat Sep 05, 2015 8:28 am

Post by Mykk » Wed Nov 15, 2017 3:21 pm

I ordered a CarSoft adapter and software from Hong Kong about a month ago, still hasn't arrived.

If I use the above adapter what software are you using?

Mykk
Posts: 99
Joined: Sat Sep 05, 2015 8:28 am

Post by Mykk » Wed Nov 15, 2017 6:39 pm

Any more insightful information about those DTC entry and exit values located between D22C through D28E. There's alot of code in there unaccounted for. :-)

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech » Thu Nov 16, 2017 4:24 am

Nothing much yet. Only able to grab a few spare hours here and there recently.

Started looking at those RAM dumps to compare the changes in the different ECU states (off, idle, running and rev limiter), want to track those back to the code sections that write to those RAM areas.
Might allow us to actually start cracking the programming, something no-one has been willing to reveal so far. These are poorly understood for such a common and regularly tuned car, not much info available really on a 23 year old system.

Latest working sheet here:
http://www.filedropper.com/413and506map ... s-17-11-16

To talk to these ECUs via the 20 pin plug in the engine bay you need an ADS converter like I posted above.
Then you will need either INPA or a suitable code reading software.

INPA is available online, someone with a wooden leg and a parrot on their shoulder may be able to offer you a copy.
Otherwise the best/ most legitimate way to get it is to get an ex-BMW IMB T40 laptop and diagnostic head (yellow head) as that is what BMW used in the dealers to deal with OBD1 cars.
A lot of dealers have ditched this capability now so bare that in mind if you ever take a pre-1996 BMW to a dealer.

Kit list for INPA:
Older laptop running XP or windows 2000/NT, Must have a serial port
Cheap round 20 pin OBD1 adaptor from Ebay
TinyADS or open source ADS adaptor, others available but not cheap.
INPA software

Bonus of this is it will also give you (limited) almost live data from the sensors and talk to the body modules of the car like the ABS etc to diagnose and clear fault lights.

olafu
Posts: 141
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Post by olafu » Fri Nov 17, 2017 4:16 pm

Olafu - Do you have the ability to test the speed limiter (in a controlled way), the 0xC9 10 marked on the XDFs and 413 BIN is in the DTC section and I think its actually a lambda DTC. I have heard complaints before that the one on the XDF does not work.
There is a 0xC9 (0xD0E7) just above in the constants section that seems a more viable candidate. It is also set to 0xFE in the Alpina BIN, I believe Alpinas are not restricted like a stock car?
I found speed limiter from 0xD093-0xD095. (413/623 BIN)
0xD093 = Ignition advance addition when speed limit fuel cut is active?!
0xD094 = Speed limit
0xD095 = Speed limit hysteresis
Actual speed limit is speed limit+hysteresis. So, fuel is cutted when speed limit+hysteresis is reached and when speed is reduced below speed limit, fuel comes back.

Values are raw data? 175 + 4 in default(dec) and i've been driving 240km/h without fuel cut with that BIN. (now i only did simulator tests) :)
0xD093 "63" in default (dec) I tried (x-60)*0.75:
0 = advance didn't change. 10 = 10 degrees advance addition when fuel cut is active. -10 = 10 degrees advance reduction. +2.25 deg in default.
All injectors will cut and back at same time, there is no "buffer" area like rev limiter has.

Mykk
Posts: 99
Joined: Sat Sep 05, 2015 8:28 am

Post by Mykk » Fri Nov 17, 2017 6:25 pm

Interesting that engineers would advance ign by a couple degrees in speed limiter fuel disable. Very cool find!

Unfortunately my 404 doesn't have the same three bytes, I have found speed limiter and buffer

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech » Sun Nov 19, 2017 5:06 am

Checks out, I have the same 3 bits here on the alpina BIN with the middle of the 3 set to 0xFE, we know the Alpina was advertised as not having the limiter so having it set to the highest functional value makes sense.

Oddly the 506 M3 bin has 0xBE and the 413 0xAF.

Implies the US M3 has a higher limiter than the stock 325?

The ignition advance is probably to help with the lean condition created by cutting the fuel injectors.
The fuel cut will slash the engine power above the threshold but the speed will then oscillate around the trigger point (foot hard in on a autobahn), The weak mixture may cause misfire if the ignition is not advanced, weak mixtures are harder to light and take longer to begin burning, I expect if the speed is sustained then the result is a horrible surging as the fuel is cut and restarted making the engine hover in and out of misfire.

Edit - BMW never stated a number for the speed limiter on the normal e36 as far as I can see. (might be wrong?)

If we stick with the same conversion factor for the limiter then the stock E36 would be 130mph (175*1.2 = 210kph) which checks out with what people report online for the max they had out of a stock e36.

The M3 works out to 141mph which with the 4mph buffer deducted fits with the reports here:
https://www.bimmerforums.com/forum/show ... -top-speed

Mykk - Where do you think the 404 speed limiter is on the 404? I will mark it on the sheets I have.

Mykk
Posts: 99
Joined: Sat Sep 05, 2015 8:28 am

Post by Mykk » Sun Nov 19, 2017 7:56 am

Hairyscreech wrote:Mykk - Where do you think the 404 speed limiter is on the 404? I will mark it on the sheets I have.
C08B - 167dec - Limiter
C08C - 4dec - Buffer

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech » Sun Nov 19, 2017 8:54 am

OK, got it, would imply a 124mph speed limiter.
What led you to that location?

Mykk
Posts: 99
Joined: Sat Sep 05, 2015 8:28 am

Post by Mykk » Sun Nov 19, 2017 9:19 am

Hairyscreech wrote:OK, got it, would imply a 124mph speed limiter.
What led you to that location?
In my experimenting I noticed you can open a factory .bin in the Miller W.A.R. chip tuning software. If you save the .bin it saves in their format and converts the .bin to their specific flavor of hex code. But the map address & locations are the same as an original .bin

I opened a stock tune, saved it. Changed the speed limiter, saved it. Then opened both files in HxD to compare what address the changes were made. Then go back to original .bin and see what value or map is in that address.

Every change I'd make in the Miller WAR program, no matter what map, coincided with the correct maps in the tuner pro .xdf

I also used this same method to see how Miller W.A.R chip disables lambda feedback, and it's an entire table not a flag. I believe in your 413 it's 4 different lambda tables, the 404 it's consolidated into one.

If you open a stock .bin in Miller W.A.R. software the raw fuel figures translate to the direct dec of the code. Their ignition timing formula does not appear to line up with what we use.

If this is something you would like to experiment with, here is the download link for the Miller W.A.R. software:

http://www.millerperformancecars.com/customer99/wiz/

The 413 & 506 are categorized together and the 506.bin opens in the software (not the 413).

Evil
Posts: 133
Joined: Tue Jul 18, 2017 12:53 pm
Location: France

Post by Evil » Sun Nov 19, 2017 11:33 am

on 403 I have both for lambda regulation: a 6x6 table and 3 2D tables. Set the whole 6x6 table to 0 turns the lambda regulation off, same thing for the 3 2D tables.
On the 413-623, datas in the table in 0xE204 are very similar to the table of the 403... maybe these datas are a coefficient for the PID and act on regulation speed? It seems that regulation is faster at high rpm/load, which make sense with datas values of this table...

Mykk
Posts: 99
Joined: Sat Sep 05, 2015 8:28 am

Post by Mykk » Sun Nov 19, 2017 5:22 pm

It would be interesting to see the similarities between M3.1 & M3.3 /M3.3.1. I wouldn't imagine much translates between the two platforms. But perhaps a little.

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech » Wed Nov 22, 2017 10:45 am

From what I can tell so far there is a lot of similarities.

They did not reinvent the wheel when they went to a new system, pretty much carried over as much of the old version as was applicable and added/change anything they needed to suit their needs.

It is why so much of the info on the old 1.3 E30 ECU is still applicable to this generation and beyond. I believe they still use the table format on the newer power PC ECUs? (I will find out soon, I think work is going to require me to leverage an as yet unreleased powerPC based ECU to perform the testing we need to do, I don't yet know if it is a Bosch ECU though)

Something I was planning to do was take a look at the 402 code, I believe it is still a 80196 processor but is without the vanos, knock control, EWS and traction control functions of the M3.3 ECU.

Edit - Revising my previous statement until I have some more information. :-
If I swap the known fueling data from the 506 code to the 413 code my cruise fueling is richer by about 5%.
My acceleration is leaner but roughly 2%.
Fueling is different at the same load as I go up through the RPM between the codes. Can't remember exactly how much right now but I will check.
The car does not run anywhere near as well.
I have checked this A-B-A (506->413->506) and can 100% confirm it is happening.

To get the 413 tune to run at the same AFR as the 506 I had to scale the fueling down 5% in the main fuel table, however the car was just not the same at higher RPM/load.
I also have an issue due to the application that the AFR bounces when I rol out of gear, on the 506 code it bounces ~13.5 to 15, on the 413 it was going mid 12s to high 16s and threatening to stall.

To be clear, I used the matching 413 XDF I made to port all of the currently tunable tables over from the 506 to the 413 code base. This should have meant the required adjustments for the M20 were carried over to the 413 from the 506, clearly this is not the case.

I have found that my RPM axis do not quite match between the two tunes so I will correct that to the 506 tune that seems to work better and report back. I think this would only explain the upper RPM 2% and not the low rpm 5%. The cell values are still very similar for cruise fueling (97 vs 98 ) so doesn't explain the 5% change.
My Idle fuel has the same difference and that would not be affected by the part throttle table RPM axis.

I still think there is something in the ECU that add and additional fuel trim over and above the main fueling tables.

These ECUs have both batch and sequential injection (batch a high RPM and sequential at low RPM), along with the ability to work with a lambda sensor in each down pipe (assumed from 4 lambda tables) and a knock sensor for each bank.
I suspect this comes with the ability to trim the fueling per bank to make up for exhaust and intake manifold geometry affects. If you have seen the standard M60 manifolds then 100% no way the V8 has perfect fueling lh bank to rh bank without a fuel trim.

I feel this has to be in there as the ECU was first designed for the V8 which cannot balance its exhaust gasses, if one bank was rich and one lean then catalytic converter life would be terrible. Getting it to pass emissions would also be hard work.

If there is 1 or 2 tables for bank 1 and bank 2 fuel trim then they are RPM based at a minimum as breathing (and thus imbalance) would not be constant through the RPM range.
This means it has to be one of the unknown and active tables and not a constant value.

To clarify, My WBO2 only reads one bank.

Going to check some of the Damos files I have for other ECUs to see if this exists in other similar ECUs.

Mykk
Posts: 99
Joined: Sat Sep 05, 2015 8:28 am

Post by Mykk » Fri Nov 24, 2017 4:56 pm

Any developments in the code work?

Just went for a ride in a friends E30 he just converted to Megasquirt from a 153 or 173 dme. Runs so smooth compared to previous. It's super inticing to go standalone ecu. The more unknown variables we can remove from the equation the more we can tune these motronics like standalone for reliable consistency and dependable performance. Unknown variables are scary in the tuning world for sure.

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech » Sat Nov 25, 2017 5:39 am

TBH even my currently unmapped M3.3.1 on the M20 is better and more responsive than the M1.3 was.

Already gone is the minor hesitation you got with the AFM system.

The old M1.3 is an ok system but suffers from the mechanical nature of the air flow sensing and the ignition. I have already found the big flat spot that M1.3 M20 engines seem to have around 4300rpm is gone, I don't have to pull timing at that speed so it is purely an artifact of the engine management.
I think I will still have some timing pulled at that speed due to the engine design but not the 10-15 degrees at high revs you can see on the 173 bins.
The M20 also suffers from slightly slow port flow speeds, this means with the 3 bar single hole injectors that the air fuel mix is poor at some speeds and loads, meaning horrible yank V8 timing angles on a pretty modern combustion chamber design.

I need to get some multi hole injectors onto my M20 really. I have some Pinktops I have been saving for a later engine build, might get those on sooner rather than later.

Evil
Posts: 133
Joined: Tue Jul 18, 2017 12:53 pm
Location: France

Post by Evil » Sat Nov 25, 2017 3:28 pm

Little question about 2 tables in the 413:

0xE3BC 6x6 Rpm x ECT which is named "Idle Valve Airflow" in the Excel file ;
0xE3F0 4x6 Rpm x ECT "Deccel/ Overrun fuel

Thes 2 maps have the same ECT scaling, RPM scaling is similar too since the 6x6 table has just 2 more points at lower rpm.
Datas are also relatively similar.

If I understand correctly Deccel fuel is fuel adition in decceleration to avoid lean surge if throttle is re-opened ?

The fact that the 2 maps are ECT and RPM related and very similar makes me think the 2 maps could be used for wall wetting modelisation?

Did some tests have been done on these?

I have the same 2 maps on my 403, and i can fin them in different versions of MP3.1 and MP3.2 (N/A and Tturbo)

Evil
Posts: 133
Joined: Tue Jul 18, 2017 12:53 pm
Location: France

Post by Evil » Sat Nov 25, 2017 3:31 pm

Little question about 2 tables in the 413:

0xE3BC 6x6 Rpm x ECT which is named "Idle Valve Airflow" in the Excel file ;
0xE3F0 4x6 Rpm x ECT "Deccel/ Overrun fuel

Thes 2 maps have the same ECT scaling, RPM scaling is similar too since the 6x6 table has just 2 more points at lower rpm.
Datas are also relatively similar.

If I understand correctly Deccel fuel is fuel adition in decceleration to avoid lean surge if throttle is re-opened ?

The fact that the 2 maps are ECT and RPM related and very similar makes me think the 2 maps could be used for wall wetting modelisation?

Did some tests have been done on these?

I have the same 2 maps on my 403, and i can fin them in different versions of MP3.1 and MP3.2 (N/A and Tturbo)

Mykk
Posts: 99
Joined: Sat Sep 05, 2015 8:28 am

Post by Mykk » Sat Nov 25, 2017 5:04 pm

I believe one to be IAC idle, PT, WOT...the other is IAC fuel cut/decel. I have them in my 404 as well and can watch them switch in and out while cell hit tracing when it goes into fuel cut off /decel.

olafu
Posts: 141
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Post by olafu » Sun Nov 26, 2017 3:46 am

0xE3BC 6x6 Rpm x ECT which is named "Idle Valve Airflow" in the Excel file ;
I think that is only a some kind base position of idle valve at different engine speeds and temperatures. Ecu reads it always when engine is running. I was used that to correct idle problems (stalling, "pumping" and so on) when using different camshafts what has poor vacuum at idle.

I think it is also used to reduce excess vacuum from intake manifold in overrun conditions. High vacuum causes oil passing in to the combustion chambers and leads higher rate to burning oil and so rises HC emissions.

In MAF fault mode (Alpha-N) there is correction for LOAD by actual idle valve position/duty cycle. I'm not find that factor/map yet, but there must be one.

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech » Sun Nov 26, 2017 5:24 am

The literature on the ECU does state that the ICV is used to help prevent harsh snatches on overrun. A clumsy snap shutting of the throttle on a high engine braking RWD car can be disastrous and lord knows the world is full of clumsy drivers.

Your right about trying to control the vacuum high vacuum can make valve stem seals leak, pull oil up the crank breather and prevent the car from coasting which hurts mpg (but helps control?) so limiting the vacuum is of benefit if you are worried about that kind of thing.
Its all emissions related really but can be used to make for a smoother drive in stop start traffic, certainly if you have a quick throttle, light flywheel, heavy clutch and high manifold vacuums.

There will need to be an overrun fuel input because this was design for a catalytic converter car, if you don't have some fuel on overrun you will load the cat up in a lean condition and NOx will start bypassing the cat.

If your not worried about that you can shut off the decell fueling a little but some will help to keep the piston crowns cool if you are flogging the car.

There are several unknown maps at this point, I have been thinking about adding them all into an "other" section on the XDF with as much detail as we can currently work out so that we can all chip away at them.

I expect a lot of them to be unrelated to the basic tuning, however I expect the could be re-purposed for other needs if we knew what they did.


Also - I went out last night with the RPM corrected on all tables of my 413 BIN to match the 506, it was a lot better.
I also prepared a tune with the D002 section copied over and one with both the D002 section and the D106 section.
Drove 2 very familliar routes and can say the following:
RPM corrected - The ECU does not like when the tables have mismatched RPM scales, no surprises there really.
D002 section - 100% did something to the fueling, I think I have a couple of candidates (D0A3 for one, it was though to be EWS related but it is adjusted on all the BINs I have).
D002 + D106 section - adding the DTC codes section confused the DANG! out the ECU, not recommended for a just cycling the ignition on-off-on test, was not happy until I disconnected the battery for a bit to clear the keep alive memory.

I also tried resetting the "injector constant" to the stock value, taking away the load scaling and instead adjusting the fuel tables down the way Alpina did on the Alpina BIN (Thinking they had better info to work on than we have atm).
Soooooo much better before even getting the fueling really set up again.
Happy to cruise with no surging down to 15.6-16:1, idle at 15:1 and way more torque than how it was before.
I understand adjusting that constant can work and lots of power has been made that way before but the data we have just does not point to it being the right way to do it.
The fuel correction factor in the fuel table is directly proportional to the fueling change, if I need to knock 5% off the fueling a simple 5% change to that table covers it with no mucking about. Simply dropping the values in there should cope with a big injector change.

Going out to do a few more tests in a bit and will feed back.

Mykk - You said Miller has a different ignition conversion factor? What do they have?
If your not sure and want me to back calculate it then give me a PM.

Mykk
Posts: 99
Joined: Sat Sep 05, 2015 8:28 am

Post by Mykk » Sun Nov 26, 2017 5:47 am

Would you guys mind taking a look at a map in the 404 for me?

There is an 8x8 RPM vs Load (D0 vs D5) table starting at CB7E that appears to be filled with raw timing values. According to cell hit tracing this table is always in use. Modifying the values in the table doesn't seem to affect vehicle behavior. The values are identical with every 404 I've compared; 530i, 540i, Auto, Manual...every chip read has the same table with the same values.

I guessed it has to do with injector firing angle? Do you guys have a way to see what this table controls?

Mykk
Posts: 99
Joined: Sat Sep 05, 2015 8:28 am

Post by Mykk » Sun Nov 26, 2017 6:00 am

Hairyscreech wrote:
Mykk - You said Miller has a different ignition conversion factor? What do they have?
If your not sure and want me to back calculate it then give me a PM.
I wouldn't be comfortable using their ignition timing calc as it's likely converted for their specific coding and offset.

On the left is tunerpro using the ignition offset we currently know, on the right is Miller software reading the same exact .BIN directly from a chip read on a 530i.

Image

The Miller self populates the RPM axis from the header information, my .xdf was done using the header info from my 540i/6 and likely has different RPM header values

I got CarSoft fired up and working only to find out it won't live data OBDI. I was really looking forward to seeing the actual ignition angle value compared to programmed. Oh well.
Last edited by Mykk on Sun Nov 26, 2017 6:27 am, edited 4 times in total.

Mykk
Posts: 99
Joined: Sat Sep 05, 2015 8:28 am

Post by Mykk » Sun Nov 26, 2017 6:04 am

olafu wrote: In MAF fault mode (Alpha-N) there is correction for LOAD by actual idle valve position/duty cycle. I'm not find that factor/map yet, but there must be one.
Excited for your findings.
Hairyscreech wrote: I also tried resetting the "injector constant" to the stock value, taking away the load scaling and instead adjusting the fuel tables down the way Alpina did on the Alpina BIN (Thinking they had better info to work on than we have atm).
Soooooo much better before even getting the fueling really set up again.
If you've already said, or it's in your your spreadsheet I apologize for asking. But how does Alpina adjust it's fuel tables compared to standard?

Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech » Sun Nov 26, 2017 9:23 am

Here you go - One zip file containing a modified alpina tune to work with the 506 XDF, one 506 M3 BIN and the matching XDF.
I have also saved the latest copy of the sheet to open on a page showing the alpina tune against the 506 tune, with a column displaying the numerical differences and and changes highlighted in pink/red.

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


There are fewer differences than it would seem and quite different to what people have been doing in the past.

Key points are that the raw code section was identical to the silver label 413 BIN, which excluding the EWS stuff is nearly identical to the 506 code/mapping

The engines are similar 3.2 for the 506 and 3l for the alpina.

Power output is similar yet the injectors are different. Perhaps we should give Mohamedramli on here a nudge to confirm his injector part numbers.

Post Reply