Rewriting boot EEPROM contents on the fly
cmd
Posts: 5
I'd like to do the following:
1. Have a LPC1114 MCU hold the Propeller in the reset state by asserting the reset pin
2. Have it reprogram the 32K EEPROM the Propeller boots from using the LPC1114's I2C interface during that time.
3. Release the Prop from reset so it will boot from the newly-programmed EEPROM.
4. Once my application is loaded from EEPROM, reuse P28 and P29 for any future I2C communication with the LPC1114 with the Prop as a I2C slave device.
I've read in other forum posts that the Prop boot sequence controls the I2C bus in a non-compliant way by directly driving the SCL and SDA pins high. I can make the LPC1114's SCL and SDA outputs high impedance so the Prop can control the bus without interfering, which I believe solves that problem. This allows the Prop to be the only I2C bus master while it boots. But are there any other issues to be concerned about in this arrangement?
Most importantly, is it a safe assumption that the data I program the EEPROM with comes directly from a ".eeprom" file that PropTool generates? If not, where can I find information about the format of the data in the EEPROM?
1. Have a LPC1114 MCU hold the Propeller in the reset state by asserting the reset pin
2. Have it reprogram the 32K EEPROM the Propeller boots from using the LPC1114's I2C interface during that time.
3. Release the Prop from reset so it will boot from the newly-programmed EEPROM.
4. Once my application is loaded from EEPROM, reuse P28 and P29 for any future I2C communication with the LPC1114 with the Prop as a I2C slave device.
I've read in other forum posts that the Prop boot sequence controls the I2C bus in a non-compliant way by directly driving the SCL and SDA pins high. I can make the LPC1114's SCL and SDA outputs high impedance so the Prop can control the bus without interfering, which I believe solves that problem. This allows the Prop to be the only I2C bus master while it boots. But are there any other issues to be concerned about in this arrangement?
Most importantly, is it a safe assumption that the data I program the EEPROM with comes directly from a ".eeprom" file that PropTool generates? If not, where can I find information about the format of the data in the EEPROM?
Comments
BTW... you don't need the EEPROM file; the BIN file is what gets transmitted from the PC to the Propeller on download. The purpose of the EEPROM file is to create an image for an EEPROM programmer (allows programming of the EEPROM prior to installing in a high-volume production situation).
I would let the ARM become the I2C slave and dispense with the EEPROM. That way you only need the .eeprom image. However you mentioned the LPC1114 which only has 32kB of Flash anyway, where do you intend to keep a copy of the Prop's image unless you are using the ARM as a boot channel, in which case you need the EEPROM and more software.
IOW, you should be able to do what you are trying with just the Propeller.
Seems to me like there is an awful lot that can go wrong with doing what you are trying, but more importantly, it seems positively nightmarish to troubleshoot any problems that DO crop up.
I'm really just wondering. What would maybe be cool would be to have the LPC serve as the eeprom itself, where you would select which program to load into the Propeller and the LPC fetches those bytes from a monster eeprom holding many programs and spoofs the Propeller into thinking that the LPC is actually a 32kb eeprom.
If that made any sense at all.
With the old BS2 I purchased a "Stache" device that held 16 programs that you could select which one to load and program the BS2. Worked really nice actually. Is this something like what you are going after?
http://emesystems.com/stache.htm
ETA- Such a device would be AWESOME for the propeller.
http://www.robotworkshop.com/robotweb/?page_id=578
I still have the PCB's available if you need one.
Robert