About accessing AHB, APB, and AXI buses
Arm®-based systems connect the processors, memories and peripherals using buses. Examples of common bus types include AMBA High-performance Bus (AHB), Advanced Peripheral Bus (APB), and Advanced eXtensible Interface (AXI).
In some systems, these buses are accessible from the debug interface. Where this is the case, then Arm Debugger provides access to these buses when performing bare-metal or kernel debugging. Buses are exposed within the debugger as additional address spaces. Accesses to these buses are available irrespective of whether the processor is running or halted.
Within a debug session in Arm Debugger you can discover which buses are available using the
info memory command. The address and description columns in the output of this command explain what each address space represents and how the debugger accesses it.
You can use
AXI: address prefixes for these buses anywhere in the debugger where you normally enter an address or expression. For example, assuming that the debugger provides an APB address space, then you can print the contents of address zero using the following command:
When using address prefixes in expressions, you can also use address space parameters to specify additional behavior. See Address space prefixes for information on how to do this.
Each address space has a size, which is the number of bits that comprise the address. Common address space size on embedded and low-end devices is 32-bits, higher-end devices that require more memory might use > 32-bits. As an example, some devices based around Arm architecture Armv7 make use of LPAE (Large Physical Address Extensions) to extend physical addresses on the AXI bus to 40-bits, even though virtual addresses within the processor are 32-bits.
The exact topology of the buses and their connection to the debug interface is dependent on your system. See the CoreSight™ specifications for your hardware for more information. Typically, the debug access to these buses bypass the processor, and so does not take into account memory mappings or caches within the processor itself. It is implementation dependent on whether accesses to the buses occur before or after any other caches in the system, such as L2 or L3 caches. The debugger does not attempt to achieve coherency between caches in your system when accessing these buses and it is your responsibility to take this into account and manually perform any clean or flush operations as required.
For example, to achieve cache coherency when debugging an image with the processors level 1 cache enabled, you must clean and invalidate portions of the L1 cache prior to modifying any of your application code or data using the AHB address space. This ensures that any existing changes in the cache are written out to memory before writing to that address space, and that the processor correctly reads your modification when execution resumes.
The behavior when accessing unallocated addresses is undefined, and depending on your system can lead to locking up the buses. It is recommended that you only access those specific addresses that are defined in your system. You can use the
memory command to redefine the memory regions within the debugger and modifying access rights to control the addresses. You can use the
x command with the
<count> option to limit the amount of memory that is read.