Chapter 3: Introducing MicroMonitor

The goal of the next few chapters is to build a large program that provides an extensible firmware platform onto (or into) which you can add application programs. This chapter assumes youve successfully gone through the pain of the previous chapter! If youre booting a new target system, then dont start here, start with the much smaller, more precise steps of the preceding chapter. At this point, I assume you have a solid base of knowledge and working hardware onto which you can start to build the real boot code.

An Embedded System Boot Platform

The term boot monitor refers to the code that is run on a computer system as the lowest level of firmware resident to the hardware platform. You can find various types of boot monitors on a wide range of computer systems, certainly not limited to embedded systems. In general, a typical boot monitor provides the system with some very basic startup capabilities, and provides a bit of insurance to the user because if all else fails (meaning the upper layers of the installed OS), the boot monitor will still be there to fall back on. Typically, a boot monitor is built to provide a basic set of capabilities for diagnostic and system startup, and once the system has started up, the boot monitor is no longer in the picture. This is where I would like to introduce the term embedded system boot platform as a superset of a typical boot monitor.

An embedded system boot platform, like a boot monitor, is a target-resident environment that provides a suite of capabilities that enhances the development process. In its simplest form, the platform speeds up some of the early stages of embedded systems development. In more elaborate configurations, the platform can provide a simple flash file system, Trivial File Transfer Protocol (TFTP)/Xmodem interfaces for application transfer, and a variety of additional commands and capabilities that provide enhancements to the development environment. As a part of a development strategy for an organization, an embedded system boot platform provides a common base on which to build a project. It is an integral part of the application itself, providing the system with a core set of features that are generic in nature and should be usable by application code regardless of the operating system. With that definition in mind, MicroMonitor is an embedded system boot platform.

MicroMonitor is the firmware that the CPU executes immediately after a reset or power-up . MicroMonitor resides in the non-volatile flash memory of the target system. It is responsible for booting the CPU and getting the system to a state where a user can access the target through some interface (typically either RS-232 or Ethernet). The capabilities provided at this interface depend on what capabilities were configured into the platform when it was built. After MicroMonitor does some initialization of the target, it presents itself as a command line interface to the user, typically through an RS-232 port. (If an Ethernet interface is included in the hardware, the developer also can communicate with MicroMonitor through the User Datagram Protocol (UDP).)

The command set includes basic capabilities like memory display and modification, parallel I/O control, and command line editing/history. MicroMonitor also configures part of the flash memory to be used as a file system (TFS, discussed in Chapter 7). The presence of a file system means that code can access the flash memory as name space instead of address space. Adding a file system opens up a whole new set of a capabilities for the embedded target, and this is what sets MicroMonitor apart from most boot monitors. Among other things, a file system allows the system and its software to be dynamically reconfigured without recompilation. For example, since the file system supports an auto-bootable attribute, the monitor can look for that attribute at boot time and automatically run all marked files. These files might be conventional, compiled binary executables, or they might be configuration scripts that configure the target to run Dynamic Host Configuration Protocol (DHCP) or Bootstrap Protocol (BOOTP) or that assign a fixed IP and MAC address to the target.

You can configure multiple files for autoboot, and MicroMonitor automatically runs the files in alphabetical order. Additionally, TFS and MicroMonitors command line interface (CLI) share the concept of user levels. When the target first starts up, it is running at the highest user level (similar to UNIX superuser or Windows administrator). After control is turned over to the individual TFS files, the user level can be adjusted so that certain portions of the system (both files and commands) are only accessible to certain user levels. User-level access is controlled through scrambled passwords that are stored in a TFS file. If somehow the passwords are lost or inaccessible, there is a back-door password that is derived from the MAC address of the target.

In this design, everything except the monitor image itself is a file even the main application invoked by the monitor is just another file in TFS. When the application is running (as a result of the monitor loading it from TFS flash memory to DRAM), other files can be accessed by the active application. You can therefore build one application binary that configures itself based on a few locally editable ASCII files in TFS. Also, since the application executes out of DRAM (rather than directly out of the flash memory in TFS), a new application can be loaded into flash memory while the current application in DRAM is left running.

As you can see, MicroMonitor is very heavily linked to TFS. As a result, many of the other commands within the CLIs command set assume the existence of a file system. Xmodem and TFTP both interface to the file system so uploads and downloads can all be name-based, instead of address-based . This design makes life a lot easier, and it makes applications that reside on top of the platform a lot easier to manage. MicroMonitor makes an embedded target look a bit like a PC with regard to the basic environment. The PC provides a core set of capabilities that the application can use: a file system, BIOS, and standard I/O. MicroMonitor allows the target to present itself as a platform that provides a similar set of facilities.

Target-Resident Command Set

The following table lists each of the MicroMonitor commands accessible from the CLI. For complete details, refer to the CD-ROM.

argv	Build argv list
arp	Address Resolution Protocol (ARP)
call	Call embedded function
cast	Cast a structure definition across data in memory
cm	Copy memory
dhcp	Issue DHCP/BOOTP discover
dis	Disassemble memory
dm	Display memory
echo	Print string to console
edit	Edit file or buffer
Etest	Test to verify operation of exception handling
ether	Ethernet interface operations
exit	Exit a script
flash	Flash memory operations
fm	Fill memory
gosub	Call a subroutine within a script
goto	Branch to script tag
heap	Heap operations
help	Display command set details
history	Display command history
icmp	Internet Control Message Protocol (ICMP) interface operations
idev	Device interface operations
if	Conditional branching within scripts
item	Extract an item from a list
let	Set shell variable equal to result of expression
mstat	Monitor status (target specific)
mt	Memory test
pm	Put to memory
read	Interactive shell variable entry for scripts
reset	Firmware restart ( warmstart )
return	Return from subroutine within script
set	Shell variable operations
sleep	Second (or millisecond) delay
sm	Search memory
strace	Stack trace (target specific)
tftp	TFTP client/server operations
tfs	TFS operations
ulvl	Display or modify current user level
unzip	Decompress block of memory to some other block of memory
xmodem	Xmodem file transfer
version	Version information

API Presented to the Application

This section lists each function of the MicroMonitor API accessible to the application. For complete details, refer to the CD-ROM.

mon_addcommand()	Add a command to the monitor
mon_appexit()	Call this function when the application exits
mon_com()	Basic hook between monitor and application
mon_cprintf()	Centered small printf()
mon_crc32()	A crc32 function
mon_decompress()	Decompress a block of data
mon_docommand()	Invoke a command in the monitor
mon_free()	Return memory to monitors heap
mon_getargv()	Retrieve the current argument list from the monitor
mon_getbytes()	Retrieve characters from console port
mon_getchar()	Retrieve one character from console port
mon_getenv()	Retrieve content of specified shell variable
mon_getline()	Retrieve a line of characters from console port
mon_gotachar()	Return indication of character presence on console port
mon_intsoff()	Turn off interrupts
mon_intsrestore()	Restore interrupt state
mon_malloc()	Allocate memory from heap managed by monitor
mon_pioclr()	Clear state of specified PIO pin
mon_pioget()	Retrieve state of specified PIO pin
mon_pioset()	Set state of specified PIO pin
mon_printf()	Small printf (no floating point)
mon_putchar()	Send character to console port
mon_restart()	Monitor restart point
mon_setenv()	Establish a new environment variable
mon_setUserLevel()	Establish a new user level in the monitor
mon_sprintf()	Small sprintf (no floating point)
mon_tfsadd()	Add a file to TFS
mon_tfseof()	Return end-of-file (EOF) state of opened file
mon_tfsinit()	Initialize (erase) flash memory used by TFS
mon_tfsclose()	Similar to standard close() on a TFS file
mon_tfsctrl()	Perform various control functions on TFS file
mon_tfsfstat()	Retrieve a local copy of a files header
mon_tfsgetline()	Retrieve next line of an opened ASCII file in TFS
mon_tfsipmod()	Perform an in-place modification on a TFS file
mon_tfsnext()	Step through list of file headers in TFS
mon_tfsopen()	Similar to standard open on a TFS file
mon_tfsread()	Similar to standard read on a TFS file
mon_tfsrun()	Run some executable file (script or binary) in TFS
mon_tfsseek()	Similar to standard seek on a TFS file
mon_tfstruncate()	Truncate the size of a file currently opened for writing
mon_tfsunlink()	Remove file from TFS
mon_tfswrite()	Similar to standard write() on a TFS file
mon_xcrc16()	A crc16 function (used internally by Xmodem)

Host-Based Command Set

This section lists each of the commands on the PC that are part of the MicroMonitor package. For complete details, refer to the CD-ROM.

aout	Tool to interface to AOUT format files
bin2srec	Binary to S-record converter
coff	Tool to interface to COFF format files
com	Very basic com port communication tool
defdate	Generate date/time strings for use with monitor version
dhcpsrvr	Single-threaded dhcp/bootp server
elf	Tool to interface to ELF format files
fcmp	File comparison utility
f2mem	Files-to-memory converter
maccrypt	Tool to create a backdoor password from a MAC address
moncmd	Interface to monitors UDP communication interface
monsym	Symbol-table format converter
newmon	Tool to update the boot flash memory
title	Place text on title bar of Win32 console window
ttftp	Single-threaded TFTP client/server
whence	Display path through which an executable is run

Figure 3.1: Applications and MicroMonitor.

Applications running on MicroMonitor can choose to bypass MicroMonitor (A), rely exclusively on MicroMonitor for core services (B), or use only a subset of MicoMonitors services (C).

A PC that runs DOS by itself doesnt have much value until you put other applications on the PC to run on top of DOS. These applications assume some underlying set of features. The underlying features beneath DOS come from the BIOS. In the case of MicroMonitor, the underlying features come through hooks that allow the application to interface to the monitor directly. MicroMonitor provides the application with some fundamental facilities through its API, but does not prohibit (as a matter of fact, it encourages) the direct connection of the application to the hardware. (Refer to Figure 3.1.) The monitor is not only a standalone program that runs on the target by itself, it is also the basis for other programs that can be downloaded onto the target through facilities provided by the monitor. Think about it: to build the monitor the first time, you have to burn flash memory in some external device just to install the boot code or program. Once the monitor is stable, you can use it to reprogram itself and to download other application programs. No more need for the device programmer!

Summary

The MicroMonitor platform provides an environment onto which a team can develop and deploy a variety of different types of applications. The simplicity of the MicroMonitor implementation makes it very easy to port MicroMonitor from one target to the next. Because MicroMonitor does not inhibit the use of any overlaying RTOS or flash file system (FFS), it offers a common base for development from one project to the next despite differences in the hardware below or the RTOS above. This common base immediately provides the team with a flash file system, fast application downloads, a convenient field upgrade path, and much more. Like other monitors, MicroMonitor resides in the boot flash memory and provides some target-specific functions that allow you to do things close to the hardware, but MicroMonitor also provides an environment that is valuable to the deployed runtime application.