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

FLASH MEMORY DRIVERS

Next, you establish some flash interfaces. There are four major flash interface functions that must be written:

• Flash idıreturn some indication of the type of flash device that is populated on the system board. This is useful for two reasons. It provides a sanity check that the flash memory is writable because in most cases you must write to the flash memory to properly read back its ID, and it allows the firmware to potentially support the possibility of there being different types of devices installed in the system.
• Flash eraseıtakes a sector number as input and properly erases that sector (or all sectors).
• Flash writeıtakes a source and destination pointer along with a size and writes the source data to the destination location. This function assumes that the destination is flash memory and that it has been erased.
• Flash erase and writeıa combination of the second and third functions above, but they are done in one step. Takes the same arguments as flash write but erases the affected sectors prior to doing the write. This function is useful for rewriting a new monitor in place. Actually, thatıs the only thing I use this for.

The biggest challenge when writing these functions is that they must be executed out of memory space that is not part of the flash device being operated on. Yes, I know there are some newer devices that allow you to get fancy here, but letıs not assume special stuff is being used. Basic flash memory will do just fine here. The idea is to create the function in flash memory, copy it to RAM, and establish a function pointer to that copy space.

The code within the function must be entirely self-relative, no jumps to other functions. (Because you canıt call printf() or putchar() from within these functions, an in-line version may be useful here for debugging the flash operation code.) Being self-relative is important because function calls could be made PC relative at link time, so moving the text for the function to a new location would cause that PC-relative jump to crash and burn. Most tool sets support the ability to write position-independent code, but Iıll assume you do not have that.

The copy of the code to RAM should be done prior to enabling any of the CPUıs caching because you are now using data accesses to populate instruction space (thatıs a topic for another article), and you donıt want to have to worry about that now. Listing 4 is a basic example of how to copy a function into RAM. Note that the buffer is 32-bit aligned using an array of longs instead of chars. This guarantees that the buffer will start on a modulo-4 address (some processors require each instruction to be on a 32-bit boundary, so this satisfies that requirement but doesnıt hurt anything for those CPUs that do not have this requirement). It assumes that the linker is placing functions within a file in contiguous memory space, and that the function will fit in the specified buffer.

There are many different flavors of flash memory available today. Some are basic, and others are capable of a lot. Once again, it is beyond the scope of this article to go into flash memory specifics, but my suggestion is to pick a device with the ability to lock and unlock sectors at run time without the need for any additional programming voltage. The ideal case is to install a jumper for the system that, after a sector is locked (or protected), can only be unlocked and written to after the hardware is power-cycled. This allows you to lock out some boot sectors and feel secure (because the firmware cannot remove a jumper), yet with the simple removal of a jumper, the boot sectors could be reprogrammed.

That brings us to the end of Part 1. You have a UART for printf(), the exception handlers are in place, and the basic flash interfaces are initialized. Next month, Iıll show you how to do some miscellaneous initialization of the basic monitor facilities. See you then!

PREVIOUS • NEXT