E30 M42 to Motronic 1.7.3 Conversion Project

[Rasp]

About segments count and cylinder count separately for AT or MT - of course it does not make sense, but Motronic code is build from standalone libraries connected each other by shared RAM variables with represents bits and values. You understand that code is incapsulated and parameters are incapsulated too. So programmer worked on some function need decide what parameters need to setup differently, for example AT/MT, than given that is 10 from 25. Ok, so other 15 will also be separated by AT/MT without any sense of this and hold same values. This is done for the convenience of programmers, calibrators has software which takes into account these features and of course segments count and cylinder count are filled once and both for AT/MT. TunerPro has not ability to set mirror address, thats I'm forced to specify all values.

[nando]

Yep - not disagreeing at all. I think there's a bit of a language barrier, or I'm not clearly explaining what I'm seeing in the disassembly.

Basically the program has a way to load a different offset into the DPTR (data pointer) depending on if it's AT or MT. So from a program point of view, it's easier if there's an AT and MT version of everything, even if they're mirrors of each other.

In the disassembly, I would probably just use the MT offsets (or build a separate IDA for AT). I just need to figure out what it's using for the offset value. Also, I think it can be different depending on what set of maps it's looking at, because some of them work without an offset value (you can see where it branches between AT and MT).

[bmwman91]

Good work bmwman91, thanks a lot!

Looks like 27C512 can be directly replaced with 28F512 if change chip connector (sorry, I'm dont know how its named in english, we call it "crib" if translate :) ).
Thats completely solves the problem with online (not bench with programmator) flashing.
Another plus in the piggy bank for M1.7.3.

Nice! Yes, it would be so much more pleasant to tune things with a flash chip in there. Constantly taking the ECU out, opening it and UV-erasing the EPROM is a hassle, and I do not have an Ostrich (nor do I want to spend $200 on one if I can avoid it).

"Crib" makes sense as a description for it. In English terminology, it would be called a socket, or specifically in this case a DIP socket.

For the XDF, I see that most axes have values manually entered. As of one of the more recent Tunerpro releases, the formulas seem to work properly and axis values can actually be made directly from the BIN values (previously, the self-referencing cell formula would cause Tunerpro to crash). The only problem is that you can't do the axis value conversion directly in the actual map since the last axis value is treated differently, so you have to make additional maps for each "real" map where the axis values are calculated, and then the "real" map has the axis values linked from the other maps. Setting the XDF up to have all axes calculated directly is a lot of work, but I think it would probably make things much easier in the end. Just a thought. I can help with adding in axis conversion tables if you want to try to get things set up like that.

About segments count and cylinder count separately for AT or MT - of course it does not make sense, but Motronic code is build from standalone libraries connected each other by shared RAM variables with represents bits and values. You understand that code is incapsulated and parameters are incapsulated too. So programmer worked on some function need decide what parameters need to setup differently, for example AT/MT, than given that is 10 from 25. Ok, so other 15 will also be separated by AT/MT without any sense of this and hold same values. This is done for the convenience of programmers, calibrators has software which takes into account these features and of course segments count and cylinder count are filled once and both for AT/MT. TunerPro has not ability to set mirror address, thats I'm forced to specify all values.

Hmm, so the Bosch firmware engineering teams all had different people/groups writing small pieces of the code independently, and then it was all put together and connected with switches and pointers in program data to select what to use?

Yep - not disagreeing at all. I think there's a bit of a language barrier, or I'm not clearly explaining what I'm seeing in the disassembly.

Basically the program has a way to load a different offset into the DPTR (data pointer) depending on if it's AT or MT. So from a program point of view, it's easier if there's an AT and MT version of everything, even if they're mirrors of each other.

In the disassembly, I would probably just use the MT offsets (or build a separate IDA for AT). I just need to figure out what it's using for the offset value. Also, I think it can be different depending on what set of maps it's looking at, because some of them work without an offset value (you can see where it branches between AT and MT).

Have you found the code addresses where the map look-ups are done? I assume that the AT vs MT switch will affect which address offset from the "map list" is loaded into DPTR. Since not all AT & MT maps are directly adjacent, the selection is more than just "incrementing DPTR by 2" after getting the pointer from the list.

[nando]

they aren't adjacent, but I noticed that all the MT maps are in groups, and AT maps are in groups - and the offsets for the maps in each group are spaced the same distance. So I think it loads the first map in the group (where it branches between AT or MT), and then the offsets are just the current group DPTR + the offset for each successive map.

That's my current theory, but I can't really work on it any further this week. It does seem to line up with what Rasp said, each group (or different engine function) is sort of standalone, and all AT and MT settings are included. :)

[bmwman91]

Just a couple of small updates. I opened up all of the remaining IC's from the M1.7.3 board I took apart and was able to do it without destroying most of them. It's basically all for fun at this point since it isn't that important to the main task of RE'ing the firmware, but since I had them in a bad I figured I would get images. They are in the Photos > Chip Pics section. Also, I put in the values for all of the resistors in the schematic, and the PDF is updated to reflect this. I am also going to measure all of the capacitors (since there are no useful markings on any of the surface mount ones). Most of them are probably 100nF bypass caps and not all that important to know the value of, but the ones in the analog sections are a little more important. The big poly caps are easy since they are large and marked, but some of the surface mount ones are C0G/NP0 type and clearly being used for analog filtering purposes, so I want to get their values. They need to be removed from the PCB for measurement though, which is easy enough.

[Rasp]

I do not have an Ostrich (nor do I want to spend $200 on one if I can avoid it).

Yes, I'm not want buy Ostrich too, because its waste of money and lot of holes and cables, not for daily car.

it would be called a socket, or specifically in this case a DIP socket.

Yes, its DIP socket, thanks :)

For the XDF, I see that most axes have values manually entered. As of one of the more recent Tunerpro releases, the formulas seem to work properly and axis values can actually be made directly from the BIN values (previously, the self-referencing cell formula would cause Tunerpro to crash). The only problem is that you can't do the axis value conversion directly in the actual map since the last axis value is treated differently, so you have to make additional maps for each "real" map where the axis values are calculated, and then the "real" map has the axis values linked from the other maps. Setting the XDF up to have all axes calculated directly is a lot of work, but I think it would probably make things much easier in the end. Just a thought. I can help with adding in axis conversion tables if you want to try to get things set up like that.

Actually thats not needed at this time or generally :) Tables stored each with own axes, change size of tables and axes not trivial work, change axes values need only if... I can not think of :) I mean thats can be needed for 1 case from 1000000. Its waste of time.

Hmm, so the Bosch firmware engineering teams all had different people/groups writing small pieces of the code independently, and then it was all put together and connected with switches and pointers in program data to select what to use?

Simply put yes, Its not unicorns or other fantastic animals :) Its developed products like other people, at least in 80-90. There is no Windows, no IDE, no version control system. Imagine how to work in such conditions and you will understand that other way is not impossible.

[bmwman91]

Makes sense. The only tables I would make axis changes to are the WOT fuel & ignition since my engine is happy up to ~7700RPM, and that is pretty simple.

So, in terms of working on the firmware, what all needs to be done still? I think I am going to take a break from the hardware since it is 95% figured out, and I'll start going into the disassembly.

[nando]

if you want to share your IDA folder I can upload what I've done so far. You will need IDA 7.0. Send me a PM. ;)

[Rasp]

Makes sense. The only tables I would make axis changes to are the WOT fuel & ignition since my engine is happy up to ~7700RPM, and that is pretty simple.

For injection 7000 RPM is limit for WOT axis and there is no way to change without recompile software (but it one byte to change this :) ). I'm think around 7000, doesnt matter 6800, 7000 or 7700 RPM, because closer to 8000 calculations speed is dramatically drop and process in engine around 7000 become very unmanageable. But of course I can be wrong, you need to test.

So, in terms of working on the firmware, what all needs to be done still? I think I am going to take a break from the hardware since it is 95% figured out, and I'll start going into the disassembly.

Try to figure out what has already been done. More than a month can only go to the realization of what is happening there, in spite of the fact that Motroniс code is less than the bootloader code of some ECU :)

It would be nice to sort out the hardware level with the S702...

Now I'm dealing with diagnostics communication, for make flasher for 28F512-like flash. Need understand which one suits for us - Intel AP28F512, AMD AM28F512 or SST27SF010.



Do you know that all this flashes has same or different algorhytms for erase/write? Its fully your specific as hardware guy :) I'm not fully understood this issue now.

if you want to share your IDA folder I can upload what I've done so far. You will need IDA 7.0. Send me a PM. ;-)

Interesting to see what have been done.

[bmwman91]

if you want to share your IDA folder I can upload what I've done so far. You will need IDA 7.0. Send me a PM. ;)

PM sent!

For injection 7000 RPM is limit for WOT axis and there is no way to change without recompile software (but it one byte to change this :) ). I'm think around 7000, doesnt matter 6800, 7000 or 7700 RPM, because closer to 8000 calculations speed is dramatically drop and process in engine around 7000 become very unmanageable. But of course I can be wrong, you need to test.



Try to figure out what has already been done. More than a month can only go to the realization of what is happening there, in spite of the fact that Motroniс code is less than the bootloader code of some ECU :)

It would be nice to sort out the hardware level with the S702...

Now I'm dealing with diagnostics communication, for make flasher for 28F512-like flash. Need understand which one suits for us - Intel AP28F512, AMD AM28F512 or SST27SF010.



Do you know that all this flashes has same or different algorhytms for erase/write? Its fully your specific as hardware guy :) I'm not fully understood this issue now.



Interesting to see what have been done.

I guess we will find out exactly what can and cannot be done at 8000RPM. From what the guy on the S2 / M2.3.2 forum was saying in his project: "The fuel/ign control chip main loop (map lookup) runs at 100hz or best effort. It can keep updating 100 times per second up to about 5000 RPM, after which the final injection/ignition output calculations start to take more and more processor time and the main loop gives way. At 8500 RPM it still runs at over 30hz. Plenty fast enough for the global low-impact calculations." At least on my M1.7 setup now, when I was tuning I was running to 7500RPM and it was able to keep the fueling correct all the way up.

Are the WOT maps in M1.7.3 done differently than in M1.7? Changing table size and axis values was very very easy in M1.7.


I can keep working on S702 since that is something I think I can figure out. I may also need to build a basic engine emulator from a separate microcontroller so that I can simulate the crank+cam sensors and various analog signals. The fuel maps can be used "backwards" while reading the injection period that the ECU is using to simulate an O2 sensor I think. Maybe to start I will just simulate the crank signal since that should be enough to get it to cycle the injector and coil circuits.

[Rasp]

I guess we will find out exactly what can and cannot be done at 8000RPM.

Yes, need investigate, theoretically around 8000 is restriction for Motronic on 60-2 crankshaft pulley.

Are the WOT maps in M1.7.3 done differently than in M1.7? Changing table size and axis values was very very easy in M1.7.

Yes, its differently for fuel, I cant know for why reason. Perhaps for greater accuracy.

I can keep working on S702 since that is something I think I can figure out.

It would be good, because for now its most secret part :)

[nando]

Are you guys able to read out a RAM dump of a working DME? That would help the disassembly.

Using the IDA project it's easy to change assembly code by hand (well, somewhat easy, you have to calculate the opcodes etc). At least, you don't have to recompile the whole thing - you just patch what you need to change and correct the checksum if required.

My work PC is down (I usually log in remotely on Fridays), so I can't get to my files today.

[bmwman91]

Yes, need investigate, theoretically around 8000 is restriction for Motronic on 60-2 crankshaft pulley.



Yes, its differently for fuel, I cant know for why reason. Perhaps for greater accuracy.



It would be good, because for now its most secret part :)

OK, I will work on S702. I will probably need to either start simulating engine signals to get S700 to use more of the S702 functions, or I will have to try to solder my logic analyzer in to the M1.7 unit in my car and drive around.

Can you give a quick summary of how M1.7.3 does WOT fuel calculations differently?

Are you guys able to read out a RAM dump of a working DME? That would help the disassembly.

Using the IDA project it's easy to change assembly code by hand (well, somewhat easy, you have to calculate the opcodes etc). At least, you don't have to recompile the whole thing - you just patch what you need to change and correct the checksum if required.

My work PC is down (I usually log in remotely on Fridays), so I can't get to my files today.

There is a way to read RAM in real time, sort of. It is really slow, so I would not exactly call it "real" real time. I think that RASP worked out a much faster serial interface method for doing this. The factory way uses the K-line communication bus. There is some info here, and it is what I used to dump the 8K internal ROM of the MCU in M1.7 a while back.

http://cardiagnostics.be/-now/GT1-MODIC-DIS_bestanden/Prescription%20Protocol%20KW-71.htm

[nando]

It doesn't really have to be in real time, a snapshot is fine - it doesn't even have to be on a running car (although that is definitely better), it's just helpful to see actual memory contents instead of "space 1" etc.

[Rasp]

OK, I will work on S702. I will probably need to either start simulating engine signals to get S700 to use more of the S702 functions, or I will have to try to solder my logic analyzer in to the M1.7 unit in my car and drive around.

It would be good to investigate how works TV1-TV4.

Can you give a quick summary of how M1.7.3 does WOT fuel calculations differently?

It doesnt have axis, for this used raw RPM value and raw 2d table.

It doesn't really have to be in real time, a snapshot is fine - it doesn't even have to be on a running car (although that is definitely better), it's just helpful to see actual memory contents instead of "space 1" etc.

Internal memory fully used, external memory on each connect to +12 fill with random garbage (I think it's not necessary to explain why?) without fill 0xFF unused areas, so real used of RAM can be given only from ASM code. Its not modern ECU with modern CPU, there is no need anything from what you suggested. Imagine that you have fully source code, not disassemble.