Designing and Debugging ROM-based Code

By Arvind Chauhan

April 9, 2007

(Designing and Debugging ROM-based Code :  Page 1 of 1 )

It's difficult to think of an embedded device that doesn't contain any type of memory. Lowering costs and increasing densities have made memory use in today's system designs very generous. More memory is provided to let software consume it all up in the name of more features and personalities, and of course, more bugs to debug. Commonly found memory types in systems include ROM, SRAM, DRAM, PROM, and flash.

The moment your PC game execution starts choking, the blame is "not enough RAM." Much of the code is executed out of RAM. SRAM (static random access memory) is faster than DRAM (dynamic random access memory), and hence, costs more. RAM retains data as long as power is applied, and DRAM in particular, needs to be refreshed regularly. Typically, SRAM is available in limited sizes while DRAM can more easily be scaled to fit the system.

ROM, on the other hand, can retain data, even when power is removed. Many ROM variants are available, including OTPROM (one-time programmable read-only memory), EPROM (erasable programmable read-only memory), and EEPROM (electrically erasable programmable read-only memory).

Many system-on-chip (SoC) designs contain both ROM and SRAM. This ROM is usually hardwired or masked ROM. The ROM is mostly used to store the first-order boot-loader program. After reset, ROM is usually mapped to the address from where the main CPU starts fetching instructions. A second-order boot loader or the main program can then be downloaded from an I/O interface. As ROM is fast, it can also be used to store the critical and well-tested library of important routines. Such routines typically don't change during the system's lifetime.

In ROM, software becomes hardware. The content can't be changed once the chip is manufactured. This "read-only" nature mandates a thorough debug of ROM code. You can't debug ROM-based code once the chip is manufactured using traditional debug techniques, namely putting breakpoints and watching the system state. There's very little you can do even after the bug is traced in ROM code.

 Page 1 of 1