1997 F-Body Tools

[In-Tech]

Hiya Tom, I will have to dig to find this older stuff. I'm surprised you are using MotS, Intel hex has always seemed good but I have never worked with your box. If you would like, PM me the code to assemble and I will attempt in MotS.

Btw, it's Carl, as noted in my sig line :)

[Tom H]

Hi Carl,

Here if the loader file we have been talking about. See attached

-Tom

[In-Tech]

Thanks Tom,
I mentioned PM in case you didn't want if public. Man, shit ton of equates in there I'll have a gander tomorrow :)

[Tom H]

Thanks Tom,
I mentioned PM in case you didn't want if public. Man, shit ton of equates in there I'll have a gander tomorrow :)

Thanks Carl.
I am writing this tool for everyone, it's all public.

I added a line using #S19WRITE to the end of my file. This generates a text version of the S9 record. At least I only need to delete one line. It's a bandaid solution. I hope you can find better.

-Tom

[kur4o]

If you fill with zeroes the extra blank space, it will not interact with checksum and maybe it will get aligned properly. Not the best solution but it will save some effort.

[Tom H]

If you fill with zeroes the extra blank space, it will not interact with checksum and maybe it will get aligned properly. Not the best solution but it will save some effort.

Code is OK... loading ok, working ok. Rub I have is that the S9 record which is the "go execute here" address points to $0000, not where the code is. Bandaid is that I manually calculate the S9 record and put the text in the SRecord file. Then all I need to do is delete the S9 produced by the assembler. I am sure there is something I am doing that is preventing the assembler from working. This is just a tool though and I don't want to spend any more time than necessary fighting with it. Some day I may trip over the answer...

The idea of reducing the probability of bricking a module is the motivation for all this. I spent some time on it and so far I can:

• Unlock the EEPROM
• Re-program the EEPROM content with the loader

All that remains is the bit where I re-program the config to have the EEPROM replace the startup vectors. Plan to try that over the next hour or so. Fingers crossed

-Tom

[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