In some systems, these buses are accessible from the debug interface. Where
this is the case, then DS-5 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 DS-5 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:
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
option to limit the amount of memory that is read.