> >> So how do you re-bootload once Murphy has succeeded in bootloading an > >> image (with correct checksum) that refuses to bootload? > > > > The bootloader is only for the convenience of our customers, so any > > firmware images will be thoroughly tested before being released. In the > > lab or production facility we use a JTAG interface to program the > > devices. > > That approach is (of course) feasible if the chance of uploading a > non-cooperative image is 'sufficiently small' compared to the cost of > re-programming using another mechanism (or the loss of the device). Personally this is one reason why I like bootloaders that initialise at reset, briefly look for comms from a loader program, and if not present run previously loaded code. I often also write into the PIC application code a "soft entry" mechanism for starting the bootloader at will (often causing a watchdog timeout is the easiest/tidiest, depends if I need to maintain I/O staus or anything special) on receipt of an appropriate serial command. That way there is less for the user to do when upgrading firmware (even for me when developing ~ I hate reaching accross the desk to press a reset button or cycle power!). This also suits when a hardware reset or power on/off is not convenient or otherwise not possible, eg. target may be remotely located and code updated over internet. Oh, and the loader program I use also toggles the RTS line which in some cases I use to force a hardware reset of the PIC. In testing I intentionally crash the bootloading operation to see what ill effects it has. Most of the time, surprisingly, there is no problem, and the process can be easily restarted! It can of course mess up your application code, but not as much as you might think, thanks in part to the PIC's single word instruction width (other micro's go beserk easier it seems). If the application code does hang after a failed loading operation and doesn't allow the "soft entry" to the bootloader, power cycling or other hardware reset will initiate the bootloader and get things going again. In reality I very rarely see any cases where I need to re-load the bootloader, if I do this usually happens during development. What also aids robustness is having bootloader code designed so that it can not write over itself. Simple bootloaders don't check for this (minimses bootloader code size). Some rely on the PC side filtering out illegal addresses (errant code on PIC can still cause havoc). Even better if the area of memory the bootloader code resides in can be secured. -- Brent Brown, Electronic Design Solutions 16 English Street, St Andrews, Hamilton 3200, New Zealand Ph: +64 7 849 0069 Fax: +64 7 849 0071 Cell: +64 27 433 4069 eMail: brent.brown@clear.net.nz -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist