Viewing and modifying memory can be a crucial debugging technique. A debugger may have more than one way to access memory on a target. The two most common access methods are using the processor or using the CoreSight debug infrastructure. We will describe each access method, but we will not describe in detail how these access methods are achieved.

Memory access using a processor

Most debuggers will default to performing memory reads and writes by executing instructions on the processor and using the Debug Communications Channel DCC to input and retrieve the data. Because the memory accesses are performed by the processor, this method means that:

  • The instructions used to perform the access should be an appropriate length size and byte size for the memory being accessed. Most debuggers will default to a certain length and byte size if none are specified.
  • The memory accesses are treated in the same way as if software had issued them. This means that they are subject to translation, permission checking, and ordering rules.
  • The processor must be in Debug state (stopped or halted) for the accesses to be performed.

As mentioned in Run control options, performing a memory read or write can subtly change the processor state especially if the memory management unit (MMU) and caches are enabled. This is worth keeping in mind if you see unexpected behavior involving caches or timing when performing memory accesses with a debugger.

Memory access using the CoreSight debug infrastructure

The Armv8-A architecture uses a debug infrastructure called CoreSight. The CoreSight infrastructure attaches compatible logic to the different Access Ports (APs) of a Debug Access Port (DAP). A typical debugger setup will perform debug operations in this way:

  1. The debugger passes commands to the connected debug adapter
  2. The debug adapter will pass commands to the DAP via a debug connector (like Joint Test Action Group (JTAG) or Serial Wire Debug (SWD)
  3. The DAP will access the appropriate Access Ports to perform the requested debug operations

Depending on the SoC design, the DAP may contain an AMBA High-performance Bus Access Port (AHB-AP) or an Advanced Extensible Interface Access Port (AXI-AP). The AHB-APs or AXI-APs connect to buses able to access memory. If these connections exist, some debuggers will allow users to access memory via the DAP AHB-APs or AXI-APs. The following diagram illustrates the typical connections between a debugger, a DAP, and a target’s memory:


Because the reads and writes of the memory directly access memory, this method means that:

  • The access will involve doing debugger memory access commands. The access size and length will be entirely dependent on the debugger being used.
  • The address used will always be a physical address.
  • Because the access is not being done by the processor, the contents of the caches in the processors will not be updated.
  • The memory operations are not atomic or locked, so if other devices are accessing the same memory region at the same time, the data may be corrupted.
Previous Next