Filter
Top Products
Debugging with RMHost
ARM DUI 0137A Copyright © 2000 ARM Limited. All rights reserved.. All rights reserved. 33
3.1.2 Background memory access
In addition to being able to access memory when your application is stopped (as with
Multi-ICE, for example), memory can also be read or written to while your application
is running.
Therefore, the memory and disassembly windows in the debugger you are using can be
opened and refreshed while your application is running. You can also view the contents
of non-automatic variables, that is, variables such as global variables and statics that are
not allocated to registers or the stack. However, this ability can be restricted while
debugging.
Memory can also be written to at any time. However you must be aware that read/write
operations might not be atomic to the application. Therefore, if a large structure is
viewed, for example, it might not be a consistent snapshot because data at the end of the
structure is likely to have been read later than data at the start of the structure. The same
problem exists with writes, so you must take care when updating such a structure when
consistency between the elements is required.
If RMTarget has not been built with support for word accesses, for example, RMHost
uses the supported access size (see
RM_OPT_WRITEWORDS
and
RM_OPT_READWORDS
in the
building chapter of the ARM RMTarget Integration Guide). For byte and halfword
accesses, RMTarget executes multiple memory-access instructions per word of data.
Note
This use of multiple memory-access instructions might cause unexpected results when
accessing certain peripherals, so be sure to enable those build options in RMTarget that
represent the access types supported by your peripherals.
While executing these instructions, your application is not running, but interrupts might
still be serviced. It is therefore essential that you take care when writing to variables
used by interrupt service routines.
RealMonitor also uses writes to memory to set software breakpoints. It is therefore
possible that when setting a breakpoint on an interrupt service routine, the routine might
execute before the breakpoint is fully set, causing the routine to malfunction (without
causing an undefined instruction or breakpoint). If this happens, an error message is not
necessarily displayed.
To work around this situation, RMHost always uses the ExecuteCode command to
ensure that writes of a single word (or halfword, if using Thumb), such as a breakpoint
instruction, are always atomic. That is, they use a single STR instruction (or STRH, if
using Thumb). This is not done for larger structures.