Rabbit 2000 Microprocessor User's Manual

16. Rabbit BIOS and Virtual Driver

When a program is compiled by Dynamic C for a Rabbit target, the Virtual Driver is automatically incorporated into the program. Virtual Driver is the name given to some initialization routines and a group of services performed by the periodic interrupt. The Rabbit BIOS, software that handles startup, shutdown and various basic features of the Rabbit, is compiled to the target along with the application program.

Rabbit Semiconductor provides the full source code for the BIOS and Virtual Driver so the user can modify them and examine details of the operation that are not apparent from the documentation.

More details on the BIOS and Virtual Driver software can be found in the Dynamic C User's Manual, the Rabbit 2000 Designer's Handbook and the source code in the Dynamic C libraries.

16.1 The BIOS

The BIOS provided with Dynamic C will work with all Rabbit board products.

The BIOS is compiled separately from the user's application. It occupies space at the bottom of the root code segment. When execution of the user's program starts at address zero on power-up or reset, it starts in the BIOS. When Dynamic C cold-boots the target and downloads the binary image of the BIOS, the BIOS symbol table is retained to make its entry points and global data available to the user application. Board specific drivers are compiled with the user's program after the BIOS is compiled.

16.1.1 BIOS Services

The BIOS includes support for the following services.

• System startup: including setup of memory, wait states and clock speed.

• Writing to flash. Writes to the primary code memory require turning off interrupts for up to 20 ms or so. To protect the System Identification Block (see the Rabbit 2000 Designer's Handbook for more information on the System ID Block), the flash driver will not write to that block. A routine that can actually write this block is not included in the BIOS to make it hard to accidently corrupt this block.

• Run-time exception handling and logging to handle fatal errors and watchdog time-outs (error logging not implemented in older versions).

• Debugging and PC-target communication

16.1.2 BIOS Assumptions

The BIOS makes certain assumptions concerning the physical configuration of the processor. Processors are expected to have RAM connected to /CS1, /WE1, and /OE1. Flash is expected to be connected to /CS0, /WE0, and /OE0. (See the Rabbit 2000 Designer's Handbook Memory Planning chapter if you want to design a board with RAM only.) The crystal frequency is expected to be n*1.8432 MHz.

The Rabbit 2000 Designer's Handbook has a chapter on the Rabbit BIOS with more details.

16.2 Virtual Driver

The Virtual Driver is compiled with the user's application. It includes support for the following services.

• Hitting the hardware watchdog timer.

• Decrementing software watchdog timers.

• Synchronizing the system timer variables with the real-time clock and keeping them updated.

• Driving uC/OS-II multi-tasking.

• Driving slice statement multi-tasking.

16.2.1 Periodic Interrupt

The periodic interrupt that drives the Virtual Driver occurs every 16 clocks or every 488 µs. If the 32.768 kHz oscillator is absent, it is possible to substitute a different periodic interrupt. This alternative is not supported by Rabbit Semiconductor since the cost of connecting a crystal is very small. The periodic interrupt keeps the interrupts turned off (that is, the processor priority is raised to 1 from zero) for about 75 clocks, so it contributes little to interrupt latency.

The periodic interrupt is turned on by default before main() is called. It can be disabled if needed. The Dynamic C Users's Manual chapter on the Virtual Driver provides more details on the periodic interrupt.

The Rabbit 2000 microprocessor requires the 32 kHz oscillator in order to boot via Dynamic C, unless a custom loader and BIOS are used.

16.2.2 Watchdog Timer Support

A microprocessor system can crash for a variety of reasons. A software bug or an electrical upset are common reasons. When the system crashes the program will typically settle into an endless loop because parameters that govern looping behavior have been corrupted. Typically, the stack becomes corrupted and returns are made to random addresses.

The usual corrective action taken in response to a crash is to reset the microprocessor and reboot the system. The crash can be detected either because an anomaly is detected by program consistency checking or because a part of the program that should be executing periodically is not executing and the watchdog times out.

The Virtual Driver's periodic interrupt hits the hardware watchdog timer with a 2 second time-out. If the periodic interrupt stops working, then the watchdog will time out after 2 seconds. The Virtual Driver provides a number of additional "virtual" watchdog timers for use in other parts of the code that must be entered periodically. The user program must hit each virtual watchdog periodically.

The best practice is to let the periodic interrupt hit the hardware watchdog exclusively, and use virtual watchdogs for other code that must be run periodically. If hits to the hardware watchdog are scattered through a program, then it may be possible for the code to enter an endless loop where the watchdog is hit, and therefore rendered useless for detecting the endless loop condition. If no virtual watchdogs are used, an undetected endless loop condition could still occur since the periodic interrupt can still hit the hardware watchdog.

If any of the virtual watchdogs times out, then hits are withheld from the hardware watchdog and it times out, resulting in a hardware reset. Virtual watchdogs may be allocated, deallocated, enabled and disabled. The advantage of the virtual watchdogs is that if any of them fail an error is detected.

The Dynamic C Users's Manual chapter on the Virtual Driver provides more details on virtual watchdogs.