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

JUST AFTER RESET

Immediately after reset, you must start with some assembler code. I try to get up to C level as soon as possible, but you must consider the possibility that this reset code may be executing as a result of a true reset/power cycle or may be the result of a firmware-invoked restart. These two types of system startups are commonly referred to as coldstart and warmstart, respectively, and they perform similar tasks. The goal is for completion of code through either entry point, resulting in the system looking like it just went through a power cycle or reset, or almost.

The code at warmstart should do all the same stuff that may have been intrinsically done as a result of a power cycle and entry into coldstart (see the list of initializations below). However, there must be a means to determine which entry point was taken. This is necessary so that decisions can be made as to whether or not you want to initialize the monitorýs .bss space for determining whether or not you want to run through some higher level system startup procedure and so forth.

The following is a list of basic initializations needed at this point in the startup:

• disable interrupts at the CPU level (not periphery, just CPU)
• disable, flush, and invalidate caches appropriately
• enable the ability to access the boot flash at the desired speed and address
• enable the ability to access the system RAM or DRAM at the desired speed and address
• initialize a stack pointer

A pseudo-code example of reset.s is shown in Listing 1. The coldstart tag should be located at the point where the CPU vectors to after a powerup or reset. Ignore moncomptr for now, Iýll talk more about this later. The warmstart tag is seen by the C code as a function so that the C code has an easy point to restart the firmware. The code at coldstart stores the INITIALIZE value into a location that will not be corrupted by the reset code, hence, it will be retrievable at the beginning of the first C function start(). This allows the firmware to decide whether it does a complete or partial startup.

A complete startup will initialize all the monitorýs .bss space, all of the monitorýs firmware subsystems, and reinitialize all periphery used by the monitor and then look to the file system for any autobootable files to run. A partial startup will not initialize the .bss space (allowing shell variables previously set to remain set) and will not look to the file system for any autobootables, it would simply stop at the CLI prompt.

In Listing 2, you see the first C function executed by the monitor, and it may be necessary (depending on the environment) to put the first section of this function at the end of the assembler code prior to calling start(). This will avoid the possibility of the .bss initialization loop stepping on something that it shouldnýt.

I have found it extremely convenient to build the monitor so that there is no need to copy any initialized data to the RAM space. This convenience eliminates the hassle of dealing with the different ways various tool sets handle it. However, it does require some discipline when coding, as there is no compile-time warning if you try to write over initialized data (unless you are careful with the use of const). Remember that the goal here is to be as compiler-, CPU-, and target-independent as possible, and this particular issue is always a bit different from one toolkit to the next.

Also, I found it handy to not use any compiler-supplied libraries for higher level functions unless absolutely necessary. This may be a bit compulsive on my part, but for a monitor, I think it is important to have a tight grasp on the code, so this monitor comes with its own printf(), malloc(), and such. Note that I am not suggesting you write your own math primitives; use what comes with the toolkit for that!

PREVIOUS • NEXT