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
Posting Permissions
Reply With Quote
Bookmarks