A similar method to try without the eeprom is: There are three code spaces in flash. The first is the bootloader, the next two are the user program areas. On powerup the device goes into the boot loader, which does the following on bootup: * Checks a status byte/word that indicates which user program areas are "working", and which one to boot by default. * Does a complete CRC check on the user program that is set to boot by default * As long as it passes, it runs the code in that user area * if it doesn't pass, it checks the status byte to see if the second area is listed as working * if it is, then it checks the second user area CRC * If that one passes it starts executing code from there. * if the CRC fails or it's listed as not working, then it goes into a bootloader command mode so it can be reprogrammed. Note that it will also not start a program listed as "not working" even if it's the default boot. Also the default boot can be the bootloader. Also there may be a bare metal bootloader that is triggered if the primary bootloader itself fails a CRC, or to update the bootloader. This one is more dangerous since it doesn't come with some interlocks mentioned below. The user programs, upon receiving a "update" command go to the bootloader command mode. The bootloader command mode is a section in the bootloader that allows some other entity to check the current status of the two user programs, change the status, and read/write in either area. The key here is that this procedure will not allow you to write to any memory that has a status of "working" without changing the status to "not working." Further, it won't let you change the status of one or the other user program unless the other program has a status of working (ie, one must be working at all times). It won't change the status from not working to working until after a CRC check. The CRC can be stored with the programs, or in a seperate area. This pretty much takes care of any circumstances you might find the chip in. Reboots during the updates, etc are all handled appropiately. The external program that talks to the chip must be aware of the current state and any interruptions, so careful attention must be paid to the protocols used in each case since a sudden reboot may take the chip out of programming and into normal operation. Further, the microcontroller is not left in an ambiguous bootloader mode if the user gives up on updating the firmware after the 34th try. The bootloader, as usual, should include the attempt write of block, attempt read of block, verify, goto next block cycle. This will enable the program loading the update into the chip to speed the process up if an interruption occurs, since it knows where it left off and can verify all previously written data upon entering the bootloading state again - unless the program updating the chip also experiences a reboot. There are other methods to fix that problem if it is expected, but worst case it does a full update. There are other things one can do to make this more robust and/or speedy, but this is a fairly reasonable method. I may have missed something so go over all the cases and make sure it meets your needs. -Adam On 4/6/06, Steve Lauziere wrote: > Ok, let me see if I can spell out my exact thinking on this based on > what you have told me: > > Prereqs: > -Bootloader is loaded on device > -Device is currently in user mode, and I want to update the > user-space firmware > > Execution: > -User-space firmware receives UPDATE command from host (SBC) > -User-space firmware writes 0xFF to last memory location > -User-space resets device (most likely with RESET) > -Bootloader executes > -Bootloader receives an initial message from host (SBC) and ACKs > for start of firmware update > -Host sends 8 byte packet of firmware > -Bootloader compares CHKSUM, writes 8 bytes to flash, and ACKs > -Else bootloader NACKs, and host resends packet. > -Repeat until all data sent... > -Once Host is done, sends FINISH message to bootloader > -OPTIONAL: (bootloader calculates CRC of firmware in flash??) > -Bootloader writes 0x00 to last mem location > -Bootloader resets > > With this method, a power reset during transfer will cause the PIC to > power back up in "bootloader" mode. And the SBC will ping the > bootloader for commencement of a new transfer. > > I could possibly keep state of the firmware update progress on the SBC, > so I know where I left off in writing to flash. This gets kinda hairy > though. > > A few questions: > 1: I think my method gets around having another EEPROM with minimal > trade-offs. Thoughts? > 2: Using the last memory location for bootloader/user-space > state...This seems a little risky. How else could you initiate an > update? > > I guess if I had to I could tie MCLR and RB0 back to my FPGA I/O, and > control the boot that way (that is how Microchip's boot loader for 8722 > works) > > > -steve > -- > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist