1997 F-Body Tools

[Tom H]

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:

; 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]

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:

1. Record the content of EEPROM. This has been done in the software I am currently writing.
2. 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.
3. Run code to program (not written yet) the EEPROM with a boot loader in case of programming interruption.
4. Turn off the EEPROM while programming to permit access to the top of FLASH.
5. 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.

        ORG $0000

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

Thoughts?

-Tom

[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.

[Tom H]

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]

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

[Tom H]

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

Hi Steveo,

Original bin locks the EEPROM unless it finds a tag. On finding the tag the BPROT register remains $00 which permits writing of the config *for that boot only*. This is done less than 64 EClocks into the boot (EClock 36 if I remember right) I have already tested this with the stock bin. Kur4o brings up the ESide... I didn't look at that yet but full of hope.
The three instruction code in the earlier post makes this happen for the '97 code. There might be differences year to year. Again all this needs to be looked at before it can be termed a solution.
It is my hope that the original bin needs no mods.

If you have the time, wade through the code snips I posted. First snip shows the instructions run from EClock 0 through EClock 36. Second is code that is loaded into ram at $0 and run. Not written yet is the code loaded into ram that writes the EEPROM with a loader and modifies the CONFIG. If you find a hole in this please post for me.


-Tom

[kur4o]

I think the best method will be. Boot from vectors set in eeprom[exchange reset vector to some check code in eeprom], upon booting check if main vectors are present at end of file.if not branch to eeprom recovery code, if yes branch to main reset code.

[In-Tech]

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:

1. Record the content of EEPROM. This has been done in the software I am currently writing.
2. 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.
3. Run code to program (not written yet) the EEPROM with a boot loader in case of programming interruption.
4. Turn off the EEPROM while programming to permit access to the top of FLASH.
5. 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.

        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)

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]

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)

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

[In-Tech]

I'll say a small prayer for the substrate.

[Tom H]

I'll say a small prayer for the substrate.

Prayer? We need more of a chant.
Both Motorola and GM tested the heck out of these things, extreme cold & extreme hot. Elevated voltage and under voltage. Substrate will be fine.
Here is an example where GM used the same principal

*************************************************
* SOFTWARE INTERRUPT: VECTOR AT $FFF6
*************************************************
4C28    14 00 08    BSET    @$00,$08    ; SPERIOUS SOFTWARE INTERRUPT
4C2B    20 FE        BRA    $4C2B        ; LOOP TILL COP RESET HITS

Cheers,
Tom


NO wait their code is actually tighter than mine. They used relative addressing/branch. Their code beats on two locations where as mine beats on three!

[In-Tech]

Hahaha, chanting
Back in the 90's I ran some tests on some TMS370 stuff, brutally burning the bit flips from 00h-FFh and it took ~30,000,000 cycles before partial failure. Adding that short delay got it up to ~90,000,000. Fun stuff. Thanks Tom for the memory visit. Great work, btw :)