Background memory access | ARM ARM DUI 0137A guide

Debugging with RMHost

3.1.2Background 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.