ARM ARM DUI 0137A User Manual

ARM DUI 0137A

33

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. 

 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.