Flash Memory: Changing the Program
There should be a shrine to Fujio Masuoka in every embedded system development laboratory -- next to the one to 4004 architect Ted Hoff. For it was Masuoka in 1984 who invented flash memory and bailed out countless engineers without ever meeting them.
Without flash there would be no convenient way of reprogramming embedded systems in the field--so no easy post-sale bug fixes, no selling product before standards are ratified and no remote software upgrades. Given that most, if not all, microcontroller makers have flash versions in their range, how do you use it?
Basically there are two ways: connect the device to a programmer and push the program into it, or provide the program and request the controller to pull it in. The first option, pushing the data in using a programmer, is what has to be done in the factory to get a system going. This method can also be used for field updates if appropriate lines are brought to a connector on the equipment and someone is prepared to physically connect a programmer to it. In a minimalist stand-alone system, this may be the only reprogramming technique possible.
Once enough resources are available the second method, requesting the microcontroller to pull data in and program itself, adds remote and host-controlled reprogramming to the list of options. Pulling data in requires the microcontroller to have enough extra memory to hold a programming program. In this case if a failed programming attempt is to be survived, there has to be enough extra flash in the system to retain the existing version of code while new code is programmed in. This need for extra memory space is reduced if the device program is written in such a way that chunks of it can be replaced and tested with the existing program before the next new section is introduced. Then the overhead is only that flash required to save the largest new portion expected.
There has to be some form of protection against overwriting the programming code, or entering programming mode when the microcontroller should be getting on with its day job. Manufacturers have various methods for controlling memory access during programming. Hitachi, for instance, has three modes on its 0.18-micron devices. Boot mode is for initial factory programming and uses a serial port. This mode allows all flash, including 8K bytes of normally hidden boot flash, to be programmed.
User boot mode uses a previously written program on the hidden flash to program the rest of on-chip flash using any interface the boot flash program is capable of operating. User program mode does not use hidden flash, but a programming program in the remaining flash. A flash write-enable pin is available for extra protection.
Plain-old RS232 is a favorite for programming and reprogramming, but USB, Ethernet, CAN and the Internet can all be used. Both CAN and USB interfaces are available on-chip in some microcontrollers. Reprogramming code is available from chip vendors, third-party tool vendors and programmer makers. Real-time operating system companies, Wind River for example, frequently offer self-programming code within operating systems.