1997 F-Body Tools

[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 :)

[Tom H]

0 stuff, brutally burning the bit flips from 00h-FFh a

Hey Carl,
Am I confused? The tight loop is just execution waiting for the watchdog/cop to hit. At this point it is just setting a ram location and resetting. When it reboots the GM software leaves the BPROT open for access when it sees my tag. At that point, I can mess with the EEPROM and CONFIG register to get the desired results. Since it is just execution not programming tight loop is OK.

I was sure you were pulling my leg

-T

[In-Tech]

Hi Tom,
Yeah, I was having a little fun about the substrate :) This situation has no worries, it just reminded me when I wrote a "burner" to test. The spec sheet said it was only good for ~100,000 writes. I thought BS and did some testing for myself