Navigation bar
  Start Previous page  4 of 6  Next page End Home  1 2 3 4 5 6  

Flash Microcontrollers Solve Problems
microcontroller allows for software errors to be corrected without expensive retooling.  Software can be downloaded
from remote locations via phone line or other media.  Then, the microcontroller can execute software that will
program its internal FLASH.  The alternative is to have a programming environment built into the application that
can be used to reprogram the device.  However, this means extra hardware and the microcontroller will be off line
while the programming is taking place.  While including extra hardware in a design to accommodate field
programming of the FLASH, it is not the best economic solution.
     One method to avoid external programming hardware is to put programming routines in the microcontroller's
own internal memory.  That is, the programming algorithms can be programmed into the internal FLASH.  There
are some applications where both programs and data are loaded into the flash.  The program may want to put
additional data into the FLASH.  Generally speaking, a microcontroller's CPU cannot execute software from a
FLASH module that the CPU is currently trying to reprogram.  If the goal is to write new data into a table or array in
the FLASH, the software doing the reprogramming cannot be resident in that FLASH module.  
This particular problem has been addressed in some microcontrollers by having more than one FLASH array.  By
putting a programming algorithm in one array, that software can be used to program the second array.  This
method is fairly straight forward.  The programming algorithm will always be resident in one memory array or the
other.  When the software in one array is programming the other, care must be used to make sure that the
programming algorithm also gets transferred.  Thus, one array or the other will always have a copy of the
programming algorithm.  The only disadvantage is that each flash module requires its own support circuitry, such
as row and address decoders, charge pumps, etc.  The extra circuitry translates into extra cost.  Simply from a
systems design standpoint, the idea of using software in one FLASH module to program another FLASH module
has been around for a long time and presents a very robust design method for updating software.
There are other options for using on-chip resources to hold programming algorithms.  Some microcontrollers have
data EEPROM.  This can be a small section of byte erasable EEPROM that is many times used to hold data.  In
some, but certainly not all, microcontroller architectures, it is possible to execute code from "data space" memory
elements.  If this is possible then programming algorithms can be executed from this space.  The general
methodology to use data space EEPROM for programming algorithms is to first save the data in this memory
element to FLASH, then reprogram the EEPROM with the programming algorithm.  When programming is finished,
the data space EERPOM is erased and the original data replaced.
Many times in extremely cost sensitive applications, there is not enough RAM in a microcontroller to hold an entire
programming algorithm.  This is another problem that has been addressed in the following manner.  For example,
the MC68HC908JK1 microcontroller incorporates a small ROM containing user callable routines to perform the
programming bootloader functions.  By placing these subroutines in ROM, a program executing in the internal RAM
would be much smaller.  Instead of all the programming routines being in RAM, there would just be a "jump to
subroutine" instruction.  This method of providing for in-application programmability is used primarily to address
economic issues.  That is, a ROM is significantly less expensive than the equivalent amount of RAM.
Robustness of in-application programmability also needs to be addressed.  One might make an argument that two
non-volatile elements are really not needed.  If the programming algorithm is contained in FLASH, part of the
algorithm could be to copy the algorithm, itself, into RAM.  Then the programming algorithm could be executed from
RAM.  This is, indeed, a reasonably reliable method if the microcontroller can execute from internal RAM. 
However, a weakness is that a power brown-out or complete power failure will certainly erase the internal RAM. 
Once the programming algorithm operating from RAM has erased the FLASH module, the window of liability is
open until the programming of the FLASH is complete.
Previous page Top Next page