EE dissection

[Faceman]

I am also interested in understanding the $EE code and had a look into the bin just with a text editor. There was some speculation about what T and E side means. i would say:
Time side and Event side, because there is reference in the bin:

first half of bin:
ERASING FLASH ON TIME SIDE.
PROGRAMMING FLASH ON TIME SIDE.

second half of bin:
PROGRAMMING FLASH ON EVENT SIDE.
ERASE VPP HI ERROR - EVENT SIDE.

But maybe it also correlates somehow to Engine and Transmission side.

Does anybody already know if the CPU memory is somehow mapped to the bin? I am asking because e.g. the VIN is in the bin, but I cannot imagine it is possible to change it by just changing it in the bin and flashing it into the car. I can imagine parts of the bin are not really written or used by the code, but come from CPU ROM.

And maybe a stupid question (sorry, don't have much knowledge yet): does the PCM have two or one 68k CPU? I am asking because the two sides seem to be so important.

[kur4o]

I am not sure but the Vin Cal id and some info is stored at the processor eeprom or some other memory chip on the board.

Actually it is two separate computers inside connected with spi interface with separate processors and memory chips.
The board that controls engine operation has two cpus. Possibly one is for maf calculations only.
T-side controls transmission and make BLM calculations and diagnostics.
E-side calculates spark, air and fuel.
T-side and e-side are flashed separately and it is possible to flash just one side, but no software I know has that feature.
Ram is mapped in the memory chip form $0000 to $2000

[Faceman]

Thanks for that info. Was the schematics of the two boards already reverse engineered ? Maybe there are even chips holding data that are not mapped to the BIN file. It also would be very interesting to know how the data looks like in the flash chip (or chips?) if read out externally. Is it possible that VIN and other stuff is stored in the CCM / BCM and retrieved from there during read procedure? Or maybe the PCM holds a copy.

[RobertISaar]

VIN is stored in the EEPROM that is internal to at least one of the 6811F1 processors. the 93-95 P66 V6 is the same way. a couple of other items(calibration part number is one) are also stored in there with the P66 V6 application, but I imagine the LT1 code does the same.

[lionelhutz]

I have changed the VIN before, but I haven't seen it as part of the bin file. I've always had to be connected to the PCM to change it.

[Faceman]

A Tunercat bin file contains the VIN (ASCII encoded, so easy human readable) at $e24
But I've never tried to change it and check if it really gets written into the PCM.

[RobertISaar]

the VIN is located there in the BIN due to the way the upload program works.... it just dumps values sequentially from a starting address to the end of the PROM, including the processor's EEPROM range.

[Faceman]

Robert do you know the address ranges in the bin, that are used for which "data source" in the PCM? Is there data in PCM that cannot be accessed via ALDL? And how about writing? Which parts of bin can be edited and are really written somewhere in the PCM?

[lionelhutz]

Tunercat doesn't give the option of checking or changing the VIN when editing the bin. There must be a reason it has to be done live while connected to the PCM. It's not possible to change part of the flash memory chip so the VIN changing routine is writing somewhere else besides into the bin file. I'm betting the "real" VIN is stored in a processor like Robert mentioned.

The bin contains the data in both of the flash chips. When I fixed my bricked PCM I split the bin and put 1/2 into each flash chip. So, reading the bin doesn't pull from other memory locations in the PCM like you keep asking about.

[RobertISaar]

i'll have to dig around to see if I kept any notes, but what I was able to find, it was due to the processors being normal 68HC11F1 models... if you step through the beginning of the program when the power-on RESET procedure is done, you can find out where the processor allocates its on-board memory. knowing that the F1 has 512 bytes of EEPROM built-in and seeing that the VIN is stored a little above $E00, it's a good assumption that the EEPROM is mapped from $E00 to $FFF. so, anything you see in the BINs that is in that range, it was pulled from the processor's EEPROM during the read operation. you can read EEPROM as if it were normal RAM or a register, but writing to it is another thing. the pink book explains that process fairly well.

[Faceman]

Maybe the config register is also somewhere in the BIN? The config register tells where the EEPROM is mapped to. Per default from the data sheet it's $FE00–$FFFF.

It is for sure, that the bin contains other data, not only data from flash chips, because there is data that changes with every readout, so obviously RAM is included. That also means, there is memory on the flash chips, that is never used, because it is not addressed by the MCU (can imagine a multiplexing mechanism, where external RAM is explicitely addressed, but I am not yet so deep into the data sheet).

The problem is, that this MCU is so highly flexible... and I do not know, how GM configures it. I am about buying such a PCM and I will disassemble it.

[Faceman]

Ok, I just had a look at the CONFIG register, that seems to be contained in the BIN file at $103F, the value is $0B, means 00001011b, so EE0 to EE3 are all zero, so EEPROM location is:
$0E00 – $0FFF
see http://cache.freescale.com/files/mic...MC68HC11F1.pdf table 4-4

So Robert you are absolutely right !

[RobertISaar]

that sounds about how I'm remembering it. I guess with the BIN pulling the registers, you don't need to step through the beginning of the code instruction by instruction to see what eventually got written. certain registers will change, but something like EEPROM location certainly wouldn't.

as far as the mux'd addressing, I've never had a 94-95 LT1 PCM opened up, so I can't say for certain. the 93-95 3100 PCM uses dual 32KB flash PROMs and doesn't have to try to overlap PROM space with any external addresses the way that the LT1 PCM has to with its 64KB PROMs.

[Faceman]

Now I have a quite good understanding of how it all works theoretically in this type of PCM. That special config register is in EEPROM, so I think it does never change. GM decided how they want to use the memory map and it's fixed. What I still couldn't figure out is, what happens during startup of the engine, what type of reset is used, where does the MCU get it's starting address from for executing code and so on.
If I am lucky I will get a PCM soon for playing...

[RobertISaar]

you may want to grab a copy of the 68HC11 programmer's reference manual.... it leaves out very little of the operation of a 68HC11F1 since it was written based on an earlier model, but I have managed to get ahold of an F1 supplement that has shed some light on things that were skipped in the original reference manual.