Originally posted by Tom Donnelly:
What is available out there to dump the ECU contents to a binary file? And are there any references to what language? The executable portion of the data has to relate to some form of machine code, such as assembler. The bulk of the dump would be the data that forms the multi-dimensional array for the decision processing. Any hacking software / hardware out there for an interface to an ordinary PC?
Tom
The EPROM itself only contains the data from which the executables pull the required info for the circumstances. Most that I know of are written in simple 2-bit hex. Pulling the code is as "simple" as desoldering the chip, dropping it into a reader, and querying it for data. Of course, what you get out looks like gibberish unless you know root addresses for things.
The problem is not the code itself (language-wise), but the indexing that the programmers used. Just because the spark tables are located at address X in one program, doesn't mean they'll be anywhere near that in another. The real problem is that very little of this is documented for older cars, like the ones we deal with.
All you have to do is know which data points to change and by how much, and you can edit the raw hex code itself. You can write in executables (not the easiest thing to deal with).
If you use an interface program, altering the values is easy. You simply have to write a definition file for the code you're working with, that tells the interface where to find the data from, and how to translate the hex values to absolute numbers.
For more info, search around for GM EPROM stuff. That's one of the most well known and supported ECU groups, and there's volumes of info out there (it's where I learned how to do it).
For my stuff, I use:
An EPROMer 5 for reading and burning
http://www.ustr.net
TunerCat as an interface (they also have a program that gives you the ability to write definition files for almost ANY ECU).
http://www.tunercat.com
I also use WinHEX or NitroHEX for raw code editing and comparison.
As far as the machine code itself, most of this stuff is based off the Motorola 68HC11, so any assembler that can translate for that processor could work. I prefer to write machine code (raw hex) myself as to avoid translation errors.
Most of the issue here is finding the correct addresses, as none I've seen have any notations, even in the assembly language. What someone originally did for a lot of the GM stuff was to make a "dummy" car, complete with all inputs and outputs. Then they changed the code, and saw how the outputs reacted with various inputs, and deduced the data locations from there. As I'm sure you know, it's not that hard to located a 2D or 3D table in the code, but knowing what exact data that table is can be another story. You might think you're changing a VE table, and instead you're playing with the cold start enrichment data. Both would effect the fuel and could look similar if not monitored VERY carefully.
Then there's also the feedback functions. If you don't translate the data in the output stream correctly, you can chase your tail forever. Sure, you can use a scan tool, but you're limited in many factors, such as datalogging and the ability to discern trends.
All of this is the MAJOR reason to use a Motec. They give you software that says, here's where you change this to do this, and it does it all in real world numbers. Plus, it has the ability to talk directly to a laptop since it translates itself. No fuss, no muss.
Starting to sound like it's worth the $$, huh?
------------------
Matt Green
"Ain't nothin' improved about Improved Touring..."
