The particular debugging capabilities provided in CrossWorks for ARM depends upon the particular ARM device being used. The following table summarizes the CrossStudio debug facilities available for each ARM device type:
|ARM Debug Architecture||Software Breakpoints||Hardware Breakpoints||Break on Exception||Monitor Mode||Memory Access||Debug I/O|
|ARM7||Unlimited (1 hardware breakpoint used)||2||No||Yes||Stop CPU or Monitor Mode||Stop CPU or DCC|
|ARM9||Unlimited (1 hardware breakpoint used on ARM920T/ARM922T)||2||Yes||Yes||Stop CPU or Monitor Mode||Stop CPU or DCC|
|ARM11||Unlimited||8 (6 instruction and 2 data)||Yes||No||Stop CPU||Stop CPU or DCC|
|Cortex-M3||Unlimited||Max. 12 (8 instruction, 4 data)||Yes||No||Real Time||Stop CPU or Real Time|
|Cortex-M1/M0||Unlimited||Max. 6 (4 instruction, 2 data)||Yes||No||Real Time||Stop CPU or Real Time|
|Cortex-A/R||Unlimited||8 (6 instruction and 2 data)||Yes||No||Stop CPU||Stop CPU or DCC|
|XScale||Unlimited||4 (2 instruction, 2 data)||Yes||No||Stop CPU||Stop CPU|
Single stepping is implemented by setting a hardware breakpoint on the next instruction that will execute in the current execution thread. Therefore, you will not single step into a different thread of execution, unless code is shared; and, if you have used all the hardware breakpoints, you won't be able to single step.
Software breakpoints are implemented by overwriting the instruction at the desired breakpoint address with a breakpoint instruction. Restarting from a software breakpoint uses the built-in ARM simulator, unless the instruction cannot be simulated, in which case the instruction is written back to memory and single stepped. The project properties Read-only Software Breakpoints and Read-write Software Breakpoints control how software breakpoints are used in memory areas marked ReadOnly and ReadWrite in the current project's memory-map file.
The project property Startup Completion Point is used to specify the address of a symbol that has a breakpoint on it. When the startup completion point is hit, software breakpoints will be used and debug input/output will be enabled. This enables you to debug an application that copies code into RAM on startup.
These ARM devices provide two hardware-breakpoint units that can be configured as program or data breakpoints.
There is no software-breakpoint instruction on ARM7TDMI, ARM720T, and ARM920T devices. To implement software breakpoints, one of the hardware-breakpoint units is programmed to break on the execution of the ARM opcode 0xdfffdfff or 0xdffedffe and, consequently, the Thumb opcode 0xdfff and 0xdffe.
Data breakpoints can only be set on ranges of aligned powers of 2. So char, short, and int/long variables can have breakpoints set on them, but larger variables are unlikely to meet the requirement for aligned powers of 2. Data-valued breakpoints such as count==3 are supported, as are masked data-valued breakpoints such as (x & 1)==1.
The hardware breakpoints can be chained together to allow breakpoint sequencing. When you are connected to the target, use the breakpoint-edit dialog or the breakpoint properties to change the Action to Set Chain on the first breakpoint, and change the Action of the second breakpoint to Stop (When Chain Set).
ARM9 devices have a vector-catch capability that can be set in the exceptions group of the Breakpoints window to enable a breakpoint when an exception occurs.
The debug communication channel (DCC) can be used to implement debug I/O, which depends on the setting of the DebugIO Implementation project property. Using the DCC to implement debug I/O enables interrupts to be serviced during debug I/O.
The DCC is also used to implement communications with the debug handler, if the project property Use Debug Handler is set. You can build the debug handler into your application by adding the file $(StudioDir)/source/ARMDIDebugHandler.s to your project. When you have the debug handler in your project, you can enable the project property Monitor Mode Debug to allow interrupts to be serviced when a breakpoint is hit. To do this, you must set the prefetch and data-abort exception vectors to jump to the symbols dbg_pabort_handler and dbg_dabort_handler, respectively. You can also enable the project property Monitor Mode Memory, in which case CrossWorks will access memory using the debug handler when the application is running. You must arrange for your application to call the function dbg_poll at regular intervals, which will enable interrupts to be serviced while the debugger is accessing memory.
These devices provide 6 hardware instruction breakpoints and 2 hardware data breakpoints. Data-valued breakpoints are not supported.
Cortex-M devices have a variable number of instruction breakpoints and data breakpoints. Typically, Cortex-M3 parts have six instruction breakpoints and four data breakpoints, Cortex-M1/M0 parts have four instruction and two data breakpoints. Note that the instruction breakpoints work only on the internal code memory of the Cortex-M devices. If you have external flash on your Cortex-M device and software breakpoints in flash aren't supported, a data breakpoint is used, which will stop the processor after the instruction has executed.
Data breakpoints can only be set on ranges of aligned powers of 2. So char, short, and int/long variables can have breakpoints set on them, but larger variables are unlikely to meet the requirement for aligned powers of 2. One data-valued breakpoint, such as count==3, is optionally supported on some Cortex-M3 devices.
Cortex-A and Cortex-R devices provide six hardware instruction breakpoints and two hardware data breakpoints. Data-valued breakpoints are not supported.
XScale devices have two instruction breakpoints and two data breakpoints. The data breakpoints are supported on int and long variables only.
The debugger supports the ARM semihosting interface. The operations SYS_READC and SYS_READ from standard input will return immediately i.e. they do not block.