Description
When benchmarking your code with ARMulator, you can describe the memory map of your system to armsd (and ADW) by using an 'armsd.map' file. armsd.map contains information such as: where ROM and RAM is located, how fast it is, how wide it is, etc.

An armsd.map typically contains something like:

00000000 40000000 RAM 4 RW 135/85 135/85
40000000 40000000 ROM 2 R 100/100 100/100   

You can then use $memstats provided by armsd (and ADW in View->Debugger Internals) to monitor read write accesses to these areas of memory. A detailed description of the map file format is given in the SDT 2.11 User Guide, section 8.3.5 and SDT 2.50 User Guide, section 11.3.5. If you do not specify a map file, the ARMulator will use a 'flat' 4GB bank of 'ideal' 32-bit memory (no wait states).

A similar mechanism can also be used during code debugging, to detect whether a program is accessing memory outside the expected range.

Solution
To ensure that you have described all areas of memory you think the image should access, you can define a single memory region that covers the entire address range as the map file's last line, e.g. to the armsd.map file above, you could add:

00000000 100000000 DUMMY 4 RW 1/1 1/1 

You can then detect if any reads or writes are occurring outside the regions of memory you expect using the command 'print $memory_statistics'. This can be a very useful debugging tool.

Alternatively, you can also force an abort to be generated for memory accesses outside your programs expected range by putting a '-' in the 'rw' field of your map file, which means 'no read or write access', e.g. to the armsd.map file above, you could add:

80000000 80000000 DUMMY 4 - 1/1 1/1 

ARMulator will then abort (either a prefetch abort or data abort) when the offending instruction reaches the execution stage of the pipeline.

Note that the default positions of the stack and heap are specified in armul.cnf (though these may be overriden by your initialisation code). The map file must define RW areas that are the same or greater in size and at the same locations as those specified for the heap and stack in armul.cnf, otherwise a Data Abort may occur.