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:Originally Posted by kur4o
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
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
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.
It might be cleaner to have three routines within the app.
- Install boot loader
- Program flash
- Remove boot loader
Once boot loader is installed, the PCM would be non functional until you remove it. With the loader installed it would always look to fill the ram. Your point of the EEPROM size is the most difficult but the factory loader is done (using spi) in $36 bytes. DLC is more complex as is the SPI for the ESide.
I just checked up on the ESide and find that the boot code is the same. We could use the tag to open up the protection (BPROT) and program the config.
->Can't wait to try this<-
Sad I didn't think about this earlier. Good thing Joel brought this up when he did. Probably needs to wait for second revision of the code cause I am too far along now, almost ready for testing.
-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)
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"Code:SLOOP JSR(somewhere) LDY #$FF DECY BNE(somewhere) RET
-Carl
Hi!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)
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"Code:SLOOP JSR(somewhere) LDY #$FF DECY BNE(somewhere) RET
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
I'll say a small prayer for the substrate.
-Carl
Prayer? We need more of a chant.I'll say a small prayer for the substrate.
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
Code:************************************************* * 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!
Last edited by Tom H; 01-21-2024 at 07:36 PM.
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 :)
-Carl
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
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
-Carl
Hi In-Tech,
I wrote the loader and now have it working, but have run into a problem with my assembler. I have variables that I map into the internal ram starting at 0. My program is resident in EEPROM at $FE00 and above all the way up to the vectors.
The assembler output that I use is SRecords. It refuses all my attempts to get it to create the final execute record at the right place. It always wants to run from zero. NOT from the $FE00. Would you happen to know what magic incantations are required in the code to get it to make the correct S9 record? I have tried all the commands that have any promise in the manual. The assembler I am using is ASM11.
As it is each time I assemble, I need to go into the file change the execution address manually and re-calc the checksum. ??tools??
-Tom
Hiya Tom, I will have to dig to find this older stuff. I'm surprised you are using MotS, Intel hex has always seemed good but I have never worked with your box. If you would like, PM me the code to assemble and I will attempt in MotS.
Btw, it's Carl, as noted in my sig line :)
-Carl
Posting Permissions
Reply With Quote
Bookmarks