Sourcery CodeBench Lite supports development and debugging of applications loaded into flash memory on ARM EABI targets. There are three steps involved:
You must use an appropriate linker script that identifies the ROM memory region on your target board, and locates the program text within that region. Refer to Chapter 5, “CS3™: The CodeSourcery Common Startup Code Sequence” for information about the boards supported by Sourcery CodeBench.
Next, load your program into the flash memory on your target board. You must use third-party tools to program the flash memory.
Finally, when debugging a program in flash memory, GDB must be told about the ROM region so that it knows where it must use hardware breakpoints to control program execution. If you are using the Sourcery CodeBench Debug Sprite to debug your program, the Sprite does this automatically, using the memory map provided in the board configuration file. Otherwise, you must provide this information explicitly.
When using GDB from the command line, you can mark the flash memory as read-only by using the command:
(gdb) memstartendro
where start and
end define the address range of the
read-only memory region.
In addition to GDB's automatic use of hardware breakpoints in the
ROM region, you can also set hardware breakpoints explicitly from
the debugger.
However, on many targets the number of available hardware breakpoints
is very small. Furthermore,
GDB also uses hardware breakpoints internally to implement commands
such as step, next, and
finish. Thus the number of breakpoints you can
explicitly set in ROM may be fewer than the number of hardware
breakpoints supported by the target system.
For example, ARM7TDMI cores support only one hardware breakpoint, which must also be used internally by the debugger if you set any software breakpoints in RAM. On ARM9 cores, there are two hardware breakpoints supported and one is consumed by the debugger if you set any software breakpoints.