I should have some GT files soon!! Today I'll be adding another GTP file.
Regarding the OBD-II LT1 files... Even the OBD-II LT1 vehicles use the 68HC11 proceessor. The flash files are also split up between 2 flash chips.I thought about this over the weekend and believe the LT1 guys will mostly fall under the OBD-I section, even the OBD-II ones.
What do you guys think?
We got this guy Not Sure, ...
So when is someone going to show me how to read these files?
Just curious to get a good look at the code is all!
DEE
i use binedit.. its a free download
heres one of many sites to get it from:
http://drive2survive.karf.net/
as for what it all means..Still workin on that myself.. lol
Business Network Solutions - for all your PC, network, printer and computer security needs.
Dee, I use Hex Workshop.
http://www.bpsoft.com/
It's not that expensive either and has MANY cool features.
Regarding actual code, you'll need a Motorola 68332 disassembler that understands TPU code.. very VERY hard to come by. If you have any luck with this please share the info. I'm looking for a GOOD one myself.
We got this guy Not Sure, ...
"Regarding actual code, you'll need a Motorola 68332 disassembler that understands TPU code.. very VERY hard to come by."
Hard, but not that difficult ;-) Its certainly not like the classic m68k code I have worked with, but not *that* different. Refer to http://www.eslave.net/ for everything you never wanted to know about programming and debugging '332 TPU code. The debugger (tpubug) is meant for an MC68332 dev board, or so it appears. [edit: Moto's SPS at e-www.motorola.com does not require an account, just hit the MC68332 product page for more ref manuals & software.]
Believe GM uses Ashware's TPU/CPU32 simulator (http://www.ashware.com/Products_Pages/MtsTpuCpu32.htm) to test code, if anyone wants to drop serious money into the project.
I am working off the Unix TPU assembler (tas) and srecord utility (hex/bin to srecord and back) with the 98+ calibration files. Using the tas source and ref manuals, I can probably add TPU microcode as a target for the gnu dev tools (binutils, gdb, gcc, etc.) in a couple days.
The problem is knowing exactly what the calibration files "are". Alright, so the TPU supports an emulation mode where the CPU copies microcode into the on-chip 2k sram to program functions for each i/o channel. Does that necessarily mean the calibration file is just 256 TPU functions (512k/2k control store cache) in sequence? Not likely.. GM coded the pre-OBD2 software in Modula and currently uses a macro assembler (GMCM). It looks like a mix of CPU32 bootstrap code, with lots of buffer space to spare -- when Moto srecord files are converted to binary prior to flash, nulls are usually converted to 0xFF by default. That explains the large null regions.. probably for "user functions" like PCM adaptive functions.
Anyhow, just a brain dump before the wife shuts me down for the night.
lmos: Some very good sites you got there.. now my brain is smoked ;D Now I have a few days worth of reading material anyway...
Business Network Solutions - for all your PC, network, printer and computer security needs.
Hey Robo. this is the same ZIF that is on the PP2 converter. I would really like one of these to fit directly to a PCM. Although i haven't found one that has the right footprint as yet. The slide type of socket i have is not too friendly on the chip legs if you know what i mean.Originally Posted by RoboGeek
how many variations are there for the flash chips? I've seen 36 pin square, 40 pin square 44 pin..
this is the type your talking about?
universal converter, assigned for all PSOP (SOIC) devices up to 44 pins (especially FLASH EPROM), 13.3mm body width (520 mil)
pins lead pitch 50 mil (1.27 mm)
operation life of ZIF socket - 10.000 actuations
not the actual one i can get..
Thats a converter and not a socket
I count sheep in hex...
wow.. this post sure came back from the dead!
Its kinda funny to read some of the very first posts we all made here. We sure have learned alot if you look back a year...
Business Network Solutions - for all your PC, network, printer and computer security needs.
Definately learned a lot since the inception of this board.. and it's nice to be refreshed of some of the things we learned back in the day as well.
We got this guy Not Sure, ...
The upcoming Romulator II from Xtronics will have 512 kb chip functionality. Once everything has been finalized, you should have a rather cheap solution for real time "on the fly" tuning of many GM OBDII systems. No more need to resolder in a chip every time you make a code change...
A lot depends on the future availablity of GM code editing software that has the capabilty of editing a 64k binary file, along with emulator hardware control and interface for the Romulator II. You can check out the software I developed to get a better idea of how the final system will work :
GMPCM Software
bigger issue is that 97 ls1 pcms use 2.6 megs of memory out of a 4 megs chip. 64k aint gonna cut it for these bad boys. howeer for the dual processor 96-97 lt1's it should work.
The later LS-1's and LS-6's use even more.
Essentially "all" of that 4 megabit (aka 512 Kilo BYTE)
flash chip.
If you have the hardware to burn a chip that size, it should not be a probem, as I can easily provide the capabilty within the GMPCM software to handle binaries with file sizes large enough to fill some harddrives.
The only file size limitations within the software at present were simply based upon what has been popular in the past (i.e. OBDI). 512 KB seems like a fairly popular chip size with OBDII, although I am sure that current needs could dictate otherwise.
GMPCM can already write a 4mb binary file using its mult-burn feature, these are simply stacked binaries for larger chips on switch circuits.
I was checking over the source code, and the work I had done previously was pretty much complete anyway.
You can create a new PCM file and import the LS1 4mb binary into it just fine. As soon as I find some info on checksum location, it will be updated so that it can correctly write the binary. GM's semi standardized location for checksum right up to OBDII was at $8006-$8007, but its probably changed from that for the larger chips.
On the later (I think it's 1998 or 1998.5+) there are a
total of eight checksums.
Can't vouch for the earlier stuff.
Jim
That is quite unlikely, unless they are using 8 separate binary files stacked together. The GM checksum is typically used verify the inegrity of the "entire" data segment. We should not confuse this with a communications checksum, as these are used to verify blocks of data.
there are 7 segments to the CAL.
eg. from a bin i am working on:
1. Operating System: 12225074
2. Engine Calibration: 92116063
3. Engine Diagnostics: 92116074
4. Trans Calibration: 92116085
5. Trans Diagnostics: 92116096
6. Fuel System: 92116107
7. System: 92116118
8. Speedometer: 92116129
locations are:
504 Seg1 CAL ID
8000 Seg2 Checksum
8004 Seg2 CAL ID
14000 Seg3 Checksum
14004 Seg3 CAL ID
16E00 Seg4 Checksum
16E04 Seg4 CAL ID
1BE00 Seg5 Checksum
1BE04 Seg5 CAL ID
1C800 Seg6 Checksum
1C804 Seg6 CAL ID
1EEA0 Seg7 Checksum
1EEA4 Seg7 CAL ID
1E520 Seg8 Checksum
1E524 Seg8 CAL ID
I count sheep in hex...
Well, that would imply that they are indeed stacking 8 separate binary files together. Not a big deal but they are obviously also not equal in size. Since the checksum address can be defined anywhere in the code, one would simply reference the checksum according to the "section" that they had modified before exporting the binary to disk, as all other checksums would retain thier original values.
This would also require specifying the start and end of the section, but all of this has already been implemented.
A separate definition file for each section would be the best way to approach this, as one would then not need to modify checksum information once it had been defined, and could not arbitrarily modify a data value in more then one section at a time. Much less confusing..
exactly how LS1Edit does it i'm sure
you only need to write the $8000 to $1FFFF part of the bin as well since this is where the cal is, rest of the file is OS and other. But it would be nice to write to these parts.
I count sheep in hex...
Yes, but then you would have to burn only the changed area/section, or somehow recompile the entire chip data with the changed section substituted before burning.
This might work well if you had block write capabilty, such as flashing directly through the aldl, but that presents such problems with protocol, etc. that it is not as feasible as simply burning the entire chip (at least not at this point in time using common inexpensive equipment).
Since you could attach an emulator in place of smaller sized chips, you can simply write the changed data by individual address as it is being modified, so it is much simpler.
One can only hope that the OBDII aldl protocols can be decipered soon, and from what I gather, it should be fairly finalized in the very near future. It would sure reduce the cost of tuning these systems by a huge amount if you could flash them directly from a laptop. It would also be quite simple to include communications capability within GMPCM with interface to a bus cable if an absence of proprietary complications that exist in the current offerings could be achieved.
Is anyone here currently working with the early Cadilac Northstar 4.6l code? It is also a prime example of a good starting point in developing OBDII definitions (like the LT1), as it uses the 512 KB (i.e. 64k) chips which could be replaced by the Romulator II for data area verification.
Reply With Quote