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 »

So I take a weekend off to be ill and all this happens! :lol:
olafu wrote:
Evil wrote:There is one table in 16x1 just after these 2, could it be E050 for PT and E0A1 for WOT?
Yes, similar function like E050 and it's traced only in WOT. E050 isn't traced in WOT.


I have these tables noted down as "PT and WOT load map data for/to A/T transmission" Can't really explain that much as I picked it up from another XDF. Maybe that helps a little?
I know if paired with an auto ECU these ECUs will provide a certain amount of info to the transmission controller.
(Does that mean we could sniff a true "LOAD" signal from one of the connections to the transmission controller?! :twisted: )
olafu
Posts: 186
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Post by olafu »

Needs something bus sniffer, and software for it. And a car. :lol: (or much better simulator) Then we can view datastream what ecu sends to EGS and what it sends back.
Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech »

That I might be able to arrange!

I will for sure have access to it via work, the car may not be ideal as its an E30 manual but otherwise I might be able to rustle something up.

I might also be able to just find out.... Will see what I can do.

Also, not yet finished the master list of tables on the XDF but I will get it into the dropbox as a work in progress.

I have added the acceleration enrichment tables and the damping factors.

Need to try to get all the axis set up right as well.

I have been trying to work out the required function for D7, at the moment my best guess is Xx0.75-48 but the only justification for it is that it seems to fit numerically with what I see on a car.
Not really a good justification. :roll:
Mykk
Posts: 99
Joined: Sat Sep 05, 2015 8:28 am

Post by Mykk »

Really bummed seeing this thread slow down after so many amazing discoveries. Any further developments to aid in removing some of the mystery of the Motronic?
olafu
Posts: 186
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Post by olafu »

I'm waiting for my ADS TINY adapter and planning to purchase complete engine simulator, like MST-9000. It can be used with other ecus too.
Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech »

I think its just the run up to christmas. I have been pretty tied up with various things, social events, minor fixes due to bad weather, work, other projects etc and obviously the OBD2 output module.

Hopefully take some time next week to get the software "finished" on that and if my sisters 2 year old drives me nuts enough to go out in the cold then also wired in.

Got a few jobs lined up for the time I have off so I have been putting off those things until work breaks up.
User avatar
dex
The Ford Guy
Posts: 612
Joined: Thu Oct 07, 2004 6:38 am

Post by dex »

Hairyscreech wrote:Beware of putting in 0xFF or 0xFD as both seem to cause a bit of a fuss in the processor. One is the code for reset and the other is the code for NOP, they shouldnt be interpreted as code due to their location but both seem to be a problem in some tables.
Any issues with using 0xFF or 0xFD in data locations is not because the CPU is treating the value as an instruction. Unexpected / undesirable effects will be due to the value exceeding the range the calculation was devised for e.g. one that results in an un-handled overflow.
Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech »

Your probably right, I have not considered pushing the resulting outputs into overflow or flipping the resulting numbers into the negatives.

I think that is something we will have to watch out for on a lot of the tables and is something not actually mentioned anywhere else when looking at these ECUs.

Also - Updated the master table list and the XDF I am using to tune.
The excel file has also been updated to match the most recent information.

They are all in the dropbox folders as before, if anyone spots any mistakes PM me and I will correct them ASAP. 8)
olafu
Posts: 186
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Post by olafu »

VIN code, date of manufacturing and some other information is located at 0xFEBE. INPA can show it clear, but it's not in ASCII format in BIN... And it's not directly written, it's splitted in "blocks" or something. Can somebody explain how that code can be translated to VIN? :D

VIN's first letter is located at 0xFEBE: (in dec:) 0=0, 9=9, 10=A and 32=W, 33=X and so on. But that works only with first letter. Third letter comes next, then 4th and 5th, but i didn't do more research.

RAM and ROM addresses can be read through K-line, up to about 30 bytes at one time. INPA polls those RAM addresses continuously. RAM addresses from 0x00 to 0xFF can be read, but they are CPU internal registers. Multi purpose register addresses starts from 0x1A (according CPU user's guide) and ends to 0xFF. 0x100 -> is located in external SRAM chip? Fault codes can be read in raw hex from 0x1038 .
Axis descriptor values matches with those address values, so, e.g. actual RPM matches, if you read it from 0xD0 (x*40). That helps if you are working with "axis descriptors" to clear what they are. No need to do "dummy tables" with long axis to trace them, but tracing has high speed. It's still very useful comprare two values by tracing 2D dummy table.
Evil
Posts: 140
Joined: Tue Jul 18, 2017 12:53 pm
Location: France

Post by Evil »

Hi all,
Does anyone knows any conversion factor for datas in D75C? (injectors dead time). Will have to re-tune it because I will change mines for slightly bigger ones. I searched on the web for the dead times of the OEM ones to try to calculate a factor with it for the 403 DME but wasn't able to found anything :? (the OEM are 0280150415).
I guess that's a simple factor without any offset?

On another subject: by looking at the four "lambda tables" used to disable closed loop, I believe that datas in those tables can be a load thresold for switching to open loop.. It make sense with the fact that the value is lower with RPM increase, that scales are mostly at high RPM and that setting all values to 0 disables closed loop... I wil take a look when my car will be running again
Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech »

Evil wrote:Hi all,
Does anyone knows any conversion factor for datas in D75C? (injectors dead time). Will have to re-tune it because I will change mines for slightly bigger ones. I searched on the web for the dead times of the OEM ones to try to calculate a factor with it for the 403 DME but wasn't able to found anything :? (the OEM are 0280150415).
I guess that's a simple factor without any offset?

On another subject: by looking at the four "lambda tables" used to disable closed loop, I believe that datas in those tables can be a load thresold for switching to open loop.. It make sense with the fact that the value is lower with RPM increase, that scales are mostly at high RPM and that setting all values to 0 disables closed loop... I wil take a look when my car will be running again
I believe the factor is x*0.05=ms and it is a value in raw milliseconds of open time.

There is a spread sheet in the tools folder of the dropbox that is calle "motronic injector dead times" with a comparison of the M20 and M50 injectors from when I needed to get my injectors right.

It makes a huge difference.

Also I will come back to that INPA post this weekend, it confirms some things I already though.
olafu
Posts: 186
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Post by olafu »

If i remember right, i measured it with scopemeter and it was x/100, 255 = 2.55ms :? And yes, it's raw addition. If 403 and 413 injector dead time tables looks such similar, i think it is x/100 in 403 too.
Evil wrote:..On another subject: by looking at the four "lambda tables" used to disable closed loop, I believe that datas in those tables can be a load thresold for switching to open loop.. It make sense with the fact that the value is lower with RPM increase, that scales are mostly at high RPM and that setting all values to 0 disables closed loop... I wil take a look when my car will be running again
M3.3.1 has load thresholds for switch closed loop off. At least Evilm3666 was found them.

But i think M3.1 has similar emission stage control bit as M3.3.1 has, but no one hasn't just been able to find it...
Last edited by olafu on Thu Jan 04, 2018 11:25 am, edited 2 times in total.
Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech »

You could be right and its X*0.01.

That's what I get for not double checking before I post. :x
Evil
Posts: 140
Joined: Tue Jul 18, 2017 12:53 pm
Location: France

Post by Evil »

Ok guys, thanks :D
Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech »

Just checked and it is X*0.01

So as always Finland is in the lead. :P
olafu
Posts: 186
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Post by olafu »

0xD00C- BIT4 is controlling VANOS output stage. It's "0" in stock bin, but if you put "1" the vanos output stage switches continuously "ON" and fault code from vanos will never stored, if solenoid plug is pulled off.

Vanos control algorithm is still in use, but if it never ever trying to move vanos to "advanced" position, it stucks to advanced and then ecu reads only vanos advanced tables.

I found this at long time ago, but never get enough time to check what else that bit does, but all seems to work properly.. But, you use this in your own risk :)
Evil
Posts: 140
Joined: Tue Jul 18, 2017 12:53 pm
Location: France

Post by Evil »

Good info!
So that could be useful on a NV motor To avoid having a solenoid plugged (or dummy load) and then not to have To tune identically retarded and advanced tables, right?
olafu
Posts: 186
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Post by olafu »

Seems to work, my frend's race car has that like modified bin and no vanos. But if it were official toggle for vanos code, it should switch whole vanos control off... :?
Mykk
Posts: 99
Joined: Sat Sep 05, 2015 8:28 am

Post by Mykk »

When you say D00C - BIT4 do you mean @ address D00F there is a byte with 00?

In the 413.bin I'm looking at D00C is value 08, but at D00F there's a 00.....on the 4th byte away counting D00C as the first.
olafu
Posts: 186
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Post by olafu »

You must split that byte to bits. As in emission stage 0xD00B BIT2. 0xD00C value is 08H, so it is 00001000 in binary. You count bits from right to left, and start from bit 0. When you turn BIT4 to "1", D00C value is 00011000 and it is 18H.
Mykk
Posts: 99
Joined: Sat Sep 05, 2015 8:28 am

Post by Mykk »

Ohh! Very cool
Mykk
Posts: 99
Joined: Sat Sep 05, 2015 8:28 am

Post by Mykk »

I've got the same byte in my 404dme V8, it is set to 08H just like the 413. I decided to see how it would respond changing that byte to 18H despite not having vanos.

The vehicle didn't respond any differently and still pulled ignition from appropriate tables.
Mykk
Posts: 99
Joined: Sat Sep 05, 2015 8:28 am

Post by Mykk »

Any new goodies for us M3.x guys? :-)
Mykk
Posts: 99
Joined: Sat Sep 05, 2015 8:28 am

Post by Mykk »

I'm currently going through all of my collected .bin's for my vehicle and making usable xdf's for each and I wanted to truly thank you guys for the time and work you've put into disassembling and reverse engineering the M3.3.

I've got a race event this weekend in Tucson Az, mostly just a test & tune drag event and a hang out & good time. I'm excited to take these tuning tools with me to the event. Again thank you.
kortex16v
Posts: 5
Joined: Tue Jul 12, 2016 9:06 am

Post by kortex16v »

Image

thanks to you, I managed to work my Dme 075, I have more than adjust my .bin on a Dyno and test all the parameters that I develop thanks to you.
I just expand the maps and reset the axes, I just have to validate all that to share my XDF.
I'm also going to run the launch control on my dme so there is still a little work

Thanks a lot to all motronic guys;)
Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech »

Quick question for anyone...

I have been playing with the acceleration enrichment tables to get the M20 running correctly with a flat fuel table like the factory M50 tunes use.

To get the fueling up to 14:1 at higher loads I have had to increase the "acceleration enrichment quantity by RPM and load" a huge amount in the high RPM and load areas.
I have increased the numerical values to 5-7.5 times greater than the stock M50 tune.

I did also try dropping the "Acceleration enrichment delta LOAD attenuation" a little.
This seemed to have more impact that upping the other table.

I understand that lowering the Delta load table is the same as increasing the quantity table but which one has the larger effect on the enrichment?

Is the Delta load table a coarse adjustment and the enrichment table a fine adjustment?

Are we sure of the interaction of these two tables?
olafu
Posts: 186
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Post by olafu »

I think that delta load attenuation is used for tune acceleration enrichment sensitivity and scaling load change rate (indirectly throttle opening rate) to enrichment. I can imagine that is comparable to acceleration pump pivot ratio in traditional carb system.


Still i don't know what that other delta load (D4F9 32x1) table actually does, but i think that strategy is roughly like: D4F9 is main rising rate of load, and it is divided by value picked from DC57. DC57 expands that load change rate to "actual load and rpm dependent basic value for enrichment" :? , and it will be processed to actual enrichment by those other tables.
CLT correction "DC31" could be used to rough tune for amount of enrichment.?

But i can't say nothing sure. We need disassembly. Also, about that D4F9, we don't know, but it can be global. By adjusting that D4F9 to tune acceleration enrichment, it can mess something else.

When we know quite a lot about how everything works in practically, it could be a big help in disassembly.
Full disassembly needs lots of work and effort, and those who have time to do it do not know how, and they who know, do not have a time :lol:
Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech »

Full disassembly needs lots of work and effort, and those who have time to do it do not know how, and they who know, do not have a time Laughing
Tell me about it. I'm hoping someone I work with now may be able to help on that side, at the moment putting together an arduino program to measure and calculate all the sensors is tough enough.

On that side though it's starting to work and come together, if/when we can get live data logs we can carefully pick over the maps easier and even play back the sensor results to the ECU to see its true response.

Has your TinyADS arrived?
olafu
Posts: 186
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Post by olafu »

Hairyscreech wrote:
Full disassembly needs lots of work and effort, and those who have time to do it do not know how, and they who know, do not have a time Laughing
Tell me about it. I'm hoping someone I work with now may be able to help on that side, at the moment putting together an arduino program to measure and calculate all the sensors is tough enough.

On that side though it's starting to work and come together, if/when we can get live data logs we can carefully pick over the maps easier and even play back the sensor results to the ECU to see its true response.

Has your TinyADS arrived?
Tiny ADS has been arrived, but INPA doesn't work with 623 BIN. :x But with 506 bin i did some tests. Nothing significant features, but ROM and RAM dump is nice.
Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech »

ROM and RAM dump in a couple of conditions may be a big key to getting a disassembly sorted out. The biggest issue is that the addressing used in the code is all based on values stored in the ROM and RAM in the sections that contain no data on the BIN dumps.

Funny you say that you the 623 BIN will not work with INPA, try the 623 UK MAP that is in the dropbox, it was the file that came off the ECU I am using and is the stock tune from an E34 525.
I am sure it worked with INPA. :?:

I am just using the 3d printers hotbed to really accurately measure the resistance of the temperature sensors I have to hand.
I need to order another M50 coolant sensor as the only one I have to hand is on the car.

I'm planning to use these as transfer functions on the data logger but it struck me that they must be functions in the ECU as well. The processor is not powerful enough at floating point math to do even a linear calculation on the fly for all of these sensors without a waste of processing time.
There has to be a TPS function, a IAT function, a CLT function and a lambda sensor function.

Will post what I get out of it and then go looking for the functions that match the results.
olafu
Posts: 186
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Post by olafu »

RAM dump from 0x1A to 0xFF matches, if i do "dummy table" and watch those values with tracing, or watch those values with INPA.
So, "descriptors" are pointed directly from register file. If i take RAM dump from 0xD0, it is engine rpm and so on. That is nothing new, because i was watched those values with dummy tables before i get INPA, but it clears some darkness :)

INPA RAM dump polls selected RAM-addresses continuously and shows their contents exactly right, but by tracing "dummy tables" is definitely fastest way to read those register values, but it is not very accurate... It's like comparing digital multimeter to analog multimeter :D

Some information what i was noted of those registers:
0x26 = TPS_SENSOR RAW?
0x27 = TEMP_SENSOR RAW??**
46-47 = 16BIT AIR_MASS?

** Seems like 0x27 is shared for IAT and CLT..? Needs more testing.
Last edited by olafu on Tue Jan 30, 2018 1:17 pm, edited 1 time in total.
Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech »

Mother**** Beep beep.

Just discovered I have had the wrong air temperature sensor in the E30 all along. :roll:

I have 2 kinds on test atm, one I removed from a M50B20 manifold a few hours ago which is a threaded spike shaped sensor, also on the heat bed is a push in sensor in a plastic cage.
They have very different resistance curves and having just checked the part numbers the caged one is the later siemens ECU sensor.

Needless to say I have the Siemens temp sensor in the E30 at the moment. :x
The difference is about 4k ohms @ 20 degrees.
The correct spike shaped sensor is actually very similar in temp coefficient to the M20 coolant sensor so one of those could get you through in a pinch!

Anyone think this may be the cause of some of the tuning issues I have been having?
I expect the ECU thinks the air temp is -50degC.
Last edited by Hairyscreech on Tue Jan 30, 2018 1:44 pm, edited 1 time in total.
Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech »

olafu wrote:RAM dump from 0x1A to 0xFF matches, if i do "dummy table" and watch those values with tracing, or watch those values with INPA.
So, "descriptors" are pointed directly from register file. If i take RAM dump from 0xD0, it is engine rpm and so on. That is nothing new, because i was watched those values with dummy tables before i get INPA, but it clears some darkness :)

INPA RAM dump polls selected RAM-addresses continuously and shows their contents exactly right, but by tracing "dummy tables" is definitely fastest way to read those register values, but it is not very accurate... It's like comparing digital multimeter to analog multimeter :D

Some information what i was noted of those registers:
0x26 = TPS_SENSOR RAW?
0x27 = TEMP_SENSOR RAW??**
46-47 = 16BIT AIR_MASS?

** Seems like 0x27 is shared for IAT and CLT..? Needs more testing.
Yes, the descriptors do actually single out the hex address of the register the values are stored in.
Some of them are going to be raw values from the analogue-digital converters in the microprocessor. The ECU will need to take the raw values from the ADC and then translate them using the transfer functions into the usable values.
Mostly as the ADC is linear with voltage but a lot of the sensors do not behave in a linear fashion.
Some digging in the INPA files might actually be revealing....

One of the key things that should be in the RAM dump is a register that is holding an offset for the ECU subroutines.
This offset is the one that will be used to reference the tables in the data.
So being able to find that will mean we can see which routines are calling which tables.

I would be interested to see what you got out of the RAM. I can probably swing IDA well enough to patch that RAM data into a BIN and maybe get the functions to point to the data tables.

How do you mean "tracing dummy tables"? I am not sure I understand the method you suggest.
olafu
Posts: 186
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Post by olafu »

Hairyscreech wrote:How do you mean "tracing dummy tables"? I am not sure I understand the method you suggest.
I choose a some table, what is in use at all times, and doesn't do anything. Like 0xD7D4. It takes 57 bytes. So, i can put "dummy table" which is maximum 57 bytes long: XX 01 01 XX 1A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 01 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 and that produces 1x26 table. (* i can't remember if it works exactly like that, but that's as an example)

XX's describes the register addresses to be investigated. So, you can watch two register values, other one is very rough, example like 0-128 or 128-255 and second axis is divided to several parts , so it's rough, but it can be used like multimeter. FF can be used to fill unused byte(s). You just need to make that table and two scalars in XDF, one is first axis descriptor and other one is second axis descriptor... I have not found any side effects yet
:lol:
Last edited by olafu on Tue Jan 30, 2018 2:24 pm, edited 1 time in total.
Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech »

I see what you mean, I gather that it is not possible to see the exact value of the data in the register though?
For the addressing I need to find the exact values at any point in time.

I think I need to get the microprocessor manual out again, there will be some useful info in the ADC section I think.
olafu
Posts: 186
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Post by olafu »

If i was understood right that basic principle: ADC is multiplexed, only one channel can be in use at time. Control register (02H) is used to point one of those channels and transmit the command to start conversion, and some other information. Result is stored to 03H and partially also in 02H.
Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech »

Just did some checking and what we could realy do with is a snapshot of the values held in the RAM from 0-1000h.

This is going to be where all the action is. This was missing from the last dumps you took and should be what helps point out the tables each function uses.

On the A2D side of things I expect you are correct (without checking) what I am curious about is how many bits the A2D has available to produce values and what its upper/lower voltage limits are.

I finished the sensor measurements off on the sensors I have right now, the file is in the dropbox.
I have a couple of new sensors on order so will repeat with a new M50 coolant and new M50 air sensor once they arrive.

I have been looking at the functions section of the code today and marked out a few things which I will graph up. It might be worth setting some of these things high/low and seeing if we get DTC codes or obvious responses that show what they do.
olafu
Posts: 186
Joined: Tue Jul 26, 2016 12:35 pm
Location: Finland

Post by olafu »

They was missing, but reason can be only there is nothing action in that area in external ram chip. Those dumps was pulled out from real external ram chip, what is taken out from fully working system by suddenly disabling write ability. Nothing was changed, chip was freezed in it's state, moved to reader and then readed it's contents out.

So, external sram chip is not used as program ram.

A/D converter full resolution is 10 bit, but i think there is only MAF or nothing what uses full capacity. MAF transfer table is 1x256, so it seems it is 8bit.
Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech »

Nice to see the A2D is 10 Bit, the ATmega2560 on the arduino is also 10Bit so one I figure out some more of the code needed then I might actually be able to have it do the MAF translation the same as the Motronic.
At the moment it is set up to use a lookup table with the MAF transfer function converted into the 0-5v/0-1023 range of the 10bit A2D, should give a very comparable MAF result.

I see what you mean about the external RAM, yes if it was in there then it should have been in that dump.

I just checked the data sheets and it looks like it might be in internal RAM, which I think INPA can read out as I am sure I have asked it for bits 0-100 before and it did spit the data out.

Looking at the sheets, external RAM begins at 200h (bit 512 onward) so we can assume 200h-1000h are just not used for anything or they would be in that dump you took.

The key ones seems to be 0-19h (bytes 0-25) as they are the register data and 1A-1FFh (bytes 26-511) as they are the internal RAM.
These two should be where the goods are hidden. (I expect mostly at the first half of the internal RAM.

Having just looked at it all I now remember that this was the conclusion I reached when I first looked at the RAM dumps before Christmas.
Has to be in the internal RAM or it would be an unnecessary burden on the processor to access the external RAM all the time for basic calculations due to the load/store architecture
https://en.wikipedia.org/wiki/Register_ ... chitecture
Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech »

I have just put a completed temperature sensor sheet into the dropbox.

It has M20, M50 and S50B32 Coolant sensor data and M50 and M52 air temp sensor data on it.

I ordered a couple of different ones and oddly the only one that didn't measure right is the Febi Bilstein sensor. It claims to be an M50 part number but the resistance matches the Siemens ECU on the S50B32 :?: :roll:

General observations from this are:
- M20 and M50 Coolant sensor for the ECU is nearly identical.
- Cheap Intermotor or FAI sensors are no problem, Febi Bilstein ones might be a problem? (Ironic?)
- The thermistor used for the air temp is the same as the coolant temp, in a pinch they could be interchanged and the car would barely notice.
- The ECU does not actually measure the resistance/voltage of the sensor but there is actually a voltage divider arrangement of resistors with the temp sensor forming one leg. The ECU has the voltage on the non sensor leg fed into the A2D converter. You should only ever see ~4-0.5v with a working connected circuit, if you unplug the sensor then you will see 5v due to an open circuit.

I took a look at the High Res photos I have of the ECU boards and identified the resistor that forms the voltage divider with the two sensors.
This meant I could calculate the expected voltages the ECU will see from the sensor at various temperatures.
The formula for that is on the spread sheet.
A mathematical function for the curve of the sensors resistance is on the sheet as well.

These results should be about as accurate as any out there on the internet, the sensors were held down to the heat bed of the 3D printer and the temp was set, once the printer read the correct temperature the heat was held until the sensors stabilized at each point, these measurements were repeatable within 5 Ohms.

This will form the basis of the sensor readings on the Arduino so I had to get it right or it would have been a waste of time.

https://www.dropbox.com/s/xjf35hb1blznb ... .xlsx?dl=0
Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech »

To add to that I have been taking a look at the possible transfer functions between the MAF table and the start of the ECU maps.

I think I have puzzled out where they all start and end, and that has parity across all the M3.3 versions, 413, 404 and M3 Euro so they are definitely the boundaries of each function.

We just have to work out what the hell each one does.

I put a new tab in the spread sheet with the relevant transfer functions graphed out and I have colour coded them temporarily to help show what I think are the boundaries, if anyone can see any correction needed then let me know and I will take a look.

The easiest but least accurate way to work these out may be to 00 or FF them out and see what goes on the fritz.

I was looking at some of the graphs and I am wondering if one of them is the missing correlation between TPS and simulated load for the MAF failure routine?

I did some work on the TPS and it is a simple voltage divide in a box. It should be nearly totally liner so I doubt it has a transfer function in the ECU. The one I measured here did not work too linear bu it might just be the old crappy sensor or may bad measurements.
I will keep on with this one as it affects the data logger.

https://www.dropbox.com/s/ddnn23r85d5rt ... .xlsx?dl=0
Evil
Posts: 140
Joined: Tue Jul 18, 2017 12:53 pm
Location: France

Post by Evil »

Very interesting! Thanks for these updates.
Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech »

I booked a couple of days off to get a break and play with the E30, spent a few days bashing my head against INPA on the new laptop and just gave up and used the old brick to get what I needed.

Main point of this one is that INPA did read out the data in the RAM from 0x00 to 0xFF.
I grabbed it in the ECU on and not running and Idle conditions, this data is not actually from the RAM chip but should actually be the data from the internal registers of the Microcontroller.

If it is the register data then it might allow full disassembly of the ECU code.

I will report back to see what I find.

Also I remember the fix for INPA not connecting to a non-EWS version of the 413.
There are 2 files in the dropbox now that patch the EWS issue, they need to go into the INPA folder and the EDIABAS folder. Should be obvious where as the folder is full of files with the same extensions. I can check later the exact location but they are just new ECU definition files.
Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech »

Almost forgot - I swapped the air temp sensor onto the car and it seems to have improved things quite a bit.
I measured the Temp sensor on the car and it was the higher resistance one.
With a bit of online searching it was suggested that the correct M50 sensor is actually the same/similar to the E30 temp sensor.

Right now I am using the lower resistance E30 sensor but would appreciate if someone who has a correctly running car could check their temp sensor.
M3.1 -> M3.3.1. should not matter which as long as it is an M50.
Would be nice to put this one to bed and be sure of the correct temp sensor.

It has made a mess of any tuning I did before and has totally ruined the acceleration adjustments I had made so back to the base mapping stage again... :roll:


I just put the extra RAM data into a disassembly, it looks very promising so far but there is still a load of data missing from 0xFF to 0x1000 that needs to be added to complete the job.
I am going to try to gather that with INPA as soon as I can.

The first thing that I have found is that the locations 0x68, 0x6A, 0x6C and 0x6E hold the references for each of the data sections.
I have marked these in the disassembly and it seems to point out which functions are for diagnostic, calibration etc, etc.
Evil
Posts: 140
Joined: Tue Jul 18, 2017 12:53 pm
Location: France

Post by Evil »

For the air temp sensor I can check on mine if you want, what do you need exactly?
Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech »

Its the coolant sensor that's the big issue.

Take a look at the sheet of temp sensor resistances, one measures ~6300 Ohms at 20 degrees C (870 Ohms @ 80 Deg C) and the other ~2500 Ohms at 20 Deg C (and 370 Ohms @80 Deg C).

One of them is not correct but they both claim to be the right sensors.

If you check what you have at cold and running temp (and if possible a reasonable guess at the temperatures) then I can compare to the measured values.
The more exact on the Temp and Resistance the better but the two resistances are so distinct I should be able to tell just from that.
Evil
Posts: 140
Joined: Tue Jul 18, 2017 12:53 pm
Location: France

Post by Evil »

In my french repair manual, for both air and water sensor, they say 2200/2700ohms @20°C and 300/370ohms @80°C, so your second sensor seems To have the good values. I remember I tested both on my car this summer @20°C and values were in the range. The water sensor was in the range too at operating temp (I have a 80°C thermostat) but I did no other test for air sensor.
Hope this helps, if any doubt I can test it again on the car 😉
Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech »

Thanks, Should be enough, just needed a solid confirmation.

In that case it looks like the M50 and M20 coolant sensor only differ by the thread on the outside of the sensor, the M20 is M12 and the M50 is M14.
Both sensors should work on the car just fine.

The ECU has a 1110 Ohm resistor to complete the voltage divider for both the Air temp and Coolant Temp sensors.

Just a generally important thing to note then when buying new sensors, have to check the resistance of the sensor before fitting them as some supplied as M50 sensors are not, even by the big OEM manufacturers, even when buying by BMW part number... :shock:

Disassembly wise I have found a few little bits so far:
- The references we noticed down at 0xFE14 -> 0xFE1B are important, this is where the ECU fetches the start of each section from. I found some code that begins at 0x2EDB (or ROM_2EDB for IDA users) which appears to start checking values from 0xFE23 backwards through those section IDs.

I need to do some more checking on that but it looks pretty solid at the moment.

I would be curious to see if someone could move the table of tables further down the code to a blank area and then update the reference to see if the ECU runs ok?
If so then we can move things around in the code at our leisure should we need more space for a table or want to patch the code base later on.
Hairyscreech
Posts: 196
Joined: Tue Jun 20, 2017 3:19 am

Post by Hairyscreech »

I took a look at the missing factor for D7 last night and I think the reason I struggled to find a linear factor for it before is that there is not one.

I believe this is simply the raw 256 bit values from the A2D converter. I get that the A2D is 10bit and would then have to convert into 8bit somewhere in the code, that would simply be the 0-1023 converted to 0-255.

The A2D works from 0-5v, with 255 values available that's 0.019531V/value.
The sensor is not liner but using the calculations I put on the "M5x temp sensors" sheet in the dropbox and working out the voltages expected at the A2D based on the voltage divider layout and using this V/value I built a table of temperature Vs D7 value.
I found that the a 0v value would be ~-40 DegC and a 5v value ~215 DegC.
While the sensor would never actually measure a full 0v or 5v due to the way it works and should never see these kind of temperatures is gave me the boundaries.

I have updated the sheet in the dropbox to show this working so if anyone wants to double check it then feel free, the more eyes checking these things the better.

Plugging the resulting numbers into the D7 based tables gives some sensible results:
The "coolant temp correction for acceleration" table has the following:
Raw value - 49 103 143 175
Temp DegC - 0 30 50 66

Running the car from cold results in a steady climb up that table and it sits in the 66+ cell once 3/4 warm. (E30 temp gauge so not electrically damped like an E36).

I am going to put the values into some of the unknown D7 tables and see what temperatures it suggests, it will help confirm if the theory is correct and maybe what those tables are. :?:
Evil
Posts: 140
Joined: Tue Jul 18, 2017 12:53 pm
Location: France

Post by Evil »

Interesting!
I noticed that last t° cell on ECT related tables (with formula x*0.75-48) was reached way before the engine had reached this t°.
E.G on ECT fuel correction, the 80°C cell is hit when engine is at about 55/60°C in the radiator inlet pipe (t° in engine must be a little higher, I have a 80°C thermostat with à 2/3mm purge hole, and a VDO gauge with sensor on the radiator inlet pipe, so I have a little coolant circulation even under operating temp). This would make sense with the 66°C you have for this table.
Post Reply