Hi Carl,
Here if the loader file we have been talking about. See attached
-Tom
Hi Carl,
Here if the loader file we have been talking about. See attached
-Tom
Thanks Tom,
I mentioned PM in case you didn't want if public. Man, shit ton of equates in thereI'll have a gander tomorrow :)
Last edited by In-Tech; 01-26-2024 at 05:26 AM.
-Carl
Thanks Carl.Originally Posted by In-Tech
Thanks Tom,
I mentioned PM in case you didn't want if public. Man, shit ton of equates in there
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
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
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
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
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
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
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
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.
yeah you really need to stop the scope creep and just get a working full reprogram even an unreliable one. eehack never had any of the extra safety measures and it was everyones favorite flash tool for like half a decade. it barely bricked anything. we can definitely help you with the logic that we've put into flashhack. it's insanely reliable, like there is a less than 10 second window where if you disconnect power from the ECM it would be unbootable, outside of that it's recoverable.
Not sure if it is scope creep... Loader used all the same OBDII structure for commands. Most of the time spent is still of value. Target changes from my loader to GM's code and the module Kur4o provided. For sure I learned good lessons about my assembler and the way it mishandles the S9 record. In this case mishandles=not what I expected, function of S9 isn't well documented. Assembler isn't well supported as the author passed away.
Currently, I have the module loading and doing some prelim stuff, turn on/off vpp, measure voltages. Task at hand is creating the code that can be loaded via bootstrap, morph into special test mode and run that programming module. That way when the FLASH goes away... zeroed, erased and so on I can still step through the programming and/or recover the PCM if I need to.
I am close... probably even try programming TSide later this week.
-Tom
Posting Permissions
Reply With Quote
Bookmarks