<< Previous | Index | Next >>

Chapter 6. The Rabbit BIOS

When Dynamic C compiles a user's program to a target board, the BIOS (Basic Input-Output System) is compiled first, as an integral part of the user's program. The BIOS is a separate program file that contains the code needed to interface with Dynamic C. It also normally contains a software interface to the user's particular hardware. Certain drivers in the Dynamic C libraries require BIOS routines to perform tasks that are hardware-dependent.The BIOS also:

• Provides a variety of low-level services for the user's program.

• Takes care of microprocessor system initialization.

• Provides the communications services required by Dynamic C for downloading code and performing debugging services such as setting breakpoints or examining data variables.

• Defines the setup of memory.

A single, general-purpose BIOS is supplied with Dynamic C for the Rabbit. This BIOS will allow you to boot Dynamic C on any Rabbit-based system that follows the basic design rules needed to support Dynamic C. The BIOS requires both a flash memory and a 32K or larger RAM or just a 128K RAM for it to be possible to compile and run Dynamic C programs. If the user uses a flash memory from the list of flash memories that are already supported by the BIOS, the task will be simplified. If the flash memory chip is not already supported, the user will have to write a driver to perform the write operation on the flash memory. This is not difficult provided that a system with 128K of RAM and the flash memory to be used is available for testing.

An existing BIOS can be used as a skeleton BIOS to create a new BIOS. Frequently it will only be necessary to change #define statements at the beginning of the BIOS. In this case it is unnecessary for the user to understand or work out the details of the memory setup and other processor initialization.

6.1 Startup Conditions Set Up By the BIOS

The BIOS sets up initial values for the following registers by means of code and declarations.

• The four memory bank control registers --MB0CR, MB1CR, MB2CR, and MB3CR--are 8-bit registers, each associated with one quadrant of the 1M memory space. Each register determines which memory chip will be mapped into its quadrant, how many wait states will be used for accessing that memory chip, and whether the memory chip will be write protected.

• The STACKSEG register is an 8-bit register that determines the location of the stack segment in the 1M memory.

• The DATASEG register is an 8-bit register that determines the location of the data segment in the 1M memory, normally the location of the data variable space.

• The SEGSIZE register is an 8-bit register holding two 4-bit registers. Together the registers determine the relative size of the base segment, data segment and stack segment in the 64K root space.

• The MMIDR register is an 8-bit register used to force /CS1 to be always enabled or not. Having /CS1 always enabled reduces power consumption.

• The XPC register is used to address extended memory. Normally the user's code frequently changes this register. The BIOS sets the initial value.

• The SP register is the system stack pointer. It is frequently changed by the user's code. The BIOS sets up an initial value.

All together there are 11 MMU and MIU registers that are set up by the BIOS. These registers determine all aspects of the hardware setup of the memory.

In addition, a number of origin declarations are made in the BIOS to tell the Dynamic C compiler where to place different types of code and data. The compiler maintains a number of assembly counters that it uses to place or allocate root code, extended code, data constants, data variables, and extended data variables. Each of these counters has a starting location and a block size.

6.2 BIOS Flowchart

The following flowchart summarizes the functionality of the BIOS:

Figure 6-1. BIOS Flowchart

6.3 Internally Defined Macros

Some macros used in the BIOS are defined internally by Dynamic C before the BIOS is compiled. They are defined using tests done in the bootstrap loading, or by reading variables set in the GUI. These are:

_FLASH_, _RAM_ - Used for conditional compilation of the BIOS to distinguish between compiling to RAM and compiling to flash. These are set in the Options | Compiler dialog box.

_RAM_SIZE_, _FLASH_SIZE_ - Used to set the MMU registers and code and data sizes available to the compiler. The values given by these macros represent the number of 0x1000 blocks of memory available.

_BOARD_TYPE_ - This is read from the System ID block or defaulted to 0x100 (the BL1810 JackRabbit board) if no System ID block is present. This can be used for conditional compilation based on board type.

6.4 Modifying the BIOS

The BIOS can be modified to be more specific concerning the user's configuration. This can be done one step at a time, making it easy to detect any problems. The source code for the Universal BIOS is in BIOS\RABBITBIOS.C. Dynamic C uses this source code for the BIOS by default, but the user can specify another BIOS for Dynamic C to use in the Options | Compiler dialog box.

There are several macros at the top of RABBITBIOS.C that users may want to modify for boards they design or for special situations involving off-the-shelf Rabbit-based boards. Not all of the macros at the top of the BIOS are described here.

USE115KBAUD

The default value of 1 specifies that Dynamic C will communicate at 115,200 baud with the target. If this macro is set to zero, Dynamic C will communicate at 57,600 baud. The lower baud rate might be needed on some PCs that can not handle 115,200 baud. If USE115KBAUD is changed to zero, the baud rate should be changed to 57,600 in the Dynamic C Options | Communications dialog box. Starting with Dynamic C 7.05, USE115KBAUD is not available to change the baud rate, simply choose the baud rate in Options | Communications.

CLOCK_DOUBLED

The default value of 1 causes the clock speed to be doubled if the crystal speed is less than or equal to 12.9 MHz. Setting this to zero means the clock speed will not be doubled.

ENABLE_CLONING

The default value of 0 disables cloning. Setting this to 1 enables cloning and slightly increases the code size of the BIOS. If cloning is used, PB1 should be pulled up with 50K or so pull up resistor. Various cloning options are available when ENABLE_CLONING is set to one. For more information on cloning, please see Chapter 8, "BIOS Support for Program Cloning," in this manual and/or Technical Note 207, Rabbit 2000 Cloning Board, which is available at rabbitsemiconductor.com.

DATAORG

Beginning logical address for the data segment. The default is 0x6000. This should only be changed to multiples of 0x1000. Increasing it increases the root code space available, and decreases root data space; decreasing it has the opposite effect. It can be changed to as low as 0x3000 or as high as 0xB000.

RAM_SIZE

This macro sets the amount of RAM available. The default value is the internally defined _RAM_SIZE_ The units are the number of 4k pages of RAM. In special situations, such as splitting RAM between two coresident programs, this may be modified to a smaller value than the actual available RAM.

FLASH_SIZE

This macro sets the amount of flash available. The default value is the internally defined _FLASH_SIZE_ The units are the number of 4k pages of flash. In special situations, such as splitting flash between two coresident programs, this may be modified to a smaller value than the actual available flash.

CS1_ALWAYS_ON

Keeping /CS1 active is useful if your system is pushing the limits of RAM access time. It will increase power consumption a little. Set to 0 to disable, 1 to enable

WATCHCODESIZE

These define the number of bytes available to the debugger for compiling watch expression. The default values are 0x200/0x060. Decreasing these increases the amount of RAM available for root data.

NUM_RAM_WAITST, NUM_FLASH_WAITST

These define the number of wait states to be used for RAM and flash. The default value for both is 0. The only valid values are 4, 2, 1 and 0.

MB0CR_INVRT_A18, MB1CR_INVRT_A18, MB2CR_INVRT_A18, MB3CR_INVRT_A18
MB0CR_INVRT_A19, MB1CR_INVRT_A19, MB2CR_INVRT_A19, MB3CR_INVRT_A19

These determine whether the MIU registers for each quadrant are set up to invert address lines A18 and A19 after the logical to physical address conversion. This allows each 256K quadrant of physical memory access up to four 256K pages on the actual memory device. These would be used for special compilations of programs to be coresident on flashes between 512k and 1M in size. See Application Note 202, Rabbit Memory Management In a Nutshell, and Application Note 210, Running Two Application on a TCP/IP Development Board for more details.

See the top of the BIOS source code (\BIOS\RabbitBIOS.c) for more options.

6.5 Origin Statements to the Compiler

The Dynamic C compiler uses the information provided by origin statements to decide where to place code and data in both logical and physical memory. The origin statements are normally defined in the BIOS; however, they may also be useful in an application program for certain tasks such as compiling a pilot BIOS or cold loader, or special situations where a user wants two application coresident within a single 256K quadrant of flash.

6.5.1 Origin Statement Syntax

Prior to Dynamic C 7.05, origin statement syntax is:

#<origin type> <origin name> <segment value> <logical address> <size> apply

All arguments are required.

Starting with Dynamic C 7.05, origin statement syntax (in BNF) is:

origin-directive : #origin-type identifier origin-designator

origin-designator : action-expression | origin-declaration

origin-declaration : physical-address size [follow-expression][action-expression] [debug-expression]

origin-type: rcodorg | xcodorg | wcodorg | rvarorg

follow-expression : follows identifier [splitbin]

action-expression : resume | apply

debug-expression : debug | nodebug | all

size : constant-expression

physical-address : constant-expression constant-expression

The non-terminals, identifier and constant-expressions, are defined in the ANSI C specification.

6.5.2 Origin Statement Semantics

An origin statement associates a code pointer and a memory region with a particular type of code. The type of code is specified by #origin-type.

All code sections (rcodorg, xcodorg code and wcodorg) grow up. All non-constant data sections (rvarorg) grow down. Root constants are generated to the rcodorg region. xdata and xstring are generated to the current xcodorg region.

All origin statements must have a unique ANSI C identifier. The scope of this identifier is only with other origin statements or declarations. In the pre 7.05 syntax this is the <origin name>.

Each memory region is defined by calculating a physical address from an 8-bit base address (first constant-expression of physical-address) and a 16-bit logical address (second constant-expression of physical-address). The size of the memory region is determined by 20-bit size. Overflow of these three values is truncated. In the pre 7.05 syntax these three values are <segment value>, <logical address> and <size>.

The keywords apply and resume are action-expressions. They tell the compiler to generate code or data in the memory region specified by identifier. An apply action resets the code or data pointer for the specified region to the starting physical address of the region and makes the region active. A resume action does not reset the code or data pointer, but does make the memory region active.

A region remains active (i.e., the compiler will continue to generate code or data to it) until another region of the same origin-type is activated with an apply or resume action or until the memory region is full.

The option follow-expression is best described with an example. First, let us declare yourcode in an origin statement containing an origin-declaration. A follow-expression can only name a region that has already been declared in an origin-declaration.

#rcodorg yourcode 0x0 0x5000 0x500

then the origin statement:

#rcodorg mycode 0x0 0x5500 0x500 follows yourcode

tells the compiler to activate mycode when yourcode is full. This action does an implicit resume on the memory region identified by yourcode. In this example, the implicit resume also generates a jump to mycode when yourcode is full. For data regions, the data that would overflow the region is moved to the region that follows. Combined data and code regions (like #rcodorg) use both methods, which one is used depends on whether code or data caused the region to overflow. In our example, if data caused yourcode to overflow, the data would be written to the memory region identified by mycode.

Furthermore, a follow-expression may specify that when the code or data resumes at the next region it should generate a separate bin file. This option is designed to support burning multiple flash or EPROM devices. The binary files generated share the same base name as the original file, but appended with a number which is followed by the .bin extension. For example, if hello.c, a large program that spans both flash chips, is compiled to file with the splitbin option on, hello1.bin and hello2.bin will be generated. Obviously, this option is only meaningful when compiling to a file.

The optional debug-expression is only valid with the xcodorg origin-type. It tells the compiler to generate only debug or nodebug code in that physical memory region. If debug-expression is not specified, the declaration is treated as an all region. An all region can have both debug and nodebug code. Activating an all region (by using apply or resume) will cause both debug and nodebug regions to become inactive. If an all region is active, both debug and nodebug regions must be made active to entirely deactivate the all region. In other words, if an all region is active and a debug region is activated, any nodebug code will still be generated to the all region until a nodebug region is made active.

With regard to follow-expressions, a debug region may not follow a nodebug region or vice versa. An all region may follow either a debug or a nodebug region. Only an all region may follow another all region. This allows debug and nodebug regions to spill into a common all region.

6.5.3 Origin Statement Examples

Figure 6-2 shows how the origin statements define the mapping between the logical and physical address spaces.

#define DATASEGVAL  0x91
#rvarorg rootdata   (DATASEGVAL) 0xc5ff 0x6600  apply      // grows down
#rcodorg rootcode   0x00         0x0000 0x6000  apply
#wcodorg watcode    (DATASEGVAL) 0xc600 0x0400  apply 
#xcodorg xmemcode   0xf8         0xe000 0x1a000 apply


// data declarations start here

Dynamic C defines macros that include information about compiling to RAM or flash and identifying memory device types, memory sizes, and board type. The origin setup shown above differs from that included in the standard BIOS included with Dynamic C as the standard BIOS uses additional macros values for dealing with a wider range of boards and memory device types.

Figure 6-2. Logical to physical mapping

6.5.4 Origin Directives in Program Code

To place programs in different places in root memory or to compile a boot strapping program, such as a pilot BIOS or cold loader, origin statements may be used in the user's program code.

For example, the first line of a pilot BIOS program, pilot.c, would be

#rcodorg rootcode 0x0 0x0 0x6000 apply

A program with such an origin directive could only be compiled to a .bin file, because compiling it to the target would overwrite the running BIOS.