2 bios assumptions, 2 virtual driver, 1 periodic interrupt – Jameco Electronics Rabbit 3000 User Manual

Page 247: 2 watchdog timer support, 1 periodic interrupt 17.2.2 watchdog timer support

Advertising
background image

238

Rabbit 3000 Microprocessor

17.1.2 BIOS Assumptions

The BIOS makes certain assumptions concerning the physical configuration of the proces-
sor. 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 3000 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 3000 Designer’s Handbook has a chapter on the Rabbit BIOS with more
details.

17.2 Virtual Driver

The Virtual Driver is compiled with the user’s application. It includes support for the fol-
lowing 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.

17.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 Z-World since the cost of connecting a crys-
tal is very small. The periodic interrupt keeps the interrupts turned off (that is, the proces-
sor 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 3000 microprocessor requires the 32 kHz oscillator in order to boot via
Dynamic C, unless a custom loader and BIOS are used.

17.2.2 Watchdog Timer Support

A microprocessor system can crash for a variety of reasons. A software bug or an electri-
cal 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 cor-
rupted. 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 pro-

Advertising
This manual is related to the following products: