OOMRM Address Space Usage

In some cases, it might be necessary to change the RAM/ROM loading options. Doing this requires understanding program allocation basics. Since I have the 512K RAM, 512K ROM option, all examples will use that. Use of the model library requires 512K or RAM as the A* algorithm can use upwards to 200K. There are two basic ways to load a program:

RAM - this loads all the program into RAM address space
ROM - this actually loads the static portions into ROM and the dynamic data (stack, heap, etc.) into RAM (this is the default).

RAM

All RAM consists of one of two types:

Heap space - Ram for global variables, static variables, malloc, etc. (grows from bottom up)
Stack space - All data passed as arguments and local variables (grows from top down).

The RAM address starts at 0 and ends at 7FFFF (512K), but 0-2FFF are used by CPU32BUG. Immediately followed by the initialized data (.data) at 0x3000 with the heap soon following.

Flash

The ROM address starts after RAM at 0x80000 and ends at 0xFFFFF. This is where the program and constructor/destructor lists are stored. As noted, the OOMRM library always uses the ROM loaded option; furthermore, the navigational model requires preallocation of RAM as defined in the current loader script leaving only about 200K RAM available for user program. For only normal functions, I have found less than 50K of RAM is usually sufficient. If you do need a large structure, be sure to make it local to the TASK_RAM area. The RAM/ROM is broken down as follows:

ROM Loaded (RTOS) Program Space

Address	Purpose
0-3FF (1K)	RAM start. [68332um 4.7.1] Target exception vector table (See also VBR)
400-7FF (1K)	CPU32BUG vector table
800-2FFF (10K)	CPU32BUG variables/stack
3000-3400	oCameraGB scratch pad (256 bytes)
3400	.data section (initialized variables)
	.bss (block starting symbol) contains zeroed bytes
	start of heap space (grows up)
User RAM	206K Usable combined heap/stack space.
0x36FFC	top of stack space (grows down)
0x37000	TASK_RAM : Broker task for all functions with large RAM allocations (250K)
0x757FC	BASE_RAM (MAP_RAM): RAM for the occupancy grid; approx 100x100 max. (40K)
0x7F7FC	WAYPOINT_RAM: stores waypoints for mission profile. (1K)
0x7FBFC	ID_RAM: storage of persistent values--x,y,map size, etc. (1K)
7FFFF	top of RAM
80000-8FFFF	ROM start. Mark's modified CPU32BUG (64K). Note, Mark's modified LO command will not allow writes to this sector.
90000	contents always "beefbeef"
	.text (code and constants)
	constructor/destructor list
	.data (ROM)

Determining RAM Usage

The following procedure can be used to determine the current RAM usage:

Open the map file for your current compile (.map)
Search for __data_start (most linker scripts will set this). On my it is at 0x3100
Copy from the _data_start to the __end__ symbol and paste in a new file.
Cut the beginning columns from this file upto the address column (with your favorite tool) and save file.
Sort the above file

The results will show RAM in address order. You can also determine each variables RAM size by simple subtraction of column with previous.