<< Previous | Index | Next >>

5. RabbitSys Memory Management

This chapter discusses RabbitSys memory allocation and protection. Separate instruction and data (I&D) space must be enabled when using RabbitSys with the Rabbit 3000A processor.

5.1 Memory Allocation

The root and xmem memory regions are split into two separate areas: the User space and the System space. RabbitSys manages all xmem and root data allocation for the user program.

The API functions for RabbitSys memory allocation are found in Chapter Appendix C. "RabbitSys API Functions." This interface is similar to the Dynamic C xalloc API.

5.1.1 Memory Mapping

A new memory mapping strategy has been adopted to optimize the RabbitSys environment. The compile mode described in the following section is based on the specific memory option for the core module.

5.1.1.1 Compile to Flash, Run in SRAM

Figure 5-1 shows an optimal memory mapping for boards with fast volatile SRAM¹, battery-backed SRAM and flash; boards like the RCM3365. The addresses used are approximate.

The mapping in Figure 5-1 is based on the MMU register values shown in the key. For details on how the register values determine the mapping, see technical notes TN202, "Rabbit Memory Management in a Nutshell" and/or TN241, "Accessing Large Memories and Bank-Switching with the Rabbit."

Figure 5-1. Compile to Flash, Run in Fast SRAM

The logical to physical mapping (i.e., the MMU mapping) is shown by the solid lines. After the program is compiled to the physical flash device, code and data are copied to fast SRAM. The dashed lines show this run-time mapping. Notice that the flash device already contained RabbitSys code on sector boundaries, which was also copied to fast SRAM on startup.

5.2 Memory Protection

RabbitSys relies on the Rabbit microprocessor User/System mode of operation to protect the system, including memory resources, from unauthorized access. As mentioned at the beginning of this chapter, there are two distinct areas in both the root and xmem regions of memory. The application is disallowed from directly accessing any memory that is in System space.

5.2.1 Write Protect Registers

System write protect registers are used by the system to ensure that system code and data are protected from errant applications. To achieve more granularity for memory protection beyond the quadrant protection available in the MBxCR registers, the Rabbit 3000 has two 8-bit control registers; each bit controls a 4K or 64K block of memory of the 1MB physical address space. The Rabbit 4000 has a much larger physical address space of 16MB and so has 32 8-bit registers that control write protection for each of the 256 64K segments. In addition, granularity of 4K is available for any two of the 256 segments.

5.2.2 Stack Information

Most stacks are allocated out of User memory because an application and RabbitSys share a common stack for syscalls and interrupts when an application is running correctly. Because stacks are one area of memory particularly vulnerable to corruption, the common stack is protected from stack underflow and stack overflow using the stack limit registers (STKHLR and STKLLR), which protect the top 16 bytes and bottom 272 bytes of the stack.

The constant _SYS_DEFSTACKSIZE defines the default stack size in bytes; it is initialized to 4096.

5.2.2.1 System Stack

When the user program is not present or is invalid, RabbitSys switches to a system stack that is in system space. The system stack is protected from User mode code and so can not be corrupted by an errant application.

5.2.2.2 µC/OS-II Stacks

Any stacks used by µC/OS-II tasks are allocated out of User space via xalloc(). All stacks used in a µC/OS-II application must be large enough to run RabbitSys. The µC/OS-II library was updated for RabbitSys to use a 4K idle task. This is a safe size. A 1 or 2K stack may be okay; to find out, you must test it.

¹ Also known as program execution SRAM