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.
Announcement
Collapse
No announcement yet.
E30 M42 to Motronic 1.7.3 Conversion Project
Collapse
X
-
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).
Comment
-
Originally posted by Rasp View PostGood 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.
"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.
Originally posted by Rasp View PostAbout 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.
Originally posted by nando View PostYep - 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).
Comment
-
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. :)
Comment
-
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.
Comment
-
Originally posted by bmwman91 View PostI do not have an Ostrich (nor do I want to spend $200 on one if I can avoid it).
Originally posted by bmwman91 View Postit would be called a socket, or specifically in this case a DIP socket.
Originally posted by bmwman91 View PostFor 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.
Originally posted by bmwman91 View PostHmm, 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?Last edited by Rasp; 03-14-2018, 09:15 PM.
Comment
-
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.
Comment
-
Originally posted by bmwman91 View PostMakes 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.
Originally posted by bmwman91 View PostSo, 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.
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.
Originally posted by nando View Postif 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. ;-)Last edited by Rasp; 03-15-2018, 11:07 PM.
Comment
-
Originally posted by nando View Postif 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. ;)
Originally posted by Rasp View PostFor 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.
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.
Comment
-
I guess we will find out exactly what can and cannot be done at 8000RPM.
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.
Comment
-
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.
Comment
-
Originally posted by Rasp View PostYes, 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 :)
Can you give a quick summary of how M1.7.3 does WOT fuel calculations differently?
Originally posted by nando View PostAre 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.
AUDI BMW RENAULT CITROEN MERCEDES PEUGEOT VOLKSWAGEN HONDA NISSAN OPEL SEAT DACIA SKODA TOYOTA VOLVO FIAT MITSUBISHI Alfa Romeo FORD Land Rover PORSCHE KIA HYUNDAI Ferrari DAF VOLVO Harley Davidson Yamaha Diagnostic Tool VAS PP PPS 2000 LPG Proxia Clip can sonde cansonde PPI AutoData BrainBee Hella Carsoft OP-Com opelscanner Tech 2 GT1 Modic EOBD OBD OBD2 PWM VPW canbus can adapter VCDS vag-com Truck Motorcycle OPPS OPS Modic DIS VCT2000 INPA Select Monitor Consult DAF WDS IDS VCM DAF DAVIE XD PTT Mack GFS Light Formidable Examiner Arbritus ETOS DAS WIS wisnet sim manuals download free pictures system DTC information LPG tuning APP Yamaha MUT Vidia TIS PIWIS Durametric M-MDS
Comment
-
Originally posted by bmwman91 View PostOK, 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.
Originally posted by bmwman91 View PostCan you give a quick summary of how M1.7.3 does WOT fuel calculations differently?
Originally posted by nando View PostIt 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.
Comment
Comment