E30 M42 to Motronic 1.7.3 Conversion Project

[MarkD]

7) Pin 27 which is labeled as "WUP" in the schematic is not connected to anything in M1.7.3, but it is in M2.3.2. Despite this, it toggles between low/high every 10ms in my DME, immediately after S702 is written to (data FDh to address A040h). I do not observe any other outputs changing when this command is sent, so I have no clue as to why it is in the firmware to do this with an unused pin.

Almost for sure this is just code used for testing and debug, to be used as a trigger for an oscilloscope and then measure an event happening after that trigger. Nothing to see here...

[bmwman91]

Dont waste time its debug code.


Yes, all before that is "init" code, just after connect ECU to battery and before ignithion on start.

Yes, looks like debug for sure. After starting the WDT and initializing S702, it looks to be checking AN0-4 to see if they are within an expected range, and then it looks like it checks to see if the internal RAM retains values written into it. I've been busy with other things so I did not make it too much further. Anyway, I often find the config / init sections of things to be somewhat informative since seeing how the various SFR's are configured usually helps in understanding how/why they are used in a particular application.

Actually $5-15 for DS1245Y on ebay, but there are offers more $100 :) (maybe original).

I think that is possible to rewrite table access function for work with external ram content, so about 15 tables we can edit online before ECU disconnected from battery. Its enought for engine tuning, but need to rewrite firmware, of course :)

Yes, eBay pricing is better...Digikey has new ones for ~$30-40. I wonder if it would be better to just find a cheap I2C or SPI interface device and build a serial-to-parallel converter for communicating with the MCU, and then use a couple of the unused pins in the X1 connector to break out into a USB connection for direct programming? And yes, it would be very cool to have some of the tables moved into the SRAM chip and do "hot" changes to them. Of the dozens of fuel & ignition related maps, it seems like only a small number of them are actually needed since many are duplicates for fuel quality or regional changes, so a little rewriting of the code or the map pointer table to force access into only the minimum number might work with these in SRAM.

Almost for sure this is just code used for testing and debug, to be used as a trigger for an oscilloscope and then measure an event happening after that trigger. Nothing to see here...

Interesting, makes sense. From RE'ing the PCB, there are tons of test points on the bottom, basically one for every signal. I assume that in the factory they put every unit into an ICT fixture and simulated everything + checked resulting outputs before packing it out. I could see the marks from pogo pins in the through-hole test points since the solder fill is so soft.

[bmwman91]

I'm now doing my code commenting in the IDA project in the nando folder of the Dropbox.

Honestly, some of the code is so badly optimized that I am thinking that it must have been written in some very rudimentary C or BASIC environment with zero optimization when it was translated into machine code. There are useless instructions everywhere which indicate that either nobody ever actually went through the assembly listing that the compiler generated, or if people were writing it directly in assembly, there were 500 different programmers and some large percentage of them really weren't very good. The latter case seems unlikely, so I am going with the first guess...written in a higher level language with a crappy compiler (it might have been "good" for the time 30 years ago, but it's junk now based on what I see).

Once I get into the subroutines that handle table lookups and stuff, I am going to make serious notes if/when I come across inefficient code. It sounds like the main loop gets bogged down at higher RPMs, and if there is room to speed it up I think that there might be some small benefit.

One example, and this is a really small one...there are plenty of others that waste more cycles.
mov A, #0
movx @R0, A
clr A

[nando]

I saw that all over the place too! I thought I was just misunderstanding the code, since i'm not familiar with 8051 ASM - no wonder it didn't make sense to me. :p

I guess it makes sense as I've been looking at mostly modern DMEs which I suppose have very good compilers, because I don't recall seeing anything like that.

If we come up with a standard way to mark that code, I might be able to write a program that fixes it all automatically from a binary. What's the easiest way to replace that kind of code? no-op? can you just delete it and shift the bytes up, or will that mess up offsets etc? (obviously padding it with FFs at the end)

[MarkD]

I'm now doing my code commenting in the IDA project in the nando folder of the Dropbox.

Honestly, some of the code is so badly optimized that I am thinking that it must have been written in some very rudimentary C or BASIC environment with zero optimization when it was translated into machine code. There are useless instructions everywhere which indicate that either nobody ever actually went through the assembly listing that the compiler generated, or if people were writing it directly in assembly, there were 500 different programmers and some large percentage of them really weren't very good. The latter case seems unlikely, so I am going with the first guess...written in a higher level language with a crappy compiler (it might have been "good" for the time 30 years ago, but it's junk now based on what I see).

Once I get into the subroutines that handle table lookups and stuff, I am going to make serious notes if/when I come across inefficient code. It sounds like the main loop gets bogged down at higher RPMs, and if there is room to speed it up I think that there might be some small benefit.

One example, and this is a really small one...there are plenty of others that waste more cycles.
mov A, #0
movx @R0, A
clr A

I can't imagine that they used BASIC. I'm quite sure they were using a mixture of assembly language and PL/M-51 back then.

You can read amount PL/M here:

http://www.keil.com/support/man/docs/c51/c51_ap_ctoplm51.htm

And I bet they had teams of programmers writing varios functional blocks,which has to conform to well documented specific inputs and outputs so that hardly anyone could leave the company with all the source code, they probably only got to see their section. Obviously there would be a few people who had access to all of it.


I'm interested to have a look at the code, where is this code you mentioned in the source?

mov A, #0
movx @R0, A
clr A

I'd like to have a look at the other examples just out of curiosity.

[bmwman91]

I saw that all over the place too! I thought I was just misunderstanding the code, since i'm not familiar with 8051 ASM - no wonder it didn't make sense to me. :p

I guess it makes sense as I've been looking at mostly modern DMEs which I suppose have very good compilers, because I don't recall seeing anything like that.

If we come up with a standard way to mark that code, I might be able to write a program that fixes it all automatically from a binary. What's the easiest way to replace that kind of code? no-op? can you just delete it and shift the bytes up, or will that mess up offsets etc? (obviously padding it with FFs at the end)

The goal would be to remove those instructions entirely since they waste instruction cycles, meaning a shift in code locations. But, we need to be extremely careful in doing this because so many data sections are accessed by their absolute address, so a lot of ORG type directives need to be put in place for every data chunk, plus all of the JMP trees need to be either fixed into place, or have their JMP offsets adjusted. Alternatively, I guess that all code chunks could have ORG directives placed in front of them, and then prune out wasteful instructions since then chunks would get shorter without having their start address change.

I can't imagine that they used BASIC. I'm quite sure they were using a mixture of assembly language and PL/M-51 back then.

You can read amount PL/M here:

http://www.keil.com/support/man/docs/c51/c51_ap_ctoplm51.htm

And I bet they had teams of programmers writing varios functional blocks,which has to conform to well documented specific inputs and outputs so that hardly anyone could leave the company with all the source code, they probably only got to see their section. Obviously there would be a few people who had access to all of it.


I'm interested to have a look at the code, where is this code you mentioned in the source?

mov A, #0
movx @R0, A
clr A

I'd like to have a look at the other examples just out of curiosity.

The IDA project is in the Dropbox link in my first post, under nando_IDA. As long as you have a Dropbox account, I think you should have read-only access.

The example I pasted above is from 0xAD28. Another good one is at 0x916E...see what it does in the call, and then promptly clears A after returning.


I'd believe that a bunch of different people were silo'ed and working on small chunks with only minimal information about what the broader context was. It sure looks like it, which could explain why (for example) things seem to be coded in such a way as to be "doubly sure" that A contains the proper value before it is used in various sections. Is it fair to assume that Bosch/BMW are extremely secretive about their algorithms since those comprise a large part of their secret sauce in making their cars run nicely?

[bmwman91]

Hey Rasp, I just realized something...it does not look like M1.7.3 has a control signal for the Check Engine Light. How is that controlled in the E36? I also do not see much reference to it in the wiring diagrams. Or am I missing something very obvious?

[Rasp]

I'm quite sure they were using a mixture of assembly language and PL/M-51 back then.

I'm think you are right (of course - because you works with some thing many years ago :) ). But I'm strongly sure that all parts is write on ASM, but all RAM access write on PLM. Because in whole code used people-understand operations with registers (do not need to be afraid of overflow), stack used only for hold some variables and addresess and all this things strikingly similar on whole code. BUT all operations with RAM or XRAM is occur in different ways, sometimes its caused by P2, sometimes by DPTR even previously used by P2 :) hold DPTR in stack in arbitrary order - push DPH, push DPL in one place, than push DPL, push DPH in several lines below. People do not write code inconsistently like what we see. Work together with RAM and XRAM probably headache in big projects, so I'm think its done this work in that way.

The goal would be to remove those instructions entirely since they waste instruction cycles

All timers in Motronic is related to CPU clock frequency (at first), 10 ms timer (follows from the first) aaaaaaaaand time of main cycle execution (which is limit max to 10 ms, so follows of the second). So if you changed main cycle so much - you can get issues with corrupted timers. Thats one thing (possible of course :) ). Thing number two - you cant change time of execution with your "clean code" or "optimisation" like described above. You need cut whole functions to make this. Thing number three - dont make common mistake of all programmers - not having understood whole code and what is happening, not having received a real problem - try to optimize something. Its waste of time, usual. Notice, I'm not command you or write the only way, but advise, because I'm has done this (mistakes) so many times already :)

The example I pasted above is from 0xAD28. Another good one is at 0x916E...see what it does in the call, and then promptly clears A after returning.

"mov A, #0" used this, because in some software its not 0, maybe 1 or 2 or 3 or other value and not always hardcoded, sometimes given from settings with "mov A, @A+DPTR" - its for example. Just common case.

I'd believe that a bunch of different people were silo'ed and working on small chunks with only minimal information about what the broader context was.

Just works in groups and make common bricks to complete some project of them, often not knowing how it works on engine :) Its produced some non-optimize things but within the "bounds of decency", its not open-source and not MS! :)

it does not look like M1.7.3 has a control signal for the Check Engine Light.

No, I'm see that check-engine light code is exists in M1.7.3, about schematic - you are best say instead of me :) Can you compare with M1.7 this thing?
E36 non-US has not check engine light, its not required by OBD-I.

[bmwman91]

With respect to making "improvements" to the code, yes I agree that nothing should be touched until a more complete understanding of the code is achieved. And since you have already tried this, it may be that not much can be done since various timings are dependent on the number of instruction cycles between operations. For the precision stuff like ignition and fuel injection, I am assuming that the main way that timing is achieved is by the P1.0/INT3 interrupt coming from the crank position wheel...the interrupt function related to that is a MONSTER. It looks like Cthulhu in the IDA graph! Beyond using the crank wheel, there is probably some amount of dependence on the exact number of instruction cycles between events since that will have an effect on the true dwell / ignition timing and injection start time. So certainly great care must be taken there.

For the main loop, I of course need to understand it before touching it. It sounds like it runs at either 100Hz, or "best effort" if the RPM is high and the interrupt functions are using a lot of available cycles. The idea would be to remove "junk" instructions from the main loop so that it could execute more quickly at higher RPM when it is not able to maintain a 10ms period. I assume that it maintains that 10ms period by checking some timing constant against one of the timers to see if 10000 instruction cycles have completed: if yes, then it goes back to the start, otherwise it waits in a NOP loop or something until then. If instead Bosch programmed in about 10000 instructions worth of "stuff to do" so that is is not actually checking the timer and is barely able to keep up with itself, then more work would be needed to ensure that timing is maintained if "junk" is removed.

Back to your point though, maybe it is pointless to do this. The ECU seems to do a good job as it is. There's a saying that says, "if it isn't broken, do not fix it." That is probably the case here.

I'm see that check-engine light code is exists in M1.7.3

For the check engine light, since you have found the code related to it, do you know which Port#.# is switched in the code for this? My only guess is that the missing T430 circuit is for this, although a TO220 transistor is way overkill for switching a small light bulb. I looked at a couple of US-spec E36 diagrams and most of them seem to use pin 8 for check engine light control (M1.7.2 & M3.3). In M1.7.3, pin 8 is not connected to anything.

[MarkD]

I wouldn't bother trying to speed things up by removing instructions. There will be very little to be gained by removing them - you aren't going to suddenly get another 5 or 10% of CPU bandwidth available. I've already thought about how to get more CPU bandwidth for many years, and had been thinking of making a product based on my idea. It was to substitute a much faster processor for the one that is currently there.

[Rasp]

For the check engine light, since you have found the code related to it, do you know which Port#.# is switched in the code for this?

CC150 20 pin, try to path it from chip to main plug, you do not publish PCB schematic so I'm cant do this. It used since M1.7 (maybe M1.1 I dont check this earlier) and has no modified.

[bmwman91]

CC150 20 pin, try to path it from chip to main plug, you do not publish PCB schematic so I'm cant do this. It used since M1.7 (maybe M1.1 I dont check this earlier) and has no modified.

Maybe you missed the post...the M1.7.3 schematic has been online for a couple of weeks. See the PDF files in the ECAD directory on Dropbox.

S702.20 isn't connected to anything. Pin 47 is the only unused output it seems, with a bunch of not-installed transistors. S702.22 seems to be the control line for it.

[Rasp]

S702.20 isn't connected to anything.

So thats cause of no check engine light on main plug.

Pin 47 is the only unused output it seems, with a bunch of not-installed transistors. S702.22 seems to be the control line for it.

Its unused pin, unmarked on all schematic I saw.

[bmwman91]

Can you confirm whether you have access to the ECAD folder or not? It has the M1.7.3 schematic and PCB layout PDFs...it should be accessible to anyone with a link.

[Rasp]

Yes I can, I mean no PCB schematic, not principial :)