Flash Memory in an Educational Environment
David C. Pheanis Christian Johnson
Computer Science and Engineering Inter-Tel, Inc.
Arizona State University 7300 West Boston Street
Tempe, Arizona 85287-5406 Chandler, Arizona 85226-3224
David.Pheanis@asu.edu Christian Johnson@inter-tel.com
Abstract access to allow students to edit, assemble, and link
Commercial applications of embedded systems of- on a host server, and the PC communicates with the
ten use ﬂash memory so vendors can update software target platforms through serial ports in a daisy-chain
in customer-owned systems without physically remov- arrangement. The multiple target platforms allow us
ing and replacing ROM chips. These reﬂashing oper- to support multiple courses at various levels of student
ations are safe because they occur under tightly con- experience since each target platform has its own par-
trolled conditions involving updates with thoroughly ticular type of microprocessor or microcontroller and
validated software. its own unique hardware design.
We have developed a reﬂashing mechanism that is Each microprocessor or microcontroller in our lab
far more ﬂexible and far more robust than previously runs a common operating system and debugger known
existing approaches. Besides being suitable for com- as MUDBUG  (for Monitor-Utility-DeBUGger). We
mercial environments, our approach also supports the originally developed the ﬁrst version of MUDBUG back
considerably more stringent needs of a university pro- in 1975, and we have made extensive upgrades over the
gram for students in computer engineering. We allow years since then. MUDBUG employs conditional assem-
a student to reﬂash the memory in a microcontroller bly to support a number of target systems with various
system and take over the entire system, including the processors. Students who take our senior-level course
reset vector. Students can therefore test their own sys- in Systems Programming gain practical experience by
tem software. A student’s experimental software may making modiﬁcations to MUDBUG, so we continue to
contain errors, of course, but our reﬂashing approach enhance MUDBUG at frequent intervals.
provides a simple, convenient, and foolproof mecha-
nism for recovering and installing the latest version
of our validated system software even if the student’s 2 Challenge of Updating MUDBUG
system software crashes immediately after a reset.
Until recently, our design of a microprocessor or mi-
1 Background and Environment crocontroller target platform typically used an EPROM
to contain MUDBUG. The idea was that we could con-
At Arizona State University, students in Computer veniently update MUDBUG once a year or perhaps once
Science and Engineering use a variety of microproces- a semester by erasing and reprogramming each plat-
sor and microcontroller development stations at sev- form’s EPROM. This approach worked well in the early
eral levels in the curriculum. They initially use devel- years, but removing, erasing, reprogramming, and re-
opment stations in a beginning class to learn about inserting EPROMs became increasingly cumbersome as
programming in assembly language, and they later the lab grew to include more than 40 development sta-
use the stations in diﬀerent ways in subsequent classes tions with four or ﬁve diﬀerent target platforms at each
to learn about the details of system software, digital development station.
hardware design, and hardware/software interfaces. An obvious solution was to migrate from EPROMs to
Each station in our lab includes a PC and several ﬂash memory. With ﬂash we could update MUDBUG in
diﬀerent custom-designed microprocessor and micro- the circuit in a matter of seconds without even opening
controller target platforms. The PC provides network the chassis that contains the platform.
Many embedded systems in the commercial world immediately after a reset if the kernel watches for a
use ﬂash memory so technicians can update software special input during the two seconds following a reset.
for customers. We wanted to go considerably beyond Many microcontrollers allow the software to conﬁgure
that level, however. First, we wanted students to the hardware only during a ﬁxed number of clock cy-
be able to ﬂash their own experimental versions of cles following a reset, so the kernel must perform these
MUDBUG or any other operating system into the tar- conﬁguration steps. Unfortunately, the conﬁguration
get platforms, taking over the reset vector and the can never change in the future since the boot block
entire memory image in the process. Second, know- that contains the kernel is permanently locked. In our
ing that experimental student programs often fail to environment, we want the students to be able to take
work, we wanted a foolproof method that would allow control immediately after a reset so they can conﬁgure
even a beginning student to restore a working version hardware items that are conﬁgurable only during the
of MUDBUG to a target platform quickly, easily, and few clock cycles following a reset.
automatically no matter how badly someone’s experi- The development team for the GPDAS and VBI
mental operating system had crippled the platform. projects at General Motors  has developed a reﬂash-
The ﬂash-programming mechanisms that commer- ing approach that is much more ﬂexible than the kernel
cial systems employ are not nearly robust enough for approach. They don’t lock the boot block or depend
our use. A trained technician reﬂashes a commer- on a permanent kernel. Instead, they provide a simple
cial system with thoroughly tested, released software. but powerful load-and-go feature in their application
In our case, we want to allow students (who are just software. With the load-and-go feature, they can load
learning and may be prone to mistakes) to reﬂash our a program into RAM and then transfer control to that
target platforms with software that may not work at program. This feature allows them to load and run
all or perhaps even with software that is malicious. In a program that reads a new image and reﬂashes the
any event, we want to allow the student to take over ﬂash memory. They are not limited to any particular
the reset vector and have complete control of the sys- protocol since they simply load and execute a program
tem starting at power-up time. In spite of letting the that uses their current protocol.
student take complete control, we want to provide a The drawback to the load-and-go approach is that
simple, convenient, and foolproof mechanism for re- a mistake in the new ﬂash image can be catastrophic.
covering and installing the latest version of MUDBUG If the new ﬂash image doesn’t work well enough to
regardless of what the student’s software does. provide at least the load-and-go feature, then the sys-
tem is broken. In this case, someone must remove the
ﬂash memory chip from the system and reﬂash it in a
3 Commercial Approaches ﬂash programmer. Of course, the GM team exercises
due diligence to make sure a new ﬂash image works
How do commercial systems update ﬂash memory? properly before sending it to the ﬁeld.
The most common approach involves putting kernel
software into a boot block and locking that boot block
to make the kernel permanent. Under normal oper- 4 The FlashBUG Approach
ating conditions, the kernel transfers control to the
system’s application software following a reset. Under In our educational application, we need the total
some sort of special condition, however, the kernel re- ﬂexibility of GM’s load-and-go approach, but we also
tains control and provides a feature for reﬂashing the need complete safety. We want the students to be
rest of the ﬂash memory with updated software. For able to reﬂash the entire image and take over the reset
example, the kernel might check a port for a special vector, so we need the complete ﬂexibility that GM’s
input during the ﬁrst two seconds following a reset, approach oﬀers. However, GM’s load-and-go approach
and that input could activate the kernel’s reﬂashing isn’t viable for us because we know the students are
feature. very likely to reﬂash a system with experimental soft-
One disadvantage of the kernel approach is that the ware that doesn’t work at all. We must have a simple,
kernel can never change since the boot block is perma- convenient method of recovering and installing the lat-
nently locked. The kernel must anticipate all future est version of MUDBUG even if the student’s ﬂash im-
needs and must handle all future communication pro- age crashes immediately after a reset.
tocols for receiving a new image for the ﬂash memory. We designed our hardware to provide a special re-
Also, the application software cannot receive control ﬂash mode as well as a normal mode. Part of our
ﬂash memory contains the FlashBUG software that per- experimental operating system that the user wants to
forms the reﬂashing function, and the rest of the ﬂash program into the ﬂash memory.
memory contains MUDBUG or any experimental sys-
A download window pops up on the screen of the
tem software that a student ﬂashes into memory. In
PC to allow the user to specify the ﬁle to download to
the normal mode, the FlashBUG portion of the ﬂash
the ﬂash memory. The student can have a change of
memory is not even in the processor’s memory map,
heart, of course, and cancel the download by clicking
so that memory eﬀectively doesn’t exist at all. Mean-
the cancel button on the screen. The download win-
while, the hardware prohibits writes to ﬂash memory
dow speciﬁes the current version of MUDBUG as the
in the normal mode, so the system is absolutely se-
default ﬁle to load, so a beginning student can con-
cure in the normal mode. The system comes up in the
veniently accept the default to restore (or update) a
normal mode following an ordinary reset.
system to the current working software. Alternatively,
A student activates the special reﬂash mode by the user can specify any object ﬁle on any internet-
pressing the reset button and also pressing another accessible node as long as the user provides a valid
button (the NMI button) while holding down the reset username and password for that node.
button. The hardware then maps the FlashBUG por- If FlashBUG doesn’t receive an object ﬁle within a
tion of the ﬂash memory into the processor’s memory reasonable amount of time, the system reports a fail-
map, and the processor fetches FlashBUG’s reset vec- ure and does not update the ﬂash memory. This time-
tor and consequently runs FlashBUG. The rest of the out mechanism protects against internet failures, host
ﬂash memory moves to another part of the processor’s failures, and students who start updates and fail to
memory map in reﬂash mode, and the hardware al- complete them.
lows write access to the ﬂash memory. FlashBUG can
therefore download any desired memory image and can Upon receiving an object ﬁle, FlashBUG downloads
ﬂash it into the MUDBUG portion of the ﬂash memory. the ﬁle, checksumming each object record of the ﬁle to
validate it, and FlashBUG programs the object image
FlashBUG allows the user to download a new ﬂash into the ﬂash memory. The FlashBUG software vali-
image with FTP from any system that has an internet dates download target addresses, of course, and dis-
connection. A student can therefore download a ﬂash allows writes to the portion of the ﬂash memory that
image from almost any system anywhere in the world contains FlashBUG, so FlashBUG itself remains secure.
(perhaps from the student’s own home PC). Similarly,
we can restore MUDBUG from anywhere in the world After the download and ﬂashing operations are
as long as we have an internet connection. complete, FlashBUG computes a checksum for MUDBUG
(or for whatever program the student downloaded)
After completing the reﬂash operation, FlashBUG and saves that checksum in the FlashBUG portion of
switches the system back to the normal mode. At the ﬂash memory for validation the next time someone
that point, the processor begins executing the new activates the system in reﬂash mode. Then FlashBUG
normal-mode software, and FlashBUG disappears from displays a message directing the user to press the reset
the memory map. At the same time, the hardware re- button, removes its own portion of the ﬂash memory
moves write access to the ﬂash memory, thus making from the memory map, and waits for the user to press
the system completely secure. the reset button to activate the new software in the
MUDBUG portion of the ﬂash memory.
5 FlashBUG’s User Interface
6 Why FlashBUG Runs from RAM
When a user activates the system in reﬂash mode,
FlashBUG takes over the reset vector and comes up in Why does FlashBUG copy itself from ﬂash memory
place of MUDBUG. FlashBUG starts by copying itself into RAM and then run from RAM? Running from
into RAM and then executing from RAM for reasons RAM is necessary because FlashBUG resides in the same
that we’ll discuss later. FlashBUG uses a checksum physical ﬂash chip that contains the MUDBUG image.
to validate the current MUDBUG image in the ﬂash When we program the ﬂash memory, the chip goes into
memory and tells the user whether MUDBUG is valid programming mode until its internal programming op-
or not. In either case, FlashBUG initiates a download eration is complete. We must be able to determine
procedure that allows the user to download either the when the chip ﬁnishes its programming operation, of
current version of MUDBUG or any other alternative or course, because the ﬂash chip can’t function normally
while it is in programming mode. As long as the ﬂash while sharing the chassis, the power supply, and 90%
chip is in programming mode, each read from any ad- of the platform hardware between the two processors.
dress in the chip results in a data value that has bit
six toggled from the bit-six value of the previous read
from the chip. When we read a ﬂash location and get 8 FlashBUG Security
the same value for bit six two times in a row, we know
the ﬂash chip has ﬁnished its programming operation. FlashBUG is always totally secure — students can
With bit six toggling from one read to the next, never change it since it isn’t even in the memory map
we obviously can’t fetch instructions and correctly ex- unless it is running and has control. MUDBUG is simi-
ecute a program from the ﬂash memory. Therefore, larly secure since our hardware design prohibits writes
FlashBUG must copy itself into RAM and run from RAM to the ﬂash memory when we aren’t in reﬂash mode.
before starting any programming operation. If necessary, we can update FlashBUG by allowing it
A more subtle consideration is that FlashBUG can- to reﬂash itself under password protection. Ordinarily,
not use interrupts because the interrupt vectors are FlashBUG validates target addresses and doesn’t allow
in the ﬂash memory. An interrupt that occurred while anyone to change the portion of the ﬂash chip that
the ﬂash chip was toggling bit six would cause a severe contains FlashBUG itself. We can use a special com-
failure. The user can induce such a failure, of course, mand and a password, though, to allow FlashBUG to
by pressing the NMI button during a programming op- update itself. By using a trapdoor function to hash
eration, but only the current programming operation the password, we can even allow the students to see
fails. FlashBUG comes up properly the next time some- the source code for FlashBUG without any danger since
one activates the system in reﬂash mode. they can’t deduce the password from the source code.
We update FlashBUG only rarely, and we update it with
validated software when we do update it.
7 FlashBUG Advantages
Our hardware design doesn’t even map FlashBUG 9 Conclusion
into the processor’s memory map unless someone
starts the system in reﬂash mode, so FlashBUG doesn’t We’ve implemented a foolproof mechanism that al-
consume any space at all in the memory map. This lows students to ﬂash their own experimental operat-
approach makes the entire memory map available for ing systems into the target platforms and easily re-
MUDBUG or for the student’s operating system. In ef- cover when they make mistakes. Furthermore, the
fect, FlashBUG doesn’t even exist in the machine unless same mechanism allows us to update MUDBUG auto-
the system is in reﬂash mode. FlashBUG is therefore to- matically by merely updating the MUDBUG image on
tally transparent to MUDBUG. the server and using a simple procedure to update each
Another elegant aspect of our hardware design is station’s target platforms.
the fact that we use just one ﬂash chip for both
MUDBUG and FlashBUG. Instead of using an auxiliary
EPROM or an auxiliary ﬂash chip for FlashBUG, we put References
FlashBUG into the same ﬂash chip with MUDBUG and
use decoding logic to map various parts of that ﬂash  David C. Pheanis and Paul-Marcel St-Onge, “A
chip into the processor’s memory map. Single-Source Debugger for Multiple Target Pro-
cessors,” ISCA 11th International Conference on
Actually, our sharing of the ﬂash chip goes even fur-
Computers and their Applications, March 7–9,
ther. We provide two processors, a 6800 and a 6809, on
1996, Proceedings, pp. 95–98.
our target platform with a toggle switch that the stu-
dent can use to select one processor or the other. Our  David C. Pheanis and Jeﬀrey A. Tenney, “Data
single ﬂash chip contains four sections: MUDBUG for Collection with Vehicle-Bus Interface,” ISCA 16th
the 6800, FlashBUG for the 6800, MUDBUG for the 6809, International Conference on Computers and their
and FlashBUG for the 6809. Everything that we’ve de- Applications, March 28–30, 2001, Proceedings, pp.
scribed works the same way for both the 6800 and 129–132.
the 6809. Having two processors on a single platform
allows us to support two diﬀerent classes of students