THE MAGAZINE FOR COMPUTER APPLICATIONS
Circuit Cellar Online offers articles illustrating creative solutions
and unique applications through complete projects, practical
tutorials, and useful design techniques.

USING A BOOT MONITOR IN EMBEDDED SYSTEMS

Part 1ıConstructing the Platform
by Ed Sutter

Start ı The Typical Package ı What are the Alternatives? ı Key Ingredients ı MicroMonitor Run Time Startup ı Just After Reset ı Establish Exception Handlers ı I/O Initialization ı Flash Memory Drivers ı Sources and PDF

THE TYPICAL PACKAGE

Where does a monitor typically come from, and why is it used? Iıve found that a monitor is thought of as (and usually limited to) the small boot-up program that comes with a microprocessor evaluation board. It resides in that boardıs bootrom and allows you to determine whether or not the microprocessor does what is needed for the project. This means that the monitor usually has some mechanism for downloading a binary image into its onboard RAM and then is able to run the code that is in that image. If the monitor supplied with the evaluation board could not at least do this, it would be difficult to do any real evaluation of the processor, so you have to assume that this is the absolute minimum that would be in a monitor that is part of an evaluation package.

Next, and in every case Iıve ever seen, the monitor has a command line interface (CLI) on a communications port (almost always the good-old RS-232). And along with the CLI, comes a command set that allows you to peek and poke memory and I/O, do the download mentioned previously, and make the jump into that downloaded code. Some of the more sophisticated ones have the ability to set breakpoints and single step, and some can even connect to host-based debuggers, allowing you to attach to the board with a PC-based GUI of some kind. Sounds pretty good so far, so why does there seem to be a lack of enthusiasm for monitors? Iıll give you some of my opinions.

First, for each CPU, the monitor has its own set of capabilities and commands. As a result, not only is it a new learning curve for each new monitor that you run into, but the capabilities of each are different. One monitor may have a strong set of capabilities for debugging, but if a new design comes along and a new processor is used, the new monitor (from a different CPU manufacturer) may be limited in its abilities.

Secondly, some monitors can get heavily intertwined with the CPU on which they are running. They are designed to depend on the facilities that are provided by the platform on which they are built. They can dump out every imaginable bit setting in a verbose form, giving every ounce of detail for every register in the system. This kind of stuff may be useful once or twice, but after that, itıs just taking up space in the bootrom. Plus, this makes it difficult to reuse the same environment for other CPUs on other hardware architectures.

Also, if the application code is using some type of RTOS, then chances are the RTOS package comes with some kind of debugger, so any debugging in a monitor is not likely to be used with a purchased RTOS.

And finally (and I think this is most important), is the fact that a monitor is usually not taken seriously. Itıs thought of as the program that some hardware guy throws together to demonstrate or evaluate some new microprocessor, but it is never considered to be a part of the system that could be delivered to an end user as part of the final product.

PREVIOUS • NEXT