Steve Lauziere wrote: >Bob Axtell wrote: > > >>I may not understand what you mean. If you are using a medium-range or 18F >>processor, you should be able to upgrade through the device's UART (serial) >>port. This only works for devices that are able to program their own >>internal >>program space; these include F876, F877, F88, many others now. >> >>I performed some consulting, studying what is realistically possible in >>the field. >>I found that the very best field upgrade schemes use a kind of >>"customer-based" >>serial port upgrade, because that simply expands the use of an item that the >>client is already familiar with. Making the customer use the standard >>ICSP scheme- >>even with a polarized connector- is a disaster, unless the customer is VERY >>electronics-savvy. The 13V flops around, can be inserted wrong, or can touch >>some PCB component... and it is all over. >> >> >> >This update is intended to be automatic. The PIC will be one part of a >large system. The system will be updated over ethernet, with a SBC >handling the updates to itself as well as other JTAG-compatible devices >(CPLDs, FPGAs). This SBC will need to update the PICs as well. It sounds >like UART transfer is the way to go since the PICs will be chained >together with RS485 or some other serial bus. I was just hesitant on >using a bootloader if there was a better way. Having some sort of "ICSP >bus" and implementing ICSP on my SBC sounds messy, and neither fun nor >elegant, anyway. I'm taking a look at AN851 right now to look for any >gotchas. > > Sounds like one of my casino networks. Aah, those were the days... I hope you are not running $Windoze on the SBC, its a quick way to commit business suicide. I've seen several people go under this way. .. >And I am using 18F, probably something like a 2525 or similar 28-pin device. > > > > >>>currently focusing on a design that would implement >>>Single-supply/Low-voltage ICSP on the host. I do need to research using >>>some sort of boot loader, as I am not sure how well the boot loader >>>would hold up against power interruption or other failure. >>> >>> >>> >>> >>> >>The way this works is as follows: The FIRST packet of words installed is >>a pointer to >>the firmware updater itself...so if the power is interrupted, the unit >>simply jumps back >>to the updater routine. Every time a packet gets installed, a >>status/address is written >>to the local EEPROM to state where things are at. >> >> >> >Are you talking about the UART/serial upgrade path? with bootloader >located in a boot block? I don't think I would want to field upgrade the >bootloader. > > No, During the time that you are upgrading the firmware, the product itself can't do anything else except upgrading, because except for the bootloader code itself, you have almost no good code available- it is in a state of flux. Bootloader code NEVER changes, ideally. >>To make the whole scheme bulletproof, the new firmware is first written >>into a temporary >>I2C EEPROM memory, so that CRC tests can be performed on it, and if >>anything fails >>during the firmware update routine, the bad section can be re-installed. >>When everything >>has been installed except the FIRST packet, which always points to >>the firmware updater, >>the FIRST is then installed, then the watchdog timer is FORCED to >>trigger (so the system >>will startup with a clean slate running the new firmware). >> >> >> >> >I may indeed use some eeprom for failsafe, but I would rather rely on my >SBC to handle CRCs and whatnot. My point in a previous paragraph about >some sort of watchdog signal was that I wanted to know how I can make >the system aware of a programming failure. Remember, this is intended to >be an automatic upgrade...I guess actually sort of autonomous as well. > > You will have problems if you upgrade only a few packets at a time, because your product will contain a mix of old and new firmware. You need some I2C or SPI EEROM to perform this kind of task. Otherwise, how will you KNOW that you had a programming failure? You can depend on a CRC during transfers, but a CRC on the overall data handles the case where power failed while transferring an unpacked packet into the memory storage unit, and it was therefore defective. If you use a 32Kx8 I2C EEPROM, you only use a mini8 package, smaller than a SOIC8. Let's go over this again. You have been sent all the new firmware data. Your server has also sent an expected CRC16 of the entire new firmware file. When you test it- and it matches- you are now CERTAIN that you have good firmware to install. You will then erase a small chunk of code memory (the F88 erases 16 words at a time) and then install a small chunk. Before you go on, you can read the new chunk to make sure it has been installed correctly. This process is repeated for every 16 words, until it is done. The VERY LAST 16-word chunk is installed at the lowest part of code space, i.e. where the program starts. >Thank you very much for the input, > > > Glad to help. This is a bit tricky; I didn't learn all this overnight. One has to think out EVERY step. >-steve > > > -- Note: To protect our network, attachments must be sent to attach@engineer.cotse.net . 1-520-850-1673 USA/Canada http://beam.to/azengineer -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist