E39 540i Me7.2 DME Tuning shenanigans and findings

[zarboz]

Was there anything in particular you were looking for in the ECU, or just general tips are tricks?
1000 pages of that PDF isn't light reading, but just going for bits one by one should be more manageable.

The few last things to iron out for me were hard limiter and then I’m on kind of a side mission looking for the SY_WFS flag

I have on the github a projects page and I do a decent job of keeping tabs of where I am and where I want to be going


I think the Xdf is about 70% complete as far as robustness is involved
It’s 98% complete for accuracy (5a01.smalltables)

I want to be able to offer Eskonf patches on the fly
I want to get more explaining on the fueling items
I need to update 5a01 and 6901/6902 mapping files to all have the same contents



I honestly bought the manual because some of the vmax and nmax functions were so different from other sheets available

And I wanted to learn about the turbo function specifically in our dme

[dme88]

- - - Updated - - -


using K+Dcan cable and Galletto 1260 to get the 64kb files


The files are year specific it looks like you have a 96... which would have the m5.2 dme (there is an XDF uploaded for that! It is rather robust and should be able to get you "tuned up" )

Unless your 96 is converted to a me7.2 somehow

Nice! However, none of the XDF for ME 5.2 opens in any Tuner Pro since 2011...

This XDF seems to open at least: https://drive.google.com/file/d/0B3E...pHNjhETUU/view

[zarboz]

Nice! However, none of the XDF for ME 5.2 opens in any Tuner Pro since 2011...

This XDF seems to open at least: https://drive.google.com/file/d/0B3E...pHNjhETUU/view

I have an OLS file i can convert into a tunerpro file for you

https://drive.google.com/open?id=1p4...6iPUiCj2if2_nP

Here is the OLS converted to a XDF marked me52.xdf

and then there is an XDF I have that does open in the new tuner pro

It is still in german but its useful :"D

[zarboz]

Doing some testing now with a user who has an 88C thermostat to get rid of their check engine light

if anyone else is interested I will post steps and results as they are available

[blackknight530i]

Doing some testing now with a user who has an 88C thermostat to get rid of their check engine light

if anyone else is interested I will post steps and results as they are available

I'm interested. I have a 540iA that needs a thermostat and I've had an 88*C one sitting on a shelf waiting for this mod. Just to be sure though, have you had any issues with people trying any of your mods and having engine failsafe problems? I did the DTC delete for the DM-TL on a customer's 2000 740i6 with M5 cluster mod (already applied and was working) and he got an engine failsafe message, even after doing the throttle adaptation reset procedure. I did the checksum correction using Ultimo, but I can't figure out what else would have caused it.The only change that was made was the DTC suppression and checksum correction.

[geargrinder]

Bryan you know you blew your entire first post away when you "updated it" to talk about ESKONF?

The thread kind of makes no sense now as the OP is just an ESKONF-only post.

[zarboz]

I'm interested. I have a 540iA that needs a thermostat and I've had an 88*C one sitting on a shelf waiting for this mod. Just to be sure though, have you had any issues with people trying any of your mods and having engine failsafe problems? I did the DTC delete for the DM-TL on a customer's 2000 740i6 with M5 cluster mod (already applied and was working) and he got an engine failsafe message, even after doing the throttle adaptation reset procedure. I did the checksum correction using Ultimo, but I can't figure out what else would have caused it.The only change that was made was the DTC suppression and checksum correction.

I do want to offer my apologies for that I should have made more clear during our email discourse that the file was for testing only.

Since that point I have obtained the full function sheet and with it gained a much better and deeper grasp of the software that is running on our DME. This has led to much higher rates of "first try success". Also I posted about ESKONF because of our conversation initially about disabling the DMTL/DMTL-H/LDP individually off of one master binary. The function sheet hasn't led me to clues about automatic vs manual bytes quite yet but I am still reading 1k plus pages

The mods that are posted on the github page's wiki are ones I would consider "tried and true" either tested by myself or another of the 2 contributors (one owns a 00 540i as well and the other an 03 both manual vehicles)

As soon as i get feedback from someone trying a test with success that is repeatable to another individual I post the documented steps of the mod on the wiki page with a brief explanation of what to edit and why.

I also have enabled issue tracking on that page. I know most folks won't setup a user account on another site but if they do ... they can file issues with my xdf / mods (things just not working as intended) and I would be able to interact with that issue on a 1:1 basis in order to ensure that the problem is resolved

Bryan you know you blew your entire first post away when you "updated it" to talk about ESKONF?

The thread kind of makes no sense now as the OP is just an ESKONF-only post.

I changed the layout so the github links are in huge text and above the eskonf information now

[blackknight530i]

I do want to offer my apologies for that I should have made more clear during our email discourse that the file was for testing only.

Since that point I have obtained the full function sheet and with it gained a much better and deeper grasp of the software that is running on our DME. This has led to much higher rates of "first try success". Also I posted about ESKONF because of our conversation initially about disabling the DMTL/DMTL-H/LDP individually off of one master binary. The function sheet hasn't led me to clues about automatic vs manual bytes quite yet but I am still reading 1k plus pages

The mods that are posted on the github page's wiki are ones I would consider "tried and true" either tested by myself or another of the 2 contributors (one owns a 00 540i as well and the other an 03 both manual vehicles)

As soon as i get feedback from someone trying a test with success that is repeatable to another individual I post the documented steps of the mod on the wiki page with a brief explanation of what to edit and why.

I also have enabled issue tracking on that page. I know most folks won't setup a user account on another site but if they do ... they can file issues with my xdf / mods (things just not working as intended) and I would be able to interact with that issue on a 1:1 basis in order to ensure that the problem is resolved




I changed the layout so the github links are in huge text and above the eskonf information now

Ok, so I guess I'm still a bit confused as to how to disable DM-TL and use LDP instead. To be honest, that's all I want to do. I have a 6902 tune that when I load it into the 6901.6902.ME72.xdf, shows CWDMTL under the project configuration and the description says, "Activate code word DMTL diagnosis (EURO coding), CD .. = 0 -> no slide". I made the assumption that I should set that to 0, which was then checksum corrected. Granted, I only checksum corrected once and not twice as JC (geargrinder) has suggested, but the fact that the car started, I'm not 100% sure that it's a checksum error. The only mod I made was to CWDMTL and checksum corrected a tune that already had the M5 cluster and cruisefix mods and had been known working (was from a patched 0da from TerraPhantm and flashed using WinKFP). If I'm doing it wrong, please enlighten me and let me know what I need to do differently to make it work. I can't afford to keep sending the DME back to the customer and having him test it.

Also, I realize that you're only posting this stuff as "experimental", but I don't have the type of car this is going into local to be able to test. I've got more people wanting to get some M5 clusters that have either 2000 540i6s or 99-2001 740i6s and I'm just hoping I can get a tune working so I can work with them.

[MotorMouth93]

Yes you likely need to do the checksum correction multiple times. Do it until Ultimo comes back saying zero corrections needed.

Someone correct me if I’m wrong, but I’ve heard that a bad checksum in the 64kb binary will still run but the SES light will be on.

[blackknight530i]

Ok, so I just saved the file after doing the checksum the first time, then compared it to not only the previous file, but also the original file and it now shows 0 corrections, whereas before it said 1 correction. To me it seems like that's only a check to make sure that the Ultimo tool did what it was supposed to do the first time, meaning it should have been correct, but maybe I am misunderstanding. Either way, I loaded the file that was created after the second check and I guess I'll have the customer test it out.

[MotorMouth93]

If it showed zero corrections then that’s not the issue. In my case ultimo didn’t show 0 corrections until the 3rd run.

[blackknight530i]

The first one that I did before showed 1 correction. Then I did it again and got 0.

Sent from my SM-G965U using Tapatalk

[zarboz]

The first one that I did before showed 1 correction. Then I did it again and got 0.

Sent from my SM-G965U using Tapatalk

I filed an issue on this and will investigate:
https://github.com/zarboz/BMW-XDFs/issues/2


I need to reword that DMTL line item it is the euro flag that merely stops diagnosis patterns and programs it would not be beneficial as the DMTL program itself is important

Basically you need to edit the ESKONF for the map file is this car a DMTL-h or a DMTL car going to LDP ?



I deleted the Eksonf stuff in the OP as it was regarded to be confusing



BUT let me see if i can explain it here:

Eksonf is set by an array of bits that is converted to a byte (1011011 taht becomes a hex character)


11 = no diagnosis
00 = installed and diagnose



This should be the eskonf byte order pulled from a 2001 me7.2

Byte 0 = 00 00 00 00 // or 00 ( TEV | EV6 | EV3 | EV1)
Byte 1 = 11 00 00 11 // or C3 (DMTLH* | KFK | EV8 | ??) ( Could also appear as 00 00 00 11 == 03 for cars equipped with DMTL heater)
Byte 2 = 00 10 00 11 // or 23 (LUE(A) | EKP | NWSE1 | KKU )
Byte 3 = 11 11 00 11 // or F3 ( NC | NC | SLP | ??)

Byte 4 = 00 11 00 00 // or 30 ( EV7 | DMTLH/MIL*| EV2 | EV4) (could also appear as 00 00 00 00 == 00 for cars equipped with DMTL heater)
Byte 5 = 00 11 00 00 // or 30 (LDP/TMV | LDR | EV4 | SLV) (could also be 11 11 00 00 == F0 for cars equipped with DMTL heater)
Byte 6 = 11 11 11 00 // or F3 ( KOS | START | NWSE2 | ?? )
byte 7 = 11 11 11 00 // or FC ( NC | NC | ?? | TDMP )


00 C3 23 F3 30 30 F3 FC is the eskonf for a 2001 DMTL car

This may look super intimidating but like i said

11 == on
00 == off

So go to Byte 2 and find the DMTL column and turn it off

The Eskonf for my 2000 LDP equipped car looks like this:

00 C3 23 F3 30 30 F3 FF


Effectively what you are doing is changing byte 7 to disable TDMP and that is it for that car


TLDR:
Get a 64kb dump via Galletto and then:

Search: 00 C3 23 F3 00 30 F3 FC
replace: 00 C3 23 F3 30 30 F3 FF

If you cant find 00 C3 23 F3 30 30 F3 FC

Then search instead for: 00 C3 23 F3

00 C3 23 F3 -- seems to be stock on all these motors no matter what and will help you find the last 3 bytes of configuration data to manipulate.


ALL THIS DOES IS TELL THE CAR THAT DMTL IS NOT PLUGGED IN LDP IS PLUGGED IN. I will do a test in the next week with that euro DMTL flag to see if i can replicate your circumstances for now I will file an issue on that particular topic on your behalf


EV == * injector
EKP == fuel pump
TEV == tank bleed valve
LUE == Electric engine fan
NWSE * ==Power stage camshaft control
KKU == changeover valve fuel circuit
MIL == external fault lamp
LDR == changeover valve boost pressure
KOS == power amplifier air conditioning compressor
KFK == map cooling / electr. thermostat
SLV == secondary air valve
SLP == secondary air pump
START == power stage start relay
LDP == leak diagnosis pump
TDMV == DM-TL module switching valve
TDMP == DM-TL module pump



Using this information to arm yourself you SHOULD be able to configure a 64kb file from a 2003 car to run a 2000 car with no CEL and function as expected

ALSO to note in 6901/2 files CWDDMTL shows as 50
in 5a01/2 cars this shows as 00

That is why i left the slider intact and it is also described as a "euro coding option" in the data sheet manual

[zarboz]

The first one that I did before showed 1 correction. Then I did it again and got 0.

Sent from my SM-G965U using Tapatalk

I added some on the fly patches for ESKONF into the 6901/6902 XDF using dumps from an 01 and 03 and 00 and 99 car to check ESKONF configuration for output setups

Basically using the patches turn off the output for that item i have confirmed this in the past 30 minutes on my car it will throw check engine light for hardware I dont have when using these ESKONF patches (IE if i patch for DMTL i get a check engine for it not being plugged in)



I have added in the comments of the patches they are purely for testing and until I get a report back i won't know whether or not they work 100% and as I do not own an m5 cluster I am not able to test that portion



I have also fixed the CWDMTL offset and will test it tomorrow when its not snowing will report back here if it makes car go into limp mode to toggle it between 1 and 0

[zarboz]

Patches added to convert your 6902/1 binary to LDP/DMTL/DMTLH and patch added to delete electric thermostat on the fly (for you 88c guys)

[geargrinder]

Bryan what you want to learn to use is "Flags" with "masks" in TunerPro. That's the way to deal with bit flags like that. At least it works well for "11" to "00". It doesn't work as well if there are "10" or "01" values.

[zarboz]

Bryan what you want to learn to use is "Flags" with "masks" in TunerPro. That's the way to deal with bit flags like that. At least it works well for "11" to "00". It doesn't work as well if there are "10" or "01" values.

I will look into that I was wondering how to display it as the binary bit count rather than a hexadecimal and decided a couple patches would be easiest; but with this method a user could toggle whatever items they want on and off I really like that


Not sure though because one of the lines does contain a 10 bit... I will dig around for more tuner pro documentation to see about this.

[harrydebest]

Great work Zarboz!!

Any chance you're able to update the 5A01 XDF with all the features present in 6901 and 6902? I've got access to a 2003 Euro 540iA, willing to experiment!

[zarboz]

The first one that I did before showed 1 correction. Then I did it again and got 0.

Sent from my SM-G965U using Tapatalk

DMTL byte offset fixed and tested == working

ESKONF patches added for you to make a 64kb binary fitup to whatever emisisons system is plugged in (still requires toggling of DMTL switch 0/1 depending on setup)

Great work Zarboz!!

Any chance you're able to update the 5A01 XDF with all the features present in 6901 and 6902? I've got access to a 2003 Euro 540iA, willing to experiment!

Sure its on my list of "Todo" this week to ensure versioning as as close as possible between all of them


I wonder if yours has the small tables or big tables for fuel injection (99 year had larger fuel injection tables)

[geargrinder]

Zarb0zyan:

I havent' had time to say so, but making the English F/R available has been a great asset to anybody geekydorkynerdy enough to want to dig into these things. Thanks for that.

Based on catching up on my reading just a little... Let me help you out with better way to communicate the ESKONF data.

First some setup and further context:

The ESKCONF block only pertains to devices that are driven off of 2 or 3 specific "power stage" IC's in the ECU.

Basically these 2 or 3 chips are used to drive some of the things that need 'light' current delivery, but more than purely logic-level (aka near-zero current).
Primarily either 'lightweight' solenoids, or, just driving relays that drive other more heavy-duty devices to relieve the current.

However the ECU uses a whole bunch of IC's to drive devices. That is one reason we don't see more devices on this map. There are a number of other chips in the ECU driving devices, and if you're looking for a device that isn't configured with ESKONF then it likely is driven by one of those.

So don't expect to find all 'enable/disable' hardware functions in ESKONF.

And another tricky/odd bit is that in the doc we have, Bosch/BMW don't define the pins for one entire chip. That is whatever is "on" Byte 9 in my table below. The first 8 bytes correlate to 2 Bosch CJ920 chips and sure enough you can find those on the board and would be able to pin-trace them out if you were so inclined. The 3rd chip is supposed to be a Bosch CJ420 (heh - smoke 'em if you got 'em boys), but there appear to possibly be 2 CJ420's on the PCB, so... Odd. It may be that Bosch and BMW are obfuscating some secrets (like they hide a lot of the EWS workings...) but who knows. So we don't know what this CJ420 does exactly... and... how the second CJ420 (#bong.rip.chip) is configured... well we dont know that yet either.

Finally, and more techno-pedantically these bits, if interpreted strictly, dont actually disable the pins, but just disable the diagnosis functions. Now maybe the logic will in fact turn them off if the diag is off, and moreover probably for most people that's all they give a crap about, but, in some cases, it may be that even if these bits are turned off (well... "on" actually but 'turn off diagnosis') then the ECU will still run the logic to activate those pins, and some routine will in fact be turning it on/off as it thinks it is supposed to.... it just won't be diagnosing whether the pin is shorted out or malfunctioning etc.

On to the table...

Notes for interpretation:

1. For layman readability, this is all "1-based index" aka start counting at "1" like normal humans, and not "0" like programmers/computers do. That's why it looks different than the ugly stuff Zauerbratzen posted before.
2. "--" = in F/R if it says "N/C" "--" to keep table more readable/less cluttered. There are literally no output pins on the IC's that correspond to these bit-locations so they will never do anything.
3. unused = In F/R they show "?" but most likely just means "available for future revisions" or "unused pin" (vs no-pin-at-all = NC, very different).
4. Although some of us recognize German abbrevs for many things now... I have translated the abbreviations to what commonly used US-enthusiast/tech terms or abbrevs are.
5. Note that a number of 'systems' have multiple devices - i.e. SAI has both the pump and the valve, DMTL has both the valve and the pump (AND the purge valve on the engine actually), etc.
6. ??? = pins that appear to be typically used but not defined in F/R. As above - Byte 9 is a mystery, corresponds to a separate IC but none of the connections are defined for us. The "Example" is taken directly from the F/R, and all the Byte-9 'mystery' connections are turned on, oddly, where-as all other "mystery connections" are turned off... hmmm... probably means its important then...

BMW ME7.2 ESKONF Coding, Per F/R:

	Bits 7&8	Bits 5&6	Bits 3&4	Bits 1&2	Example
Byte 1	Evap purge valve	Injector 6	Injector 3	Injector 1	00 00 00 00
Byte 2	unused or (DMTL-H)*	MAP thermostat	Injector 8	unused	11 00 00 11
Byte 3	Electric fan	Fuel pump	VANOS Solenoid 1	3/2 changeover valve FPR	00 10 00 11
Byte 4	--	--	SAI pump	unused	11 11 00 11
Byte 5	Injector 7	DMTL-H (or MiL)*	Injector 2	Injector 4	00 00 00 00
Byte 6	LDP or DMTL valve	Wastegate	Injector 5	SAI valve	00 11 00 00
Byte 7	AC compressor	Starter relay	VANOS Solenoid 2	unused	00 00 00 11
Byte 8	--	--	unused	DMTL pump	11 11 11 11
Byte 9	???	???	???	???	00 00 00 00

* = for hardwired DMTL MiL (check engine) light, on vehicles without a CAN instrument cluster - aka no BMW's, so this does not apply
(F/R says this is for "Morgan" so there must be some Morgan that runs a BMW-style ME7 ECU!?... would make sense though that the Morgan has no instrument cluster therefore needs a hard-wired MiL)

Bit-pair Coding:

What do the 2 bits mean?

The first bit is a "OBD diagnosis" flag, or whether that device triggers an OBD error aka it might throw a 'BMW' error but not show up on the OBD scan.
(This, kiddies, is why Cantankerous Ol' Granpa GG always says "Use a real BMW scanner and not that OBD piece of crap!!")

The second bit German->English translates to 'healing test', and its in practice slightly more complicated than this I think, but for practical purposes we can consider it "BMW diagnosis".

So... practically, consider it to be:

	First Bit	Second Bit
Bit =0	OBD errors diagnosed	BMW errors diagnosed
Bit = 1	OBD diag disabled	BMW diag disabled

This is why "00" = fully enabled OBD diagnosis, and "11" = fully disabled diagnosis

Have fun, geeks.

[zarboz]

Zarb0zyan:

I havent' had time to say so, but making the English F/R available has been a great asset to anybody geekydorkynerdy enough to want to dig into these things. Thanks for that.

Based on catching up on my reading just a little... Let me help you out with better way to communicate the ESKONF data.

First some setup and further context:

The ESKCONF block only pertains to devices that are driven off of 2 or 3 specific "power stage" IC's in the ECU.

Basically these 2 or 3 chips are used to drive some of the things that need 'light' current delivery, but more than purely logic-level (aka near-zero current).
Primarily either 'lightweight' solenoids, or, just driving relays that drive other more heavy-duty devices to relieve the current.

However the ECU uses a whole bunch of IC's to drive devices. That is one reason we don't see more devices on this map. There are a number of other chips in the ECU driving devices, and if you're looking for a device that isn't configured with ESKONF then it likely is driven by one of those.

So don't expect to find all 'enable/disable' hardware functions in ESKONF.

And another tricky/odd bit is that in the doc we have, Bosch/BMW don't define the pins for one entire chip. That is whatever is "on" Byte 9 in my table below. The first 8 bytes correlate to 2 Bosch CJ920 chips and sure enough you can find those on the board and would be able to pin-trace them out if you were so inclined. The 3rd chip is supposed to be a Bosch CJ420 (heh - smoke 'em if you got 'em boys), but there appear to possibly be 2 CJ420's on the PCB, so... Odd. It may be that Bosch and BMW are obfuscating some secrets (like they hide a lot of the EWS workings...) but who knows. So we don't know what this CJ420 does exactly... and... how the second CJ420 (#bong.rip.chip) is configured... well we dont know that yet either.

Finally, and more techno-pedantically these bits, if interpreted strictly, dont actually disable the pins, but just disable the diagnosis functions. Now maybe the logic will in fact turn them off if the diag is off, and moreover probably for most people that's all they give a crap about, but, in some cases, it may be that even if these bits are turned off (well... "on" actually but 'turn off diagnosis') then the ECU will still run the logic to activate those pins, and some routine will in fact be turning it on/off as it thinks it is supposed to.... it just won't be diagnosing whether the pin is shorted out or malfunctioning etc.

On to the table...

Notes for interpretation:

1. For layman readability, this is all "1-based index" aka start counting at "1" like normal humans, and not "0" like programmers/computers do. That's why it looks different than the ugly stuff Zauerbratzen posted before.
2. In F/R if it says "N/C" aka no-connection, I have shown "--" to keep table more readable/less cluttered. There are literally no output pins on the IC's that correspond to these bit-locations so they will never do anything.
3. In F/R if it says "?" then I have left that... because... who knows what that means.. but most likely just means "available for future revisions" or "unused pin" (vs no-pin-at-all = NC)
4. Although some of us recognize German abbrevs for many things now... I have translated the abbreviations to what commonly used US-enthusiast/tech terms or abbrevs are.
5. Note that a number of 'systems' have multiple devices - i.e. SAI has both the pump and the valve, DMTL has both the valve and the pump (AND the purge valve on the engine actually), etc.
6. As above - Byte 9 is a mystery, corresponds to a separate IC but none of the connections are defined for us. The "Example" is taken directly from the F/R, and all the Byte-9 'mystery' connections are turned on, oddly, where-as all other "mystery connections" are turned off... hmmm... probably means its important then...

BMW ME7.2 ESKONF Coding, Per F/R:

	Bits 7&8	Bits 5&6	Bits 3&4	Bits 1&2	Example
Byte 1	Evap purge valve	Injector 6	Injector 3	Injector 1	00 00 00 00
Byte 2	? or (DMTL-H)*	MAP thermostat	Injector 8	?	11 00 00 11
Byte 3	Electric fan	Fuel pump	VANOS Solenoid 1	3/2 changeover valve FPR	00 10 00 11
Byte 4	--	--	SAI pump	?	11 11 00 11
Byte 5	Injector 7	DMTL-H (or MiL)*	Injector 2	Injector 4	00 00 00 00
Byte 6	LDP or DMTL valve	Wastegate	Injector 5	SAI valve	00 11 00 00
Byte 7	AC compressor	Starter relay	VANOS Solenoid 2	?	00 00 00 11
Byte 8	--	--	?	DMTL pump	11 11 11 11
Byte 9	?	?	?	?	00 00 00 00

* = for hardwired DMTL MiL (check engine) light, on vehicles without a CAN instrument cluster - aka no BMW's, so this does not apply
(F/R says this is for "Morgan" so there must be some Morgan that runs a BMW-style ME7 ECU!?... would make sense though that the Morgan has no instrument cluster therefore needs a hard-wired MiL)

Bit-pair Coding:

What do the 2 bits mean?

The first bit is a "OBD diagnosis" flag, or whether that device triggers an OBD error aka it might throw a 'BMW' error but not show up on the OBD scan.
(This, kiddies, is why Cantankerous Ol' Granpa GG always says "Use a real BMW scanner and not that OBD piece of crap!!")

The second bit German->English translates to 'healing test', and its in practice slightly more complicated than this I think, but for practical purposes we can consider it "BMW diagnosis".

So... practically, consider it to be:

	First Bit	Second Bit
Bit =0	OBD errors diagnosed	BMW errors diagnosed
Bit = 1	OBD diag disabled	BMW diag disabled

This is why "00" = fully enabled OBD diagnosis, and "11" = fully disabled diagnosis

Have fun, geeks.

Going to transpose this into the github wiki if thats alright with you


https://github.com/zarboz/BMW-XDFs/w...y-GearGrinder)



Let me know if this is OK to keep up you are a little more eloquent with your writing than my technical self

[geargrinder]

Thats OK Bryan - couple notes on the formatting over there:

- note you have to escape the "*" for that weird Morgan-DMTL footnote as it gets turned into a bullet by the rudimentary GitHub text-parser. In some ways we could just leave both those cells "?" for BMW M62TU purposes (unless somebody wants to convert their M62TU to a no-cluster setup with a MiL light)
- Wastegate is one word (not WasteGate)
- I'm not sure I'd use the triple-or-quad "????" (unless thats a GitHub format problem...) on the cells in the first 8 bytes as it seems to imply a real mystery. Those arent' really a mystery, they appear to be "unused", so a minimal "?" is prob fine. If you want to use quad-???? on the Byte9 columns, that's prob appropriate because those really are an odd mystery and I suspect are hooked up to something. Either that or both of those CJ420's are handled completely elsewhere in the binaries.

[zarboz]

Thats OK Bryan - couple notes on the formatting over there:

- note you have to escape the "*" for that weird Morgan-DMTL footnote as it gets turned into a bullet by the rudimentary GitHub text-parser. In some ways we could just leave both those cells "?" for BMW M62TU purposes (unless somebody wants to convert their M62TU to a no-cluster setup with a MiL light)
- Wastegate is one word (not WasteGate)
- I'm not sure I'd use the triple-or-quad "????" (unless thats a GitHub format problem...) on the cells in the first 8 bytes as it seems to imply a real mystery. Those arent' really a mystery, they appear to be "unused", so a minimal "?" is prob fine. If you want to use quad-???? on the Byte9 columns, that's prob appropriate because those really are an odd mystery and I suspect are hooked up to something. Either that or both of those CJ420's are handled completely elsewhere in the binaries.

I was really wanting to replace the ??? with Unknown

Ill fixup the other formatting items


Also on your note about byte 9

in my DME it shows all but the last bit enabled in an odd way, so in my binary i have 00 00 00 01 that last bit flag does intrigue me quite a bit, but I have as of yet to get a donor DME from the junk yard to dis assemble / trace / diagnose what that output does also my life has been pretty hectic so my time to focus on reading documents has dwindled to about 2-3 hours a week. As I said in the e-mail I think I might have made it to page 80 something if that as far as deep reading. I am piqued a little more now... also if you get time in the damos file in text editor it declares Codeword anti-theft system and Codeword immobilizer I thought those were pretty fascinating.

[jicaino]

Whooooa, I miss updates for a couple of days and you guys are this much deeper into it...

[geargrinder]

I was really wanting to replace the ??? with Unknown

Ill fixup the other formatting items


Also on your note about byte 9

in my DME it shows all but the last bit enabled in an odd way, so in my binary i have 00 00 00 01 that last bit flag does intrigue me quite a bit, but I have as of yet to get a donor DME from the junk yard to dis assemble / trace / diagnose what that output does also my life has been pretty hectic so my time to focus on reading documents has dwindled to about 2-3 hours a week. As I said in the e-mail I think I might have made it to page 80 something if that as far as deep reading. I am piqued a little more now... also if you get time in the damos file in text editor it declares Codeword anti-theft system and Codeword immobilizer I thought those were pretty fascinating.

I was going to type suggestion on wording for the table but maybe I'll just go edit it and show you. Stand by for that.

Yes "01" should = "not-OBD diag, but BMW diag".

You see this a lot in all the OEM ECU discussions - various DTC's often can be configured "OBD report" or "no OBD report".

This is basically that kind of flagging except for per-hardware-pin on the outboard IC. I scanned one of the IC datasheets and that chip is reporting data to our CPU and using bit-flags over I2C indicate "short to ground, short to power" etc. which is exactly what BMW diags (aka INPA or a BMW-protocol tool like PASoft) report with electrical errors. Now I understand just a little more about how those errors work.

If you get a 'short to ground' error on, for instance your purge valve, it is not the CPU diagnosing that directly, it is the power-stage outboard IC diagnosing that and reporting it to the CPU which then sets an error in memory.

And this is why you sometimes need 2 different 'disables'. One is for the actual "emissions testing" error (turn that off) but then this is the electrical testing that the outboard IC chip does. We've always known there were 2 different types of errors - logical vs electrical/hardware - but this explains the mechanism of how it works. Interesting. For DorkoGeekNerdz.