3.15.3. Accessing the PTM registers

The following subsections describe the possible methods of accessing the PTM registers:

An implementation must include at least one interface to the registers, but whether each interface is supported is implementation defined. If more than one interface is implemented, the architecture supports concurrent access from multiple interfaces.

The description of each method of access includes details of any restrictions that apply to that method, but see also:

Coprocessor access

A coprocessor interface to the PTM registers enables you to use the PTM as an extended breakpoint unit, to test for unit failure when testing multiple devices. You can do the following without external hardware:

  • program the PTM

  • collect trace, in conjunction with the Embedded Trace Buffer (ETB)

  • examine the contents of the ETB, if implemented.

The following subsections describes how a coprocessor register interface changes the programmers model:

The coprocessor access model

Where a coprocessor model is supported, a single coprocessor gives access to all the accessible PTM registers. All instructions in Coprocessor 14 (CP14) with Opcode_1 equal to 1 are reserved for PTM use.

The registers you can access using the CP14 interface include the CoreSight management registers and the OS Save/Restore registers. See Organization of the PTM registers for a list of all the PTM registers, in register-number order.

Note

When accessed through the coprocessor interface, the Lock Access and Lock Status registers (registers 0x3EC and 0x3ED) read-as-zero. You do not have to set a lock to access the PTM registers through the coprocessor interface.

Use the following instructions to read and write the PTM registers:

MRC p14, 1, <Rd>, reg[9:7], reg[3:0], reg[6:4]
MCR p14, 1, <Rd>, reg[9:7], reg[3:0], reg[6:4]

In these instructions, reg[9:0] is the PTM register number, as Table 3.16 shows.

Figure 3.10 shows the mapping between the bits of the PTM register number and the fields of the CP14 instruction.

Figure 3.10. Mapping from register number to CP14 MRC or MCR instruction fields

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.


You can access the PTM registers through the coprocessor interface only when the processor is in a privileged mode. Any attempt to read or write a PTM register using coprocessor instructions when the processor is in User mode generates an Undefined Instruction exception. However, any coprocessor accesses initiated by a debug tool when the processor is halted in Debug state is always privileged regardless of the state of the CPSR.

A read from a nonexistent register returns zero, and a write to a nonexistent register is ignored. The tools must determine what registers are valid from the programmers model. For more information on access permissions see About the access permissions for PTM registers.

Access to PTM registers might also be prevented by controls in the processor. The CPACR, NSACR, and HCPTR (for Virtualization) include controls to trap accesses to PTM registers.

Note

This behavior is different to coprocessor access to debug registers, where attempting to access a nonexistent register usually results in an Undefined Instruction exception.

Determination of support

To determine whether coprocessor access is supported, read the ID Register. See ID Register, ETMIDR:

MRC p14, 1, <Rd>, c0, c9, 7

If this instruction does not generate an Undefined Instruction exception, and returns a nonzero value, then coprocessor access is supported.

Behavior of other CP14 accesses with Opcode_1 equal to 1

All CP14 access instructions with Opcode_1 equal to 1 are reserved for PTM use. However, only instructions with CRn values from b0000 to b0111 are used for PTM register accesses. MRC and MCR accesses to Coprocessor 14 with a CRn value of b1000 or greater are:

  • undefined in User mode

  • unpredictable in privileged modes.

Memory-mapped access

A PTM can provide memory-mapped access to its registers. This is usually required in a CoreSight system, and provides all the benefits of coprocessor access, along with other benefits described in the CoreSight Architecture Specification.

Memory-mapped access provides a 4KB address space, and gives access to all registers. Each register occupies 4 bytes, making a total of 1024 registers available in this way. For example, register 0x080 is at offset 0x200 from the base address of the PTM.

A read from a nonexistent register returns zero, and a write to a nonexistent register is ignored. Debug tools must use the programmers model to determine the registers that are valid.

For more information about register access permissions see About the access permissions for PTM registers.

The PTM can distinguish between memory-mapped accesses from:

  • on-chip software

  • a debugger, for example using the CoreSight Debug Access Port (DAP).

Software accesses require you to first unlock the PTM, using the lock registers described in About the lock registers.

Restrictions on the type of access to PTM registers

In About the PTM registers, Table 3.16 shows the access type, read-only, write-only, or read/write, of each PTM register. Debug software must take account of these access types. Behavior is unpredictable if you attempt a read access to a write-only register, or a write access to a read-only register. This is true for all methods of accessing the registers.

PTM register access models

Table 3.15 summarizes the more common PTM register access models, with an indication of the situations when they are likely to be appropriate.

Table 3.15. Typical PTM register access implementations

Register interfacesAccess requirements
Coprocessor only

Debugger access is through an ARM Debug Interface v5 [a].

In addition, software access is possible through the coprocessor interface.

Memory-mapped only

Debugger access is through an ARM Debug Interface v5 [a].

It is implementation defined whether software access is possible through the system memory map.

Coprocessor and memory-mapped

Debugger access is through an ARM Debug Interface v5 [a].

In addition, software access is possible through the coprocessor interface, and it is implementation defined whether software access is possible through the system memory map.

[a] For more information see the ARM Debug Interface v5 Architecture Specification.


For information about the access controls that can apply to PTM register accesses see About the access permissions for PTM registers.

Copyright © 1999-2002, 2004-2008, 2011 ARM. All rights reserved.ARM IHI 0035B
Non-ConfidentialID060811