1997 F-Body Tools

[Tom H]

Hi,

Going back a week or so, we were discussing ways to prevent creating bricks when programming is interrupted for some reason. I had the idea to use the on chip EEPROM that is part of the MC68HC11F1 used on the OBDII LT1s for this. Learning about how GM uses the part and all caused me a bit of pain. Several times I bricked my module until I came to understand more about how the EEPROM is used.

Speaking of just the TSide for today...
Turns out that address $0E35 in the EEPROM is used by the code in flash to determine if the module has been set up or not at the factory. First thing I did was to erase the EEPROM which made this location $FF. Once erased the OBDII will not respond to commands except one mode. After thinking I had junked the PCM, I started looking at the code to see what had happened. Turns out that the location at $0E35 is programmed using mode $3B. I must have spent hours tracking this all down. One command: 4C 10 F0 3B A0 00
and I was back in business. Not the end of troubles though.

I wrote a loader with almost zero features to place in the 512 byte EEPROM. I mapped a hole in my code at $0E35 so that my password would still work. The code does however fill the EEPROM to the brim and thus overwrites the password. No troubles there though because I knew where the pass (and seed) were stored and just changed the password I was sending.

I first tested the loader at the standard location in low memory. Then re-assembled for use at address $FE00. Once placed at that location it replaces the vectors that are normally provided by FLASH. I wrote the loader such that there is space at the top for these vectors. On startup the vectors point to the EEPROM and execution starts in the loader.

OK, so what does all this do for us? The loader is installed by re-programming the EEPROM. Once this is done the PCM is brain dead on restart except for one function: filling it's RAM memory with code that you send it. In our case if we wish to re-program the flash, we would send down a programming/erase/verify routine to the ram. By running this code out of ram, the entire flash can be re-programmed. In the case of an interruption to the programming, the loader is still in EEPROM and ready for you to try again. Used properly, it should prevent any bricks.

Next post is on the use of bootstrap/test mode. Want to separate the topics just a bit....
Tom

[Tom H]

Hi,
Going way back there were some details given regarding repair of bricked PCMs. I have had reason with the re-programming project to make use of this. I wanted to document some bits here as this efforts may make it necessary for others to have this ability...

First up, here is the schematic of the hardware:
Schematic.jpg

I want to focus on the USB <--> Serial cable for a moment. Cables using the Prolific chip and it's clones are a problem. Microsoft goes out of it's way to mark your driver obsolete every time you change anything or they do an update. You can continue with it if you don't mind fighting with Microsoft all the time. Even then, depending on if your cable is a clone of the prolific part (most are) the baud rate is WAY off in most cases. Remember that a 5% error in baud rate builds over the 10 bit word and by the last bit is 50%. Probably doesn't work or at best is unreliable.
I have found that cables based around the CMD340 chip set work a treat. No driver issues. Baud rate with less than 1% error. I did a hack test on the ones I got for some rates of interest:
1,890, 8,192 and 12,288. These are the rates useful for work on the LT1 PCMs. Using a frequency counter I sent 'U's to the port and found better than 1%. I believe most of the error is from my terminal software. These cables cost $5 and I am going to purge all the half working stuff I own.

Ok, so that is the cable side of things. The rest of the schematic is just pulling pins low to change the processor startup mode to bootstrap, pull up the data lines because wire or is default and so on. The connector to the board I use can still fit in the case. They are just wire wrap header pins (.025 square, 2wide by four long). Here is a picture:
IMG_1985.jpg
The connectors are not numbered on the PCB, nor is there a square pad to indicate pin 1. I selected the following for pin out.
IMG_1984.jpg
Last up is a picture of my setup for bootstrap
IMG_1981.jpg

With this setup and some software you can overwrite both flash and EEPROM. It's just opinion but I don't think FLASH parts should ever be socketed or replaced. Once the conformal coating of the board is broken or a socket added I think the reliability will be poor.

When writing code for the loader I needed this setup to recover the PCM... twice I am sad to say.

-Tom

[Tom H]

Hi,
Question for you all... In my disassembly it is marked where the checksum is located for the TSide ($2015). What does this checksum cover? Is it the calibration, calibration + code, sum of E +TSides, both banks ????

If someone knows, I won't need to go back through the code to find out.

Cheers,
Tom

[kur4o]

It should cover both banks, from checksum address to end of bin. 16 bit byte sum.

[Tom H]

It should cover both banks, from checksum address to end of bin. 16 bit byte sum.

Thanks! I found my problem in an unexpected place. The loader I planned to use to prevent bricking puts the EEPROM in the upper memory at $FE00. Since it overlays the flash, my checksum is wrong. Worse, it will prevent the programming of the upper flash.

Now I just need to see if I can find a solution. I can't move it because it supplies the vectors. Can't turn it off because that's in the config which is protected. HMMMmmm, Kind of makes me think of the first rule of holes...

-Tom

[Tom H]

I can't move it because it supplies the vectors. Can't turn it off because that's in the config which is protected. HMMMmmm, Kind of makes me think of the first rule of holes...
-Tom

Use of the EEPROM as a loader is not workable. In expanded mode there is no way to move or remove the EEPROM from the memory map. It hides the last 512 bytes of flash. I have looked hard, there is no workaround that I can find. In fact the EEPROM used as a loader works a treat for everything but those last few bytes on both pages.

I need to look further into the solutions already in place for the earlier PCMs OR ??
-Tom

[kur4o]

If it doesn`t work as expected you can always put it on hold for now, and focus on actual writing, reading operation. Than when that is nailed, we can look for brick safe solution.