Flash Memory in an Educational Environment


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Flash Memory in an Educational Environment

  1. 1. 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 flash 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 reflashing 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 reflashing mechanism that is Each microprocessor or microcontroller in our lab far more flexible and far more robust than previously runs a common operating system and debugger known existing approaches. Besides being suitable for com- as MUDBUG [1] (for Monitor-Utility-DeBUGger). We mercial environments, our approach also supports the originally developed the first 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 reflash 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 modifications to MUDBUG, so we continue to contain errors, of course, but our reflashing 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 different ways in subsequent classes tions with four or five different 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 flash memory. With flash we could update MUDBUG in different 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.
  2. 2. Many embedded systems in the commercial world immediately after a reset if the kernel watches for a use flash 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 configure that level, however. First, we wanted students to the hardware only during a fixed number of clock cy- be able to flash their own experimental versions of cles following a reset, so the kernel must perform these MUDBUG or any other operating system into the tar- configuration steps. Unfortunately, the configuration 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 configure even a beginning student to restore a working version hardware items that are configurable 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 [2] has developed a reflash- The flash-programming mechanisms that commer- ing approach that is much more flexible 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 reflashes 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 reflash 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 reflashes the any event, we want to allow the student to take over flash 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 flash image can be catastrophic. covering and installing the latest version of MUDBUG If the new flash 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 flash memory chip from the system and reflash it in a 3 Commercial Approaches flash programmer. Of course, the GM team exercises due diligence to make sure a new flash image works How do commercial systems update flash memory? properly before sending it to the field. 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- flexibility of GM’s load-and-go approach, but we also tains control and provides a feature for reflashing the need complete safety. We want the students to be rest of the flash memory with updated software. For able to reflash the entire image and take over the reset example, the kernel might check a port for a special vector, so we need the complete flexibility that GM’s input during the first two seconds following a reset, approach offers. However, GM’s load-and-go approach and that input could activate the kernel’s reflashing isn’t viable for us because we know the students are feature. very likely to reflash 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 flash im- needs and must handle all future communication pro- age crashes immediately after a reset. tocols for receiving a new image for the flash memory. We designed our hardware to provide a special re- Also, the application software cannot receive control flash mode as well as a normal mode. Part of our
  3. 3. flash memory contains the FlashBUG software that per- experimental operating system that the user wants to forms the reflashing function, and the rest of the flash program into the flash memory. memory contains MUDBUG or any experimental sys- A download window pops up on the screen of the tem software that a student flashes into memory. In PC to allow the user to specify the file to download to the normal mode, the FlashBUG portion of the flash the flash 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 effectively doesn’t exist at all. Mean- the cancel button on the screen. The download win- while, the hardware prohibits writes to flash memory dow specifies the current version of MUDBUG as the in the normal mode, so the system is absolutely se- default file 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 reflash mode by the user can specify any object file 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 file within a tion of the flash 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 flash memory. This time- tor and consequently runs FlashBUG. The rest of the out mechanism protects against internet failures, host flash memory moves to another part of the processor’s failures, and students who start updates and fail to memory map in reflash mode, and the hardware al- complete them. lows write access to the flash memory. FlashBUG can therefore download any desired memory image and can Upon receiving an object file, FlashBUG downloads flash it into the MUDBUG portion of the flash memory. the file, checksumming each object record of the file to validate it, and FlashBUG programs the object image FlashBUG allows the user to download a new flash into the flash 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 flash allows writes to the portion of the flash 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 flashing 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 reflash operation, FlashBUG and saves that checksum in the FlashBUG portion of switches the system back to the normal mode. At the flash memory for validation the next time someone that point, the processor begins executing the new activates the system in reflash 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 flash memory moves write access to the flash 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 flash memory. 5 FlashBUG’s User Interface 6 Why FlashBUG Runs from RAM When a user activates the system in reflash mode, FlashBUG takes over the reset vector and comes up in Why does FlashBUG copy itself from flash 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 flash chip that contains the MUDBUG image. to validate the current MUDBUG image in the flash When we program the flash 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 finishes its programming operation, of current version of MUDBUG or any other alternative or course, because the flash chip can’t function normally
  4. 4. while it is in programming mode. As long as the flash 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 flash location and get 8 FlashBUG Security the same value for bit six two times in a row, we know the flash chip has finished 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 flash memory. Therefore, larly secure since our hardware design prohibits writes FlashBUG must copy itself into RAM and run from RAM to the flash memory when we aren’t in reflash mode. before starting any programming operation. If necessary, we can update FlashBUG by allowing it A more subtle consideration is that FlashBUG can- to reflash itself under password protection. Ordinarily, not use interrupts because the interrupt vectors are FlashBUG validates target addresses and doesn’t allow in the flash memory. An interrupt that occurred while anyone to change the portion of the flash chip that the flash 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 reflash 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 reflash 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 flash 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 reflash 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 flash chip for both MUDBUG and FlashBUG. Instead of using an auxiliary EPROM or an auxiliary flash chip for FlashBUG, we put References FlashBUG into the same flash chip with MUDBUG and use decoding logic to map various parts of that flash [1] 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 flash 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 [2] David C. Pheanis and Jeffrey A. Tenney, “Data single flash 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 different classes of students