Next: JTAG Commands, Previous: General Commands, Up: Top

## 16 Architecture and Core Commands

Most CPUs have specialized JTAG operations to support debugging. OpenOCD packages most such operations in its standard command framework. Some of those operations don't fit well in that framework, so they are exposed here as architecture or implementation (core) specific commands.

### 16.1 ARM Hardware Tracing

CPUs based on ARM cores may include standard tracing interfaces, based on an “Embedded Trace Module” (ETM) which sends voluminous address and data bus trace records to a “Trace Port”.

- Development-oriented boards will sometimes provide a high speed trace connector for collecting that data, when the particular CPU supports such an interface. (The standard connector is a 38-pin Mictor, with both JTAG and trace port support.) Those trace connectors are supported by higher end JTAG adapters and some logic analyzer modules; frequently those modules can buffer several megabytes of trace data. Configuring an ETM coupled to such an external trace port belongs in the board-specific configuration file.
- If the CPU doesn't provide an external interface, it probably has an “Embedded Trace Buffer” (ETB) on the chip, which is a dedicated SRAM. 4KBytes is one common ETB size. Configuring an ETM coupled only to an ETB belongs in the CPU-specific (target) configuration file, since it works the same on all boards.

ETM support in OpenOCD doesn't seem to be widely used yet.

> Issues: ETM support may be buggy, and at least some `etm config` parameters should be detected by asking the ETM for them.

> ETM trigger events could also implement a kind of complex hardware breakpoint, much more powerful than the simple watchpoint hardware exported by EmbeddedICE modules. Such breakpoints can be triggered even when using the dummy trace port driver.

> It seems like a GDB hookup should be possible, as well as tracing only during specific states (perhaps handling IRQ 23 or calls foo()).

> There should be GUI tools to manipulate saved trace data and help analyse it in conjunction with the source code. It's unclear how much of a common interface is shared with the current XScale trace support, or should be shared with eventual Nexus-style trace module support.

> At this writing (November 2009) only ARM7, ARM9, and ARM11 support for ETM modules is available. The code should be able to work with some newer cores; but not all of them support this original style of JTAG access.

#### 16.1.1 ETM Configuration

ETM setup is coupled with the trace port driver configuration.

— Config Command: etm config target width mode clocking driver

> Declares the ETM associated with target, and associates it with a given trace port driver. See Trace Port Drivers.

> Several of the parameters must reflect the trace port capabilities, which are a function of silicon capabilties (exposed later using `etm info`) and of what hardware is connected to that port (such as an external pod, or ETB). The width must be either 4, 8, or 16, except with ETMv3.0 and newer modules which may also support 1, 2, 24, 32, 48, and 64 bit widths. (With those versions, `etm info` also shows whether the selected port width and mode are supported.)

> The mode must be `normal`, `multiplexed`, or `demultiplexed`. The clocking must be `half` or `full`.

> > Warning: With ETMv3.0 and newer, the bits set with the mode and clocking parameters both control the mode. This modified mode does not map to the values supported by previous ETM modules, so this syntax is subject to change.

> > Note: You can see the ETM registers using the `reg` command. Not all possible registers are present in every ETM. Most of the registers are write-only, and are used to configure what CPU activities are traced.

— Command: etm info

> Displays information about the current target's ETM. This includes resource counts from the `ETM_CONFIG` register, as well as silicon capabilities (except on rather old modules). from the `ETM_SYS_CONFIG` register.

— Command: etm status

> Displays status of the current target's ETM and trace port driver: is the ETM idle, or is it collecting data? Did trace data overflow? Was it triggered?

— Command: etm tracemode [type context_id_bits cycle_accurate branch_output]

> Displays what data that ETM will collect. If arguments are provided, first configures that data. When the configuration changes, tracing is stopped and any buffered trace data is invalidated.

> - type ... describing how data accesses are traced, when they pass any ViewData filtering that that was set up. The value is one of `none` (save nothing), `data` (save data), `address` (save addresses), `all` (save data and addresses)
> - context_id_bits ... 0, 8, 16, or 32
> - cycle_accurate ... `enable` or `disable` cycle-accurate instruction tracing. Before ETMv3, enabling this causes much extra data to be recorded.
> - branch_output ... `enable` or `disable`. Disable this unless you need to try reconstructing the instruction trace stream without an image of the code.

— Command: etm trigger_debug (`enable`|`disable`)

> Displays whether ETM triggering debug entry (like a breakpoint) is enabled or disabled, after optionally modifying that configuration. The default behaviour is `disable`. Any change takes effect after the next `etm start`.

> By using script commands to configure ETM registers, you can make the processor enter debug state automatically when certain conditions, more complex than supported by the breakpoint hardware, happen.

#### 16.1.2 ETM Trace Operation

After setting up the ETM, you can use it to collect data. That data can be exported to files for later analysis. It can also be parsed with OpenOCD, for basic sanity checking.

To configure what is being traced, you will need to write various trace registers using `reg ETM_*` commands. For the definitions of these registers, read ARM publication IHI 0014, “Embedded Trace Macrocell, Architecture Specification”. Be aware that most of the relevant registers are write-only, and that ETM resources are limited. There are only a handful of address comparators, data comparators, counters, and so on.

Examples of scenarios you might arrange to trace include:

- Code flow within a function, excluding subroutines it calls. Use address range comparators to enable tracing for instruction access within that function's body.
- Code flow within a function, including subroutines it calls. Use the sequencer and address comparators to activate tracing on an “entered function” state, then deactivate it by exiting that state when the function's exit code is invoked.
- Code flow starting at the fifth invocation of a function, combining one of the above models with a counter.
- CPU data accesses to the registers for a particular device, using address range comparators and the ViewData logic.
- Such data accesses only during IRQ handling, combining the above model with sequencer triggers which on entry and exit to the IRQ handler.
- ... more

At this writing, September 2009, there are no Tcl utility procedures to help set up any common tracing scenarios.

— Command: etm analyze

> Reads trace data into memory, if it wasn't already present. Decodes and prints the data that was collected.

— Command: etm dump filename

> Stores the captured trace data in `filename`.

— Command: etm image filename [base_address] [type]

> Opens an image file.

— Command: etm load filename

> Loads captured trace data from `filename`.

— Command: etm start

> Starts trace data collection.

— Command: etm stop

> Stops trace data collection.

#### 16.1.3 Trace Port Drivers

To use an ETM trace port it must be associated with a driver.

— Trace Port Driver: dummy

> Use the `dummy` driver if you are configuring an ETM that's not connected to anything (on-chip ETB or off-chip trace connector). This driver lets OpenOCD talk to the ETM, but it does not expose any trace data collection.

> — Config Command: etm_dummy config target

> > Associates the ETM for target with a dummy driver.

— Trace Port Driver: etb

> Use the `etb` driver if you are configuring an ETM to use on-chip ETB memory.

> — Config Command: etb config target etb_tap

> > Associates the ETM for target with the ETB at etb_tap. You can see the ETB registers using the `reg` command.

> — Command: etb trigger_percent [percent]

> > This displays, or optionally changes, ETB behavior after the ETM's configured trigger event fires. It controls how much more trace data is saved after the (single) trace trigger becomes active.

> > - The default corresponds to trace around usage, recording 50 percent data before the event and the rest afterwards.
> > - The minimum value of percent is 2 percent, recording almost exclusively data before the trigger. Such extreme trace before usage can help figure out what caused that event to happen.
> > - The maximum value of percent is 100 percent, recording data almost exclusively after the event. This extreme trace after usage might help sort out how the event caused trouble.

— Trace Port Driver: oocd_trace

> This driver isn't available unless OpenOCD was explicitly configured with the `--enable-oocd_trace` option. You probably don't want to configure it unless you've built the appropriate prototype hardware; it's proof-of-concept software.

> Use the `oocd_trace` driver if you are configuring an ETM that's connected to an off-chip trace connector.

> — Config Command: oocd_trace config target tty

> > Associates the ETM for target with a trace driver which collects data through the serial port tty.

> — Command: oocd_trace resync

> > Re-synchronizes with the capture clock.

> — Command: oocd_trace status

> > Reports whether the capture clock is locked or not.

### 16.2 Generic ARM

These commands should be available on all ARM processors. They are available in addition to other core-specific commands that may be available.

— Command: arm core_state [`arm`|`thumb`]

> Displays the core_state, optionally changing it to process either `arm` or `thumb` instructions. The target may later be resumed in the currently set core_state. (Processors may also support the Jazelle state, but that is not currently supported in OpenOCD.)

— Command: arm disassemble address [count [`thumb`]]

> Disassembles count instructions starting at address. If count is not specified, a single instruction is disassembled. If `thumb` is specified, or the low bit of the address is set, Thumb2 (mixed 16/32-bit) instructions are used; else ARM (32-bit) instructions are used. (Processors may also support the Jazelle state, but those instructions are not currently understood by OpenOCD.)

> Note that all Thumb instructions are Thumb2 instructions, so older processors (without Thumb2 support) will still see correct disassembly of Thumb code. Also, ThumbEE opcodes are the same as Thumb2, with a handful of exceptions. ThumbEE disassembly currently has no explicit support.

— Command: arm mcr pX op1 CRn CRm op2 value

> Write value to a coprocessor pX register passing parameters CRn, CRm, opcodes opc1 and opc2, and using the MCR instruction. (Parameter sequence matches the ARM instruction, but omits an ARM register.)

— Command: arm mrc pX coproc op1 CRn CRm op2

> Read a coprocessor pX register passing parameters CRn, CRm, opcodes opc1 and opc2, and the MRC instruction. Returns the result so it can be manipulated by Jim scripts. (Parameter sequence matches the ARM instruction, but omits an ARM register.)

— Command: arm reg

> Display a table of all banked core registers, fetching the current value from every core mode if necessary.

— Command: arm semihosting [`enable`|`disable`]

> Display status of semihosting, after optionally changing that status.

> Semihosting allows for code executing on an ARM target to use the I/O facilities on the host computer i.e. the system where OpenOCD is running. The target application must be linked against a library implementing the ARM semihosting convention that forwards operation requests by using a special SVC instruction that is trapped at the Supervisor Call vector by OpenOCD.

### 16.3 ARMv4 and ARMv5 Architecture

The ARMv4 and ARMv5 architectures are widely used in embedded systems, and introduced core parts of the instruction set in use today. That includes the Thumb instruction set, introduced in the ARMv4T variant.

#### 16.3.1 ARM7 and ARM9 specific commands

These commands are specific to ARM7 and ARM9 cores, like ARM7TDMI, ARM720T, ARM9TDMI, ARM920T or ARM926EJ-S. They are available in addition to the ARM commands, and any other core-specific commands that may be available.

— Command: arm7_9 dbgrq [`enable`|`disable`]

> Displays the value of the flag controlling use of the the EmbeddedIce DBGRQ signal to force entry into debug mode, instead of breakpoints. If a boolean parameter is provided, first assigns that flag.

> This should be safe for all but ARM7TDMI-S cores (like NXP LPC). This feature is enabled by default on most ARM9 cores, including ARM9TDMI, ARM920T, and ARM926EJ-S.

— Command: arm7_9 dcc_downloads [`enable`|`disable`]

> Displays the value of the flag controlling use of the debug communications channel (DCC) to write larger (>128 byte) amounts of memory. If a boolean parameter is provided, first assigns that flag.

> DCC downloads offer a huge speed increase, but might be unsafe, especially with targets running at very low speeds. This command was introduced with OpenOCD rev. 60, and requires a few bytes of working area.

— Command: arm7_9 fast_memory_access [`enable`|`disable`]

> Displays the value of the flag controlling use of memory writes and reads that don't check completion of the operation. If a boolean parameter is provided, first assigns that flag.

> This provides a huge speed increase, especially with USB JTAG cables (FT2232), but might be unsafe if used with targets running at very low speeds, like the 32kHz startup clock of an AT91RM9200.

#### 16.3.2 ARM720T specific commands

These commands are available to ARM720T based CPUs, which are implementations of the ARMv4T architecture based on the ARM7TDMI-S integer core. They are available in addition to the ARM and ARM7/ARM9 commands.

— Command: arm720t cp15 opcode [value]

> DEPRECATED – avoid using this. Use the `arm mrc` or `arm mcr` commands instead.

> Display cp15 register returned by the ARM instruction opcode; else if a value is provided, that value is written to that register. The opcode should be the value of either an MRC or MCR instruction.

#### 16.3.3 ARM9 specific commands

ARM9-family cores are built around ARM9TDMI or ARM9E (including ARM9EJS) integer processors. Such cores include the ARM920T, ARM926EJ-S, and ARM966.

— Command: arm9 vector_catch [`all`|`none`|list]

> Vector Catch hardware provides a sort of dedicated breakpoint for hardware events such as reset, interrupt, and abort. You can use this to conserve normal breakpoint resources, so long as you're not concerned with code that branches directly to those hardware vectors.

> This always finishes by listing the current configuration. If parameters are provided, it first reconfigures the vector catch hardware to intercept `all` of the hardware vectors, `none` of them, or a list with one or more of the following: `reset` `undef` `swi` `pabt` `dabt` `irq` `fiq`.

#### 16.3.4 ARM920T specific commands

These commands are available to ARM920T based CPUs, which are implementations of the ARMv4T architecture built using the ARM9TDMI integer core. They are available in addition to the ARM, ARM7/ARM9, and ARM9 commands.

— Command: arm920t cache_info

> Print information about the caches found. This allows to see whether your target is an ARM920T (2x16kByte cache) or ARM922T (2x8kByte cache).

— Command: arm920t cp15 regnum [value]

> Display cp15 register regnum; else if a value is provided, that value is written to that register. This uses "physical access" and the register number is as shown in bits 38..33 of table 9-9 in the ARM920T TRM. (Not all registers can be written.)

— Command: arm920t cp15i opcode [value [address]]

> DEPRECATED – avoid using this. Use the `arm mrc` or `arm mcr` commands instead.

> Interpreted access using ARM instruction opcode, which should be the value of either an MRC or MCR instruction (as shown tables 9-11, 9-12, and 9-13 in the ARM920T TRM). If no value is provided, the result is displayed. Else if that value is written using the specified address, or using zero if no other address is provided.

— Command: arm920t read_cache filename

> Dump the content of ICache and DCache to a file named `filename`.

— Command: arm920t read_mmu filename

> Dump the content of the ITLB and DTLB to a file named `filename`.

#### 16.3.5 ARM926ej-s specific commands

These commands are available to ARM926ej-s based CPUs, which are implementations of the ARMv5TEJ architecture based on the ARM9EJ-S integer core. They are available in addition to the ARM, ARM7/ARM9, and ARM9 commands.

The Feroceon cores also support these commands, although they are not built from ARM926ej-s designs.

— Command: arm926ejs cache_info

> Print information about the caches found.

#### 16.3.6 ARM966E specific commands

These commands are available to ARM966 based CPUs, which are implementations of the ARMv5TE architecture. They are available in addition to the ARM, ARM7/ARM9, and ARM9 commands.

— Command: arm966e cp15 regnum [value]

> Display cp15 register regnum; else if a value is provided, that value is written to that register. The six bit regnum values are bits 37..32 from table 7-2 of the ARM966E-S TRM. There is no current control over bits 31..30 from that table, as required for BIST support.

#### 16.3.7 XScale specific commands

Some notes about the debug implementation on the XScale CPUs:

The XScale CPU provides a special debug-only mini-instruction cache (mini-IC) in which exception vectors and target-resident debug handler code are placed by OpenOCD. In order to get access to the CPU, OpenOCD must point vector 0 (the reset vector) to the entry of the debug handler. However, this means that the complete first cacheline in the mini-IC is marked valid, which makes the CPU fetch all exception handlers from the mini-IC, ignoring the code in RAM.

To address this situation, OpenOCD provides the `xscale vector_table` command, which allows the user to explicity write individual entries to either the high or low vector table stored in the mini-IC.

It is recommended to place a pc-relative indirect branch in the vector table, and put the branch destination somewhere in memory. Doing so makes sure the code in the vector table stays constant regardless of code layout in memory:

         _vectors:
                 ldr     pc,[pc,#0x100-8]
                 ldr     pc,[pc,#0x100-8]
                 ldr     pc,[pc,#0x100-8]
                 ldr     pc,[pc,#0x100-8]
                 ldr     pc,[pc,#0x100-8]
                 ldr     pc,[pc,#0x100-8]
                 ldr     pc,[pc,#0x100-8]
                 ldr     pc,[pc,#0x100-8]
                 .org 0x100
                 .long real_reset_vector
                 .long real_ui_handler
                 .long real_swi_handler
                 .long real_pf_abort
                 .long real_data_abort
                 .long 0 /* unused */
                 .long real_irq_handler
                 .long real_fiq_handler

Alternatively, you may choose to keep some or all of the mini-IC vector table entries synced with those written to memory by your system software. The mini-IC can not be modified while the processor is executing, but for each vector table entry not previously defined using the `xscale vector_table` command, OpenOCD will copy the value from memory to the mini-IC every time execution resumes from a halt. This is done for both high and low vector tables (although the table not in use may not be mapped to valid memory, and in this case that copy operation will silently fail). This means that you will need to briefly halt execution at some strategic point during system start-up; e.g., after the software has initialized the vector table, but before exceptions are enabled. A breakpoint can be used to accomplish this once the appropriate location in the start-up code has been identified. A watchpoint over the vector table region is helpful in finding the location if you're not sure. Note that the same situation exists any time the vector table is modified by the system software.

The debug handler must be placed somewhere in the address space using the `xscale debug_handler` command. The allowed locations for the debug handler are either (0x800 - 0x1fef800) or (0xfe000800 - 0xfffff800). The default value is 0xfe000800.

These commands are available to XScale based CPUs, which are implementations of the ARMv5TE architecture.

— Command: xscale analyze_trace

> Displays the contents of the trace buffer.

— Command: xscale cache_clean_address address

> Changes the address used when cleaning the data cache.

— Command: xscale cache_info

> Displays information about the CPU caches.

— Command: xscale cp15 regnum [value]

> Display cp15 register regnum; else if a value is provided, that value is written to that register.

— Command: xscale debug_handler target address

> Changes the address used for the specified target's debug handler.

— Command: xscale dcache [`enable`|`disable`]

> Enables or disable the CPU's data cache.

— Command: xscale dump_trace filename

> Dumps the raw contents of the trace buffer to `filename`.

— Command: xscale icache [`enable`|`disable`]

> Enables or disable the CPU's instruction cache.

— Command: xscale mmu [`enable`|`disable`]

> Enables or disable the CPU's memory management unit.

— Command: xscale trace_buffer [`enable`|`disable` [`fill` [n] | `wrap`]]

> Displays the trace buffer status, after optionally enabling or disabling the trace buffer and modifying how it is emptied.

— Command: xscale trace_image filename [offset [type]]

> Opens a trace image from `filename`, optionally rebasing its segment addresses by offset. The image type may be one of `bin` (binary), `ihex` (Intel hex), `elf` (ELF file), `s19` (Motorola s19), `mem`, or `builder`.

— Command: xscale vector_catch [mask]

> Display a bitmask showing the hardware vectors to catch. If the optional parameter is provided, first set the bitmask to that value.

> The mask bits correspond with bit 16..23 in the DCSR:

>               0x01    Trap Reset
>               0x02    Trap Undefined Instructions
>               0x04    Trap Software Interrupt
>               0x08    Trap Prefetch Abort
>               0x10    Trap Data Abort
>               0x20    reserved
>               0x40    Trap IRQ
>               0x80    Trap FIQ

— Command: xscale vector_table [(`low`|`high`) index value]

> Set an entry in the mini-IC vector table. There are two tables: one for low vectors (at 0x00000000), and one for high vectors (0xFFFF0000), each holding the 8 exception vectors. index can be 1-7, because vector 0 points to the debug handler entry and can not be overwritten. value holds the 32-bit opcode that is placed in the mini-IC.

> Without arguments, the current settings are displayed.

### 16.4 ARMv6 Architecture

#### 16.4.1 ARM11 specific commands

— Command: arm11 memwrite burst [`enable`|`disable`]

> Displays the value of the memwrite burst-enable flag, which is enabled by default. If a boolean parameter is provided, first assigns that flag. Burst writes are only used for memory writes larger than 1 word. They improve performance by assuming that the CPU has read each data word over JTAG and completed its write before the next word arrives, instead of polling for a status flag to verify that completion. This is usually safe, because JTAG runs much slower than the CPU.

— Command: arm11 memwrite error_fatal [`enable`|`disable`]

> Displays the value of the memwrite error_fatal flag, which is enabled by default. If a boolean parameter is provided, first assigns that flag. When set, certain memory write errors cause earlier transfer termination.

— Command: arm11 step_irq_enable [`enable`|`disable`]

> Displays the value of the flag controlling whether IRQs are enabled during single stepping; they are disabled by default. If a boolean parameter is provided, first assigns that.

— Command: arm11 vcr [value]

> Displays the value of the Vector Catch Register (VCR), coprocessor 14 register 7. If value is defined, first assigns that.

> Vector Catch hardware provides dedicated breakpoints for certain hardware events. The specific bit values are core-specific (as in fact is using coprocessor 14 register 7 itself) but all current ARM11 cores except the ARM1176 use the same six bits.

### 16.5 ARMv7 Architecture

#### 16.5.1 ARMv7 Debug Access Port (DAP) specific commands

These commands are specific to ARM architecture v7 Debug Access Port (DAP), included on Cortex-M3 and Cortex-A8 systems. They are available in addition to other core-specific commands that may be available.

— Command: dap apid [num]

> Displays ID register from AP num, defaulting to the currently selected AP.

— Command: dap apsel [num]

> Select AP num, defaulting to 0.

— Command: dap baseaddr [num]

> Displays debug base address from MEM-AP num, defaulting to the currently selected AP.

— Command: dap info [num]

> Displays the ROM table for MEM-AP num, defaulting to the currently selected AP.

— Command: dap memaccess [value]

> Displays the number of extra tck cycles in the JTAG idle to use for MEM-AP memory bus access [0-255], giving additional time to respond to reads. If value is defined, first assigns that.

#### 16.5.2 Cortex-M3 specific commands

— Command: cortex_m3 maskisr (`on`|`off`)

> Control masking (disabling) interrupts during target step/resume.

— Command: cortex_m3 vector_catch [`all`|`none`|list]

> Vector Catch hardware provides dedicated breakpoints for certain hardware events.

> Parameters request interception of `all` of these hardware event vectors, `none` of them, or one or more of the following: `hard_err` for a HardFault exception; `mm_err` for a MemManage exception; `bus_err` for a BusFault exception; `irq_err`, `state_err`, `chk_err`, or `nocp_err` for various UsageFault exceptions; or `reset`. If NVIC setup code does not enable them, MemManage, BusFault, and UsageFault exceptions are mapped to HardFault. UsageFault checks for divide-by-zero and unaligned access must also be explicitly enabled.

> This finishes by listing the current vector catch configuration.

### 16.6 Software Debug Messages and Tracing

OpenOCD can process certain requests from target software, when the target uses appropriate libraries. The most powerful mechanism is semihosting, but there is also a lighter weight mechanism using only the DCC channel.

Currently `target_request debugmsgs` is supported only for `arm7_9` and `cortex_m3` cores. These messages are received as part of target polling, so you need to have `poll on` active to receive them. They are intrusive in that they will affect program execution times. If that is a problem, see ARM Hardware Tracing.

See `libdcc` in the contrib dir for more details. In addition to sending strings, characters, and arrays of various size integers from the target, `libdcc` also exports a software trace point mechanism. The target being debugged may issue trace messages which include a 24-bit trace point number. Trace point support includes two distinct mechanisms, each supported by a command:

- History ... A circular buffer of trace points can be set up, and then displayed at any time. This tracks where code has been, which can be invaluable in finding out how some fault was triggered.

  The buffer may overflow, since it collects records continuously. It may be useful to use some of the 24 bits to represent a particular event, and other bits to hold data.

- Counting ... An array of counters can be set up, and then displayed at any time. This can help establish code coverage and identify hot spots.

  The array of counters is directly indexed by the trace point number, so trace points with higher numbers are not counted.

Linux-ARM kernels have a “Kernel low-level debugging via EmbeddedICE DCC channel” option (CONFIG_DEBUG_ICEDCC, depends on CONFIG_DEBUG_LL) which uses this mechanism to deliver messages before a serial console can be activated. This is not the same format used by `libdcc`. Other software, such as the U-Boot boot loader, sometimes does the same thing.

— Command: target_request debugmsgs [`enable`|`disable`|`charmsg`]

> Displays current handling of target DCC message requests. These messages may be sent to the debugger while the target is running. The optional `enable` and `charmsg` parameters both enable the messages, while `disable` disables them.

> With `charmsg` the DCC words each contain one character, as used by Linux with CONFIG_DEBUG_ICEDCC; otherwise the libdcc format is used.

— Command: trace history [`clear`|count]

> With no parameter, displays all the trace points that have triggered in the order they triggered. With the parameter `clear`, erases all current trace history records. With a count parameter, allocates space for that many history records.

— Command: trace point [`clear`|identifier]

> With no parameter, displays all trace point identifiers and how many times they have been triggered. With the parameter `clear`, erases all current trace point counters. With a numeric identifier parameter, creates a new a trace point counter and associates it with that identifier.

> Important: The identifier and the trace point number are not related except by this command. These trace point numbers always start at zero (from server startup, or after `trace point clear`) and count up from there.