1997 F-Body Tools

**kur4o** · 01-16-2024

If you want to play it really safe on bricking, I can share how it was done on 94-95 lt1. EEprom can be used for easier bin identification since it have vin and Os id.

A mini bin was created that contains vectors reset code and communication code. Than we tested if this mini bin actually communicates and can be recovered.
On flashing, first was flashed that mini bin and later rest of the bin. Chances you had a hard brick was minimal even you completely loss power.
We also skip FFs to speed code flashing, not sure how viable is this with big $400 long messages. You can eventually decrease the message length to accommodate something like that. This can be implemented when you have solid flash code as a phase2.

**steveo** · 01-17-2024

in flashhack i make reading the 68hc11's onboard eeprom optional, but i would highly reccommend it.

it's also traditional to read the ram region as it is mapped, but i skip that by default and just leave 0 there. most users appreciate that.

i think flashhack's anti bricking logic is probably worth copying when you have the rest figured. me and kur4o did a lot of testing and research there and it is excellent, it leaves a very short window or just a few seconds during which the ecm is left unbootable, and even within that window, if you don't cut power the kernel stays loaded in ram and you can retry, so the only way you could fail is to cut power during that few second window. very unlikely.

using the eeprom is another option if you could write a compact enough kernel to fit in there, however that eeprom (at least in EE) was locked via the config register by GM, so during the first flash it is impossible to write. you would need to patch the bin's init code to alter the config register, write the bin fully, then reboot the ecm to have write access to that area (which i have done successfully, but it means your first write would always be at risk, right?) my flash tool writes that entire area as well, i figured one day someone might want to relocate a table there and allow really quick and safe updates to it

**Tom H** · 01-17-2024

Originally Posted by steveo

using the eeprom is another option if you could write a compact enough kernel to fit in there, however that eeprom (at least in EE) was locked via the config register by GM, so during the first flash it is impossible to write. you would need to patch the bin's init code to alter the config register, write the bin fully, then reboot the ecm to have write access to that area (which i have done successfully, but it means your first write would always be at risk, right?) my flash tool writes that entire area as well, i figured one day someone might want to relocate a table there and allow really quick and safe updates to it

Interesting that locking of the register... I think we can get around that.

Writing the config register is locked into it's state once 64 eclocks have been run. Looking at the software (at least for '97) the code does this:

Code:

; VECTOR TO $4C46

		ORG $4C46

LOC_4C46:	JMP	$6621

		ORG $6621

LOC_6621:	LDS	#$1FFF		;  SET STACK AT TOP OF EXTERNAL RAM

		LDAA	#$01		;  INTERNAL RAM AT $0000, REGISTERS AT $1000
		STAA	$103D		;  CPU INIT

		LDAA	#$99		;  CONFIGURATION OPTIONS
		STAA	$1039		;  CPU OPTION

		LDAA	#$03		; TIMER CONFIGURATION OPTIONS
		STAA	$1024		; CPU TMSK2

		CLR	$1035		; BPROT: PERMISSIONS TO WRITE EEPROM/CONFIG REG

		LDD	$201F		; $0A02

		LDAB	$0200		; EEPROM PROGRAMMING TIMER
		CMPB	#$55		; LOOK FOR TAG: $55
		BEQ	$664B		; FOUND, NO BLOCK PROTECTION

		LDAA	#$10
		CMPB	#$AA		; LOOK FOR TAG: $AA
		BEQ	$6648		; OVERWRITE PROTECTING BPROT

		LDAA	#$11		; OVERWRITE PROTECTING PTCON, BLOCK 0

LOC_6648	STAA	$1035		; WRITE BPROT

LOC_664B	LDAA	#$15		; CONTINUE WITH BOOT

Downloading to ram a small routine that sets location $0200 to $55 will make the next run un-protected. The normal case is protected as you suggest. The download software need be only a few instructions. First set the tag location to $55, then a tight loop with no COP resetting. Once the COP expires (some nominal delay) a second routine can be run to program the EEPROM and OPTION registers. From then on all resets should go to the vector stored in EEPROM.

I think the programming can be done with no exposure to brickage. Still the problem of writing a kernel, but it need only be a boot loader for the programming software.

What have I missed? I hope to test this out v soon.

-Tom

**Tom H** · 01-18-2024

Hi,

This morning I tested the idea of reprogramming the EEPROM to hold some sort of non-volatile loader while programming. This *should* prevent making bricks even if the power is removed half way or some other interruption occurs.

This can be done in this way, there are just a few steps:

Record the content of EEPROM. This has been done in the software I am currently writing.
Run the code below to keep BPROT bits clear. This will no permit you to reload the CONFIG register and place the EEPROM at the top of page overlapping the flash.
Run code to program (not written yet) the EEPROM with a boot loader in case of programming interruption.
Turn off the EEPROM while programming to permit access to the top of FLASH.
When programming is complete, restore the EEPROM, reset the CONFIG register as normal

Once this is done, the code will always run the code in EEPROM, not the regular stuff in flash. At that point you can load into ram the programming and comms routines.

Code:

        ORG $0000

ENTRY:    LDAA    #$55        ; TAG VALUE
          STAA    $0200        ; SAVE
SLOOP:    BRA    SLOOP        ; SUICIDE BY COP

Thoughts?

-Tom

**kur4o** · 01-18-2024

This sounds like the eeprom will contain all the flash logic and will switch to eeprom loop in case there is no data on main flash. Like mini boot loader.
ON flashing you can even use code from there and only upload flash content.

On sure how it will work on eside. Might need some reconfiguration and possibly one time patch. But it will be totally bulletproof, once you figure how to switch between main flash and eeporm boot logic.

**Tom H** · 01-18-2024

Originally Posted by kur4o

This sounds like the eeprom will contain all the flash logic and will switch to eeprom loop in case there is no data on main flash. Like mini boot loader.
ON flashing you can even use code from there and only upload flash content.

On sure how it will work on eside. Might need some reconfiguration and possibly one time patch. But it will be totally bulletproof, once you figure how to switch between main flash and eeporm boot logic.

I was thinking more like:

Install the loader in EEPROM and program the CONFIG to place it top of memory. This means the vectors are all replaced with those in EEPROM. Now on boot, the CPU takes vectors from EEPROM which restart at the bottom of EEPROM. address would be 0xFE00.
From there the loader will fill the ram, both internal (0x0000 -0x03FF) and external (0x1810 - 0x1FFF) with the flash routines. Once the ram is initialized control will transfer to the ram routines.
The ram routines then disable the EEPROM and execute the programming routines.
Once a successful programming is done, re-program the CONFIG and EEPROM back to their normal function.

As usual the ESide is a little more complicated but the same principal should work. Once the loader is installed the TSide would need to be alive to pass data through the SPI.

I didn't say it would be all easy, but I think it is do-able. I will play with the concept a bit more.

-Tom

**steveo** · 01-19-2024

the actual logic will be difficult and i believe will make your plan unworkable, as the original bin that is booted from when starting the flash process has already altered and locked the config register. the config register can only be set once, you can't just alter it at runtime. this means your plan requires altering the original bin so you can mess with the config register on ecm boot at least once, which would require at least one 'unprotected' flash

**In-Tech** · 01-21-2024

Originally Posted by Tom H

Hi,

This morning I tested the idea of reprogramming the EEPROM to hold some sort of non-volatile loader while programming. This *should* prevent making bricks even if the power is removed half way or some other interruption occurs.

This can be done in this way, there are just a few steps:

Record the content of EEPROM. This has been done in the software I am currently writing.
Run the code below to keep BPROT bits clear. This will no permit you to reload the CONFIG register and place the EEPROM at the top of page overlapping the flash.
Run code to program (not written yet) the EEPROM with a boot loader in case of programming interruption.
Turn off the EEPROM while programming to permit access to the top of FLASH.
When programming is complete, restore the EEPROM, reset the CONFIG register as normal

Once this is done, the code will always run the code in EEPROM, not the regular stuff in flash. At that point you can load into ram the programming and comms routines.

Code:

        ORG $0000

ENTRY:    LDAA    #$55        ; TAG VALUE
          STAA    $0200        ; SAVE
SLOOP:    BRA    SLOOP        ; SUICIDE BY COP

Thoughts?

-Tom

Hiya Tom,
At a glance, the SLOOP is an incredibly tight loop especially in eeprom and not flash.
In my mind, if you have room, I am thinking a JSR to use some ticks as well as more ticks using the stack, then a simple LDY(or anything not being used or needed later before loop quits)

Code:

SLOOP    JSR(somewhere)
    LDY    #$FF
    DECY
    BNE(somewhere)
    RET

It's been a bit since I did assy, forgive. I think this will use up some ticks and of course can be enhanced or tuned from there. NOP's. I'm sure you get the "jist"

**Tom H** · 01-21-2024

Originally Posted by In-Tech

Hiya Tom,
At a glance, the SLOOP is an incredibly tight loop especially in eeprom and not flash.
In my mind, if you have room, I am thinking a JSR to use some ticks as well as more ticks using the stack, then a simple LDY(or anything not being used or needed later before loop quits)

Code:

SLOOP    JSR(somewhere)
    LDY    #$FF
    DECY
    BNE(somewhere)
    RET

It's been a bit since I did assy, forgive. I think this will use up some ticks and of course can be enhanced or tuned from there. NOP's. I'm sure you get the "jist"

Hi!
Tight loop is actually intended. For the remaining duration of the COP (CPU or PRU) the CPU keeps accessing three locations in repetition. Presents no troubles, I have tested it well. The loop could be larger but the intent would remain: to reset the CPU without affecting location $0200. Once reset it gives the code the ability to change the CONFIG register stored in EEPROM.
Probably the smallest program I have ever written...

-Tom