if we need to standardize we should try to stick with what is already in use if possible, that way tunercat/jet dst bins will also work with whatever we do instead of having to convert between formats like we did with lt1edit/tunercattunerpro
if we need to standardize we should try to stick with what is already in use if possible, that way tunercat/jet dst bins will also work with whatever we do instead of having to convert between formats like we did with lt1edit/tunercattunerpro
I agree - no reason to change it if the data doesn't care and there's already a precedent.
OK, here we stay. I have gone through a bunch of the code. Seems like a straight forward implementation of Intel's quick pulse programming / quick erase. Makes figuring it out a breeze.
I am still working through the '95 but I imagine the '97 must be very similar. The routine that is named ERASE2_sub_31D in your file represents the first two blocks of the flow chart. The intent is to program the whole array to zero. Here is the commented code I come up with:
I assume the routines that are given between $0400 and $1810 are for the GM test gear. Planning to ignore...Code:************************************************* * ERASE * USE QUICK PULSE PROGRAMMING TO ZERO THE ENTIRE * FLASH ARRAY. AS PER FIG. 4 & 5 OF THE DATA SHEET ************************************************* 031D 9D 29 JSR @$29 ; INITIALIZE OC1: 20MS 031F 4F CLRA ; 0320 B7 03 68 STAA $0368 ; 0323 DE 12 LDX @$12 ; FLASH END ADDRESS 0325 08 INX ; 0326 09 DEX ; PROGRAM NEXT LOCATION 0327 4F CLRA ; INITIALIZE PULSE COUNT 0328 36 PSHA ; 0329 9D 26 JSR @$26 ; CHECK AND CLEAR OC1 032B 32 PULA ; 032C 27 0F BEQ $033D ; OC1 MATCH NOT SET 032E 7C 03 68 INC $0368 ; 0331 F6 03 68 LDAB $0368 ; 0334 C1 05 CMPB #$05 ; 0336 25 05 BCS $033D ; 0338 8D D0 BSR $030A ; SEND IN PROGRESS MESSAGE 033A 7F 03 68 CLR $0368 ; 033D 9D 1D JSR @$1D ; MAKE FLASH OE INACTIVE 033F C6 40 LDAB #$40 ; FLASH COMMAND SEQUENCE 0341 E7 00 STAB $00,X ; COMMAND: SET UP PROGRAM 0343 C6 00 LDAB #$00 ; 0345 E7 00 STAB $00,X ; PROGRAM LOCATION TO $00 0347 9D 17 JSR @$17 ; RESET WATCHDOG TIMERS 0349 C6 C0 LDAB #$C0 ; FLASH COMMAND: PROGRAM VERIFY 034B E7 00 STAB $00,X ; 034D 9D 1A JSR @$1A ; MAKE FLASH OE ACTIVE 034F E6 00 LDAB $00,X ; READ BACK LOCATION 0351 27 07 BEQ $035A ; SUCCESS, LOCATION IS $00 0353 4C INCA ; INCREMENT PULSE COUNT 0354 81 19 CMPA #$19 ; 25 PULSES 0356 23 E5 BLS $033D ; TRY AGAIN 0358 20 09 BRA $0363 ; PROGRAMMING ERROR 035A 9C 10 CPX @$10 ; FLASH BASE ADDRESS 035C 26 C8 BNE $0326 ; LOOP THROUGH REST OF ARRAY 035E CC 00 00 LDD #$0000 ; NO MESSAGE, SUCCESS ARRAY IS NOW 0361 20 03 BRA $0366 ; ZEROED OUT, READY FOR QUICK PULSE ERASE 0363 CC 06 06 LDD #$0606 ; MODE 6 MESSAGE: PROGRAMMING ERROR 0366 39 RTS ; DONE 0367 00 ; 0368 00 ;
-Tom
Hi,
I have completed my look through the FLASH programming code & commented the operation. The comments are best efforts only, I hope they are of use to you.
-Tom
Looking at the 96-97 code, I think I understand the Tside flashing. Once loaded, the Flash can be checked for manufacturer and device. Based on that an algorithm is selected. I believe in all our cases that will be Intel. Please let me know if anyone has AMD parts.
Once the part is known, it is programmed to all zeros before erasing it to the factory state ($FF). It looks as if there is about 1K of buffer in the PRU to pass the new data to. The buffer is formatted with three extra bytes. Bytes are target address in flash high, then low and last is byte count. In this suggested case, byte count would be 128 or $80. This would permit 8 buffers of $80 to fit in ram for programming. Total buffer size will be ($80 + 3) * 8 = $418 bytes total. I will propose that the address of the buffer would start at $1BE8 thus it would end at the top of PRU ram $1FFF. Eight calls to the programming routine would yield 1K bytes programmed. I wonder if there is anything to be gained by buffering 1K or if buffering 128 would be more straight forward. Your thoughts?
TSide page 0 ranges from $2000 - $FFFF. Since there is no need to program the first 8K, the buffer (1K) will need to be filled 56 times to complete programming the page. Similarly, page 1 ranges from $8000 through $FFFF. There is no need to program the first 32K.
The result of all this is that a 1K buffer needs to be replenished 88 times on the TSide. That is 704 calls to the programming routine.
Again perhaps filling a 128 byte buffer 704 times will make the code easier. I believe the slowest part of this will be the serial transfer from PC to PCM.
Trying to size the time it will take to program... We need to transfer 88K bytes. That is just over 90K bytes. Each byte is sent as hex digits (that doubles the byte count). With overhead of ID, Count....checksum, I figure that programming the TSide needs to move something in the order of 200K bytes PC to PCM. There will also be 704 replies if all goes well that need to be processed. From this crude figuring, it looks like about 250K characters need sending/receiving & processing. That looks to me like it might take 8 - 10 minutes.
Is 8-10 minutes reasonable & expected (or has my math gone off the rails).
I plan to try this out once my parts arrive from China. It takes so long to ship things... If this is a success, I will be able to suggest a way to reprogram a brick without de-soldering the FLASH. Still it won't be the easiest thing because it will access the test connector. This will require the PCM to be opened up and so on.
-Tom
The time you came up is way off. It will be like 1-2 min max in x4 mode.
Here is a list of simulated write with the commands send over the bus.
Chipid id used to identify the chip. It is always intel in these PCMs, the tool decides how to proceed if the chip is not correct. I guess the amd id is there so there isn`t a crash response if you try to program the wrong pcm. There isn`t any amd code to handle erase and write of amd chips.
Erase is done in 2 parts. First set all bits to 1. Second part turns all to 0 and than to 1. Something with intel quick erase. The routine manages erase exactly by the data in intel flash chip manual.
Note that each flash routines like erase, vpp, checksum, chipid and so on are loaded at 1810 buffer one by one. The bin upload buffer is at 1b00. The flash routine have built in $500 bytes length message.
The header before each uploaded block is
BD 18 1D 20 00 04 00
18ad is the start address of write routine.
2000 is the address where data will be programmed
0400 is the length of the data to be programmed
Usually 0-1fff area is not programmed at all. That also includes bank2 0-8000 area. Total data transferred is 88kb for tside.
Looking forward to this, and agreed that it currently is taking an insane amount of time to get anything from overseas unless you pony up for private couriers like DHL or FedEx. I order stuff from China and Japan often so I'm definitely feeling your pain right now.
I wonder if this is actually how new PCMs are factory-programmed. Obviously won't be a big deal if that's how we have to do it, but I've always wondered how the dealership did it. I somehow can't imagine your typical service tech cracking open a PCM and jumping onto some PCB pins to flash an EEPROM. Plugging into the PCM's external ports or the ALDL connector, though, those seem more likely.
In any event, carry on, I love everything you guys are doing even though it's for the OBDII cars. Both because I might end up owning one one day, and because lots of this will probably end up trickling down to the 94-95 PCMs too.
1990 Corvette (Manual)
1994 Corvette (Automatic)
1995 Corvette (Manual)
Hi,
There were several ways we used to handle flash way back when. Easy, was to have the chip vendor pre-program the parts on their final test. Downside was that last minute changes and variation of the final product would mess up the plan. You needed high volume (not a problem for GM) and some setup cash. Second thing that could be done was to program on the "bed of nails" tester. These things have a custom interface board with hundreds of spring loaded points. Through the points you can generate the wave forms to program the part. Often boards were tested and programmed in one step. Last and slowest was to move things in serial.
If I were guessing, I think that the program section would be factory program and the calibration would be programmed after. Where the calibration was not programmed (all FFs), just that section could be programmed on the line. The amount is smaller and would take only a minute or so. Well, so much for my guesses.
Earlier I wrote about a way to revive bricked modules. This should work for all the PCMs with this configuration 94 through 97. The interesting thing with the later cars is that we can now see the programming software and use it for updates. This should not require removal of the boards from the case, that is just for bricks.
C-Tom
Do the flash roms HAVE to be fully zero'd and 0xFF set first ?
I always thought it was a bit crap that you couldn't just flash individual cells & update them.
Mitch
'95 Z28 M6 -Just the odd mod.
'80 350 A3 C3 Corvette - recent addition.
Hi Kur40,
I need to clarify my post for you, it was at best confusing. For all the 94-97 PCMs a module that is truly bricked has no access to the data link controller. This means the J1850 is not available which means no x4 mode. In this case you need to use the SCI. I failed to note when the thought context switched between understanding of the later code and un-bricking based on sci.
You will notice two commands sent to the flash prior to erase...
The unlock feature is present only in the AMD part but is ignored by the Intel part for compatibility. From the datasheet and the '94-5 code you sent the erase sequence programs 0s then erases to 1s. I am not far enough into the 96-7 code to answer this, but expect it matches the Intel flow chart.Code:0200 9D 1D JSR @$1D ; MAKE FLASH OE INACTIVE 0202 86 AA LDAA #$AA ; AMD UNLOCK COMMAND 1 0204 B7 55 55 STAA $5555 ; INTEL IGNORES 0207 86 55 LDAA #$55 ; AMD UNLOCK COMMAND 2 0209 B7 AA AA STAA $AAAA ; INTEL IGNORES 020C 86 90 LDAA #$90 ; INTEL/AMD ID COMMAND 020E B7 55 55 STAA $5555 ;
Using 1K ($400) as a transfer size in a non-bricked 96-7 makes perfect sense. The GM implementation of J1850 permits long frames. This reduces overhead and speeds the process. In this case we should do the same, 88 downloads of 1K.
Going back to the bricked module flashing, to do this, the program needs to bootstrap a loader. When the loader is in place there will be a need to increase the baud rate. The bootstrap baud rate with the stock crystal works out to 1888 baud. Nice round number. When I wrote yesterday I envisioned moving to 8192 which is the standard. It may however be possible to move to a higher rate. Since this is single purpose and not integrated with the ABS/Dash/BCM/whatever, it will be interesting to test at 16384 or 32768. I need to look at the baud rate generator to see what faster speeds fall out of it that the rest of the module can support.
I am now off to look at the later code.
-Tom
The quick answer is no. You can clear, or set, even a bit of a byte. A little bit longer answer(see what I did there? ) is did you correct the checksum for the change you made and the CEL is flashing rapidly cuz it is very unhappy The software could do a compare of your old file vs new file and write just that. If much has changed, that would probably be futile, time wise. Shit, you could write an idling bootloader, disable the checksum, send executable packets and almost have real-time emulation. Ummmmm this IS freeware, right?
-Carl
Hi Mitch,
I have not gone through the AMD datasheet, but the Intel part requires a full erase. If a cell is FF, you can program it. Programming only takes 1s and makes 0s. If you program a location that is already programmed the result is not detailed in the datasheet but I would expect an AND function. The erase command does indeed program every bit in the array to zero before erase. This is done to make the threshold the same for all cells. When you do the verify commands an offset threshold is used to make sure the stored charge is enough for the life of the part. To be safe, erase as a whole and program locations that are FF only. The exception to the second part is what is done to erase.
It is my guess that the ECMs were programmed with all the code when the parts were soldered to the board and that calibration was added later perhaps on the assembly line. If you want to overwrite the calibration a full erase then program cycle is needed. It would be interesting if there are some folks who worked for GM at the time we could talk to.
-Tom
Hi Carl,
Thank you Carl, I missed a key bit of info. You can erase and erase verify a single loc. My bad.
-Tom
xxxxxxxxxxxxxxxxxIf you program locations that are not FF and 0s transition to 1s the cell is internally not correctly
xxxxxxxxxxxxxxxxxxprogrammed. This can result in heat sensitivity and worst case a bricking. Suggest we follow the data sheet,
xxxxxxxxxxxxxxxIf I understand what I am reading their caution is "CAUTION: The algorithm must be followed to ensure proper and reliable operation of the device."
xxxxxxxxxxxxxI have not tested this but: If a cell that is programmed 00 is written to FF and an erase verify command is run, I think you will find faults from time to time. The "margin threshold" won't be met.
Can you suggest where I can find programming directions that indicate programming 0 --> 1 is OK?
-Tom
Last edited by Tom H; 05-07-2020 at 02:33 PM.
Yeah but you could recalc the checksum & update that byte.
Steveo's EEHack does to a small extent
Great, will that be ready by tea time? :-)
I wish I knew more about these sytems, so I appologise if I throw in some random comments
There are a few of us who do follow these discussions even if we're sat here with a dumb expression on our face sometimes.
If the processors were ARM based, i'd be able to follow some of the dissassembly better.
Mitch
'95 Z28 M6 -Just the odd mod.
'80 350 A3 C3 Corvette - recent addition.
Bookmarks