Remote program monitor method and system using a system-under-test microcontroller for self-debug

Description Submit all comments and votes

BACKGROUND OF THE INVENTION

1. Technical Field

The present invention relates in general to techniques for correcting or "debugging" computer software code and, in particular, to a source-level run-time software code debugging instrument using a built-in software debugger that is transparent to and co-resident with a target system code.

2. Description of the Related Art

A program monitor is intrusive software code located in target memory to debug computer programs. The program monitor operates in conjunction with and monitors the operation of a main computer program that controls the functions of a microcontroller-based target circuit. The program monitor code is intrusive in that it is linked to the main program code, both of which are either downloaded into memory sites provided in the target circuit or stored in a read only memory (ROM) used by the programmer. The use of a monitor program requires that a universal asynchronous receiver-transmitter or other communication hardware be provided in the target circuit so that the monitor can communicate apart from the main program to the programmer.

The use of program monitors is advantageous because they are relatively inexpensive and find the majority of errors or "bugs" located in the main program. One drawback of program monitors is that they require the use of resources in the target circuit and typically are ineffective in detecting more difficult problems present in the associated program code.

The in-circuit emulator has become a standard tool for debugging microcontrollers and microprocessors. A variety of emulators are available often consisting of an adapter board which plugs directly into an IBM PC/XT/AT bus with cable attachment to a pod containing a "bond-out" microcontroller. The "bond-out" microcontroller in the pod plugs directly into the target system in lieu of the target system's microcontroller. A PC debugger software application program is then invoked to display and manipulate the target system's registers, to start and stop traces, and to set and reset breakpoints at specific program addresses or at specific reads or writes to data addresses.

Besides the burden of considerable expense of the emulator adapter board and pod unit, valuable slot space within the PC is used. To get around PC slot usage, emulator manufacturers offer a stand-alone emulator called an Expansion Box, allowing the emulator to operate outside the PC. The Expansion Box has its own power supply and is either serial, parallel or modem attached to the PC. Examples of emulator manufacturers include Nohau Corporation (EMUL51-PC emulator), and Intel Corporation (ICE-51 emulator).

One type of debugger function, single stepping, is described by Intel's Microcontroller User Manual, 1982, page 6-28, section 6.8.3, "How to Single-Step the 8051". This article specifies that one of the external interrupts be level activated and held normally low. It further describes how an external interrupt routine can be made to execute following each instruction of the target system by toggling the external interrupt input pin high and low with a push button switch. The article does not however, describe a software debug tool. Instead, it describes a hardware technique of examining the 8031 port 0 and port 2 address and data lines in conjunction with single stepping the code with the push button.

As will be appreciated, one major drawback of emulation in the prior art is that emulators are relatively expensive, thereby making them inaccessible to a significant percentage of the growing number of software engineers participating in microcontroller-based circuit design tasks. Besides the considerable expense of emulator adaptor boards and pod units, valuable slot space within in the PC is used to accommodate such debugging techniques. Further, prior art techniques involve complicated hardware manipulations and analyzation to perform the debugging procedure. What is needed is a debugging method and system that performs the emulator debugging functions on an off-the-shelf microcontroller in place in the system under test without the need for in-circuit emulator technology, additional microcontroller on-board circuitry, or a supporting microcontroller designed into the system under test.

SUMMARY OF THE INVENTION

According to the present invention, a remote program monitor method and system using a system-under-test microcontroller for self-debug comprises a system-under-test (SUT) that includes a read-only memory (ROM) and a microcontroller for executing a program under test. The microcontroller has an interrupt input, wherein one or more enable debugger signals received at the interrupt input causes the microcontroller to execute a debugger program contained in the ROM. The SUT is connected with a host computer over a standard serial connection for bidirectional debug information transmission. When the SUT receives one or more debugger signals as an interrupt input, the signal causes the microcontroller to execute a debugger program contained in the ROM. The above as well as additional objects, features, and advantages of the present invention will become apparent in the following detailed written description.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features believed characteristic of the invention are set forth in the appended claims. However, the invention, as well as a preferred mode of use, and further objects and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:

FIG. 1 is a high level block diagram of the software components of the invention.

FIG. 2 is a Data Structure diagram depicting the Debug Parameter Table.

FIG. 3 is a block diagram depicting how the Interrupt Vector Jump Table is initialized to either branch to or point to the other software modules or data modules respectively, in memory.

FIG. 4 is a block diagram of the memory mapping of the invention.

FIG. 5 is a hardware block diagram of the INT0 pin being shared between the Debugger and the Target system hardware, and another block diagram of the INT0 pin being dedicated to the Debugger.

FIG. 6 is a block diagram depicting two methods which can be incorporated into the target system to determine whether the source of the INT0 interrupt was only from the Target system, only from the present invention Debugger, or from both the Target system hardware and the present invention Debugger.

FIG. 7 is a block diagram depicting a method of hooking to the INT0 Interrupt Vector Jump Table entry named "Hook".

FIG. 8 is a code flow diagram depicting a debugpoint being executed on the Target system code.

FIG. 9 is a code flow diagram depicting the target system code being interrupted by the INT0 Debugger, then subsequently interrupted by the serial link interrupt.

FIG. 10 is a code flow diagram depicting a serial interrupt occurring during the process of executing a debugpoint in the target system's INT0 handler, then subsequently executing a debugpoint in the target system's code when the target system's INT0 handler completes.

FIG. 11 is a code flow diagram depicting a serial interrupt occurring during the process of executing the target system's INT0 handler. An INT0 reentry follows serial interrupt completion. Subsequently, a debugpoint is executed in the target system's code, when the target system's INT0 handler completes.

FIG. 12 is a flowchart of the INT0 Handler.

FIG. 13 is a flowchart of the Power On Reset Routine.

FIG. 14 is a flowchart of the Debugger Initialization Routine. This routine resets all boolean flags and variables used by the INT0 Handler.

FIG. 15 is a flowchart of the INT0 Reentrant Routine.

FIG. 16 is a flowchart of the INT0 Command Processor Routine.

FIG. 17 is a flowchart of the INT0 Trace Routine.

FIG. 18 is a flowchart of the Trace Table Initialization Routine.

FIG. 19 is a flowchart of the INT0 Debugger Routine.

FIG. 20 is a flowchart of the Serial Link Interrupt Entry Routine.

FIG. 21 is a flowchart of the Serial Link Decoder Routine.

FIG. 22 is a flowchart of the Serial Link Packet Parser Routine.

FIG. 23 is a flowchart of the Serial Link Transmitter Setup Routine.

FIG. 24 is a flowchart of the Serial Link State Handler Routine.

FIG. 25 is a flowchart of the Serial Link State 1 Routine.

FIG. 26 is a flowchart of the Serial Link State 2 Routine.

FIG. 27 is a flowchart of the Serial Link State 3 Routine.

FIG. 28 is a flowchart of the INT0 Exit Routine.

FIG. 29 is a Data Structure diagram depicting the Trace Table.

FIG. 30 is a Data Structure diagram depicting a generic serial link Data packet, hereafter referred to as a D-packet.

FIG. 31 is a memory mapping of the present invention RAM Work Area.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

The 8031 microcontroller, a term generically used to include its variations: the 8032, 8051, 8052, 8751, and 8752, is widely used in all types of hardware mechanism control applications. The 8031 microcontroller software is often debugged using a debug tool known as an in-circuit emulator. The Debug Tool of a preferred embodiment of the present invention is a 8031 debug tool with emulator types of functions which needs only a minicomputer, such as a PC, running a user-interactive PC Host Debugger Application program and a serial cable attaching the standard communication port of a PC to the 8031 based target system. Prior art emulators are extravagant and expensive hardware tools for most prototype debug applications and are often very awkward or impractical to insert into a product's microcontroller socket in a customer environment to debug a field problem. The present invention contains built-in 8031 software used to debug 8031 based systems without the need for an in-circuit emulator and its associated hardware. A developer can actually use the target system to debug itself with the present invention target system bootstrap ROM code and Host Debugger Application program. The Host Debugger Application program can multitask with any Host Target System Application program that interfaces to the target system's code through the serial link connection. The present invention software is transparent to and co-resident with 8031 target system code. The present invention requires no additional minicomputer hardware adapter to operate and runs with all manufacturers' 8031 microcontrollers.

Therefore, an object of the present invention is to provide a method and system of debugging 8031 based systems using a PC Host with a standard serial port and without installing a PC emulator adapter and without purchasing an Expansion Box.

Another object of the present invention is to provide a method and system of downloading the 8031 target system code from the PC Host serial port to the target system's external program memory using the 8031's onboard UART.

A further object of the present invention is to provide a method and system of debugging 8031 based systems in the customer environment without attaching an emulator pod to the product's microcontroller socket in lieu of the product's microcontroller.

Another object of the present invention is to provide a method and system of debugging 8031 based systems using a PC Host with a standard serial port running a Debug Application Program and using the target system microcontroller itself as part of the debugging means, without the use of an emulator pod with a bond-out chip.

A further object of the present invention is to provide a method and system having debugger microcode in ROM that shares the 8031 Serial and INT0 interrupts with the target system code.

Another object of the present invention is to provide a method and system having debugger microcode in ROM that is co-resident and transparent to the target system code.

A further object of the present invention is to provide a method and system having debugger microcode in ROM that provides a unique serial communication link protocol to the PC host that supports 2 communication channels simultaneously. A field called a "debug switch" within a D-packet indicates whether a given D-packet is owned by the debugger or the target system code.

Another object of the present invention is to provide a method and system having debugger microcode in ROM that provides a serial communication application program interface, or API, that supports functions: Put Debug D-packet, Get Debug D-packet, Query Transmitter Busy, and Query Debug D-packet Available, for the debugger code.

A further object of the present invention is to provide a method and system having debugger microcode in ROM that provides a serial communication application program interface, or API, that supports functions: Put Target System D-packet, Get Target System D-packet, Query Transmitter Busy, and Query Target System D-packet Available, for the target system code.

Another object of the present invention is to provide a method and system having debugger microcode in ROM that provides a serial communication application program interface, or API, that supports functions: Query Write Debug D-packet Allowed, Write Debug D-packet, Query Read D-packet Available, Read D-packet, Query Write Target System D-packet Allowed, and Write Target System D-packet, for the serial link interrupt handler code.

A further object of the present invention is to provide a method and system having debugger microcode in ROM that provides an Interrupt Vector Jump Table in external RAM that can be used to "chain" to, "hook" to, or replace existing interrupt vectors.

Another object of the present invention is to provide a method and system having debugger microcode in ROM that provides a jump instruction in the Interrupt Vector Jump Table for use by the target system code to hook into the existing INT0 interrupt debugger routine.

A further object of the present invention is to provide a method and system having debugger microcode in ROM that provides an INT0 interrupt service precursive routine that is non-interruptable and can be neither "chained" to nor replaced. This INT0 precursive routine is always the first routine to execute at the time of an INT0 interrupt and is responsible for calling the INT0 hook vector provided in the Interrupt Vector Jump Table.

Another object of the present invention is to provide a method and system having debugger microcode in ROM that provides an INT0 interrupt service precursive routine which is re-entrant and that:

(1) gets control immediately following the INT0 interrupt.

(2) can simulate a 3 level interrupt priority scheme on a 2 level interrupt priority microcontroller.

(3) can branch to the present invention debugger routine in order to debug a target system's INT0 routine already in progress.

(4) can Query for, Put, or Get the present invention Debugger D-packets via the Communications API.

A further object of the present invention is to provide a method and system of the most commonly used In-circuit emulator types of operations including:

a. Tracing

1) Setting tracepoints in the target system 8031 software

2) Selectively enabling and disabling these tracepoints from the PC Host Debug Application program.

3) When a tracepoint is encountered within the target system code that is enabled, a trace record is constructed and appended to the trace table. When a tracepoint is encountered that is disabled, and single stepping is also disabled, trace activity stops.

4) A trace record which consists of:

a) Length field

b) Forward chain pointer

c) Backward chain pointer

d) Registers at the time of interrupt

e) Program Counter at the time of interrupt

f) Next program instruction to be executed

g) Internal RAM

h) A number of external RAM contiguous areas

b. Breaking

1) Setting breakpoints in the target system 8031 software.

2) Selectively enabling and disabling breakpoints from the PC Host Debug Application.

3) When an enabled breakpoint is encountered, a trace record is built and appended to the existing trace table and the entire trace table is transmitted to the PC Host Debug Application. The PC Host displays this information to the developer. The breakpoint routine awaits a message from the PC Host through the communication API for an indication to resume execution of the target system code.

4) When a disabled breakpoint is encountered, and single stepping is also disabled, no status to the PC host is transmitted.

c. Single Stepping

1) Setting steppoints in the target system 8031 software

2) Selectively enabling and disabling steppoints from the PC Host Debug Application program.

3) When an enabled steppoint is encountered, a trace record is built and appended to the existing trace table. If break is not also enabled, the trace record is subsequently transferred to the PC Host using the communication API. If break is enabled when an enabled steppoint is encountered, the entire trace table is transmitted to the PC Host. The PC Host displays this information to the developer. The steppoint routine waits for a message from the PC Host through the communication API for an indication to resume execution of the target system code. The steppoint differs from a breakpoint in that it affects each subsequent instruction executed in the target system code until a disabled steppoint is encountered.

4) When a disabled steppoint is encountered at a debugpoint which also does not have an enabled breakpoint, no status to the PC Host is transmitted.

d. A method of activating the present invention debug features: tracing, breaking, and single stepping, within the target system by using one of the target system's external interrupts running in level-activated mode. At the designer's discretion, this external interrupt can be used exclusively for the present invention debug interrupt routine or shared between the target system hardware and the present invention using minimal hardware logic in the target system at the external interrupt pin. In the preferred embodiment, INT0 is used. However, INT1 may also be used.

e. A method of selectively enabling and disabling the present invention debug features: tracing, breaking, and single stepping, by downloading a Debug Parameter Table to the target system. An "escape" or interrupt from the target system code to the INT0 interrupt handler debug routine is referred to as a "debugpoint". The Debug Parameter Table contains a record for each specified debugpoint in the target system. Each record consists of:

1) A program memory address which is compared to the target system program counter at the time the debugpoint occurs. If a match occurs, the debugpoint takes action based upon the contents of the remainder of this record.

2) A boolean flag for tracing

"1"=enabled

"0"=disabled

3) A boolean flag for breaking

"1"=enabled

"0"=disabled

4) A boolean flag for single stepping

"1"=enabled

"0"=disabled

5) A boolean flag for internal RAM size tracing

"1"=256 bytes

"0"=128 bytes

6) An integer, "N", representing the number of pairs of external RAM beginning address and ending address pointers, delimiting the areas of contiguous external RAM that are to be traced in a trace record.

7) "N" pairs of external RAM addresses:

An external RAM address specifying where to begin tracing external RAM.

An external RAM address specifying where to stop tracing external RAM.

Another object of the present invention is to provide a method and system to stop target system code execution on the fly by a Forced Break command from the PC Host Debugger Application program.

A further object of the present invention is to provide a method and system to enable the debugger on the fly by an Enable Debugger Command from the PC Host Debugger Application program.

Another object of the present invention is to provide a method and system to disable the debugger on the fly by a Disable Debugger Command from the PC Host Debugger Application program. If the target system has hooked to INT0, the Debugger Routine portion of the INT0 Handler will be bypassed. The target system INT0 Hook routine will still be allowed to operate.

A further object of the present invention is to provide a method and system to modify 8031 register contents on the fly, or while the debugger is at a Forced Break, Breakpoint, or Steppoint.

Another object of the present invention is to provide a method and system of tracing the target system opcode and operands of each instruction executed. Upon entry to the debug interrupt handler, the top of the stack contains the address the next instruction of the routine that was interrupted. The byte pointed to by this address is the opcode. The opcode determines how many bytes in length the instruction is. The opcodes and operands are then copied into a trace table record.

A further object of the present invention is to provide a method and system of uploading the Debugger generated trace table record(s) at an enabled breakpoint, steppoint, or forced break, to the PC Host Debugger Application program for viewing on an application's screen.

Another object of the present invention provides multiple target system software modules built into a bootstrap ROM 30 module allowing the microcontroller to perform the self-debug of the present invention. The target system software modules built into the bootstrap ROM module include:

a. Target system download routine

b. Initialization of Interrupt Vector Jump Table into external RAM

c. INT0 Debug routine which supports functions typically found in most emulators:

Enable Debugger

Disable Debugger

Tracepoints

Breakpoints

Steppoints

Patch Code (code download)

Forced Breakpoints

Register Modification

Restart Target System

Reboot Target System

d. Serial Link Level Interface and Communication API for target system and debugger.

With reference now to the figures and in particular with reference to FIG. 1, Bootstrap ROM 30 interfaces between the PC Host 10 and the Target system code 40 as shown. Initially, the target system 8031 source code is assembled on the PC. The resulting executable object code is downloaded by the PC Host 10 through the serial connection to the target system Bootstrap ROM Downloader routine 33. The Downloader routine copies the object code to target system RAM. After the download is complete, the Downloader routine branches to the target system code 40. The target system code 40 can then chain onto any entry in the Interrupt Vector Jump Table 31. The target system code 40 may also replace any Interrupt Vector Jump Table entry except the INT0 Hook entry. The Serial Interrupt Vector is unavailable for either chaining or replacement. The target system 20 can communicate to a PC Host 10 application other than the PC Host Debugger application using the present invention serial link protocol with the "debugger switch" field in the D-packet set to a value indicating "target system".

The first step in enabling the INT0 Debug routine involves the PC Host Debugger application sending an "Enable Debugger" D-packet. Receipt of this D-packet will cause the -Enable Debugger hardware signal to be activated. With the INT0 input pin held low by the -Enable Debugger signal and INT0 programmed to be level-activated, INT0 interrupts can be enabled or disabled by the target system code 40 unmasking or masking INT0 respectively with an "enable INT0 interrupt" instruction (i.e. SETB EX0) or "disable INT0 interrupt" instruction (i.e. CLR EX0) respectively.

Having the Enable Debugger signal activated and INT0 unmasked will cause an escape from the target system code 40 to the INT0 interrupt handler. This escape is referred to as a "debugpoint". Included in the assembly of the target system source code is the Debug Parameter Table and "enable INT0 interrupt" instructions placed at strategic locations where debugpoints are desired. Having the -Enable Debugger signal deactivated and INT0 unmasked disables debugpoints but still allows target system INT0 interrupts to occur as long as the INT0 pin of the 8031 is shared between the target system logic and the -Enable Debugger signal. The Debug Parameter Table, shown in FIG. 2 is a look-up table used by the Debugger in the Bootstrap ROM 30 to determine what actions to take at a debugpoint. Actions include tracing enable/disable, breaking enable/disable, and single stepping enable/disable, or any combination of these, yielding a variety of possible actions. Debug data in the form of trace table records is uploaded to the PC Host Debugger Application during single-stepping, breakpoint, or forced break.

A D-packet can be sent from the PC Host Debugger Application to (1) enable the present invention Debugger, (2) disable the present invention Debugger, (3) modify register(s) in the target system 20, (4) load or patch the target system code 40, (5) update the Debug Parameter Table, (6) force break the target system code 40 execution, (7) continue execution of the target system code 40, (8) restart the target system code 40 beginning at the entry point used by the Bootstrap ROM 30 when initial target system downloading is complete, and (9) Reboot the target system at address 0000h just as if a hardware power on reset occurred. D-packets can be sent from the PC Host Debugger Application to the present invention Debugger to perform sequences of operations such as (1) force break the target system 20, (2) update Debug Parameter Table, and (3) continue execution of the target system code 40. The present invention Debugger can respond to PC Host D-packets with status such as (1) acknowledge, (2) negative acknowledge, (3) trace table record(s) or (4) Trace Error. Status is sent to the PC Host 10 as either Synchronous or Asynchronous form. The difference being that synchronous status is sent to the PC Host 10 as a D-packet response to a PC Host D-packet command. Asynchronous status is a D-packet that is sent to the PC Host 10 which is not a response to a PC Host D-packet command. An example of asynchronous status is a D-packet that is sent to the PC Host 10 during single stepping or when a breakpoint occurs. An example of synchronous status is an "Acknowledge" D-packet that is sent to the PC Host 10 in response to an "Update Debug Parameter Table" D-packet command.

The PC Host Debugger Application presents all information from the target system debugger to the developer on a user-friendly screen. The PC Host Debugger Application can disable the present invention debugger by sending a "Disable Debugger" D-packet command. Receipt of this D-packet will cause the -Enable Debugger logic signal to become deactivated. The INT0 mask will remain unaffected because the target system code 40 may have its own INT0 service routine hook which must be functional at the time the Disable Debugger D-packet command is received.

In order for the present invention package to work properly, the following target system 20 hardware requirements are necessary as shown in FIG. 4.

1. A memory requirement such that the external program memory the present invention Bootstrap ROM 30 be located at address 0 and all other target system external program and data memory resides in RAM. This is necessary to facilitate downloading of target system code 40 with breakpoints. The external program memory and external data memory are combined by applying the -RD and -PSEN signals to the inputs of an AND gate and using the output of the AND gate as the read strobe to the external Program/Data memory. External Program/Data RAM memory resides from 2K to 64K. The ROM bootstrap resides from 0 to 2K.

2. Sharing INT0 between the debugger and the target system hardware control requires a 2-input AND gate with the output of the AND driving the INT0 input. The inputs to the AND gate are a -Enable Debugger signal and a target system -Prototype Interrupt signal. The diagram in FIG. 5 shows how INT0 can be shared between the debugger and the target system 20, and how INT0 can be used exclusively for the debugger. INT0 must be set to level-activated for the debugger to operate.

a. INT0 interrupts will only occur when the target system code 40 executes a "SETB EX0" instruction. The "CLR EX0" instruction will mask off (i.e. disable) the INT0 interrupt handler.

b. -Prototype Interrupt and -Enable Debugger are signals that can be connected to spare 8031 port lines or to other I/O expansion logic in the target system 20 as shown in FIG. 6. The -Prototype Interrupt signal is read by the target system's INT0 service routine that was hooked to the INT0 Hook vector in the Interrupt Vector Jump Table. This target system INT0 service routine determines whether the source of the interrupt is from the target system 20 and if so, services the interrupt. After servicing the interrupt, or if the source of the interrupt was not the target system 20, control is returned to the present invention INT0 Hook routine 34 which returns to the present invention INT0 Handler 32 as shown in FIG. 1 for further debug processing.

c. When the -Enable Debugger signal is set low, the Debugger is enabled and a debugpoint will occur after every target system 20 instruction as long as INT0 interrupts are unmasked. Setting -Enable Debugger high disables the debugger.

Software

The present invention package contains a Power On Reset (POR) routine, a Downloader routine, an Interrupt Vector Jump Table, an INT0 Handler which contains the debugger, a default INT0 Hook routine, a serial interrupt handler which supports a 2 channel communication protocol, a communications Application Program Interface (API), default timer 0, timer 1, timer 2, and INT1 interrupt service routines, default Enable Debugger routine, and default Disable Debugger routine.

The Power On Reset Routine executes following a POR vector jump at power on time. Its purpose is to perform rudimentary diagnostic functions on the 8031 microcontroller, initialize the Interrupt Vector Jump Table with default jump vectors, initialize the on-board UART, enable serial interrupts, and branch to the Downloader Routine.

The Downloader Routine is responsible for querying the communication API for D-packet available, reading the D-packets received from the host, and testing the D-packet's Debug Switch field for "Target System Code Download". If the Debug Switch is not equal to "Target System Code Download", the D-packet is discarded because the target system code 40 must be totally downloaded before other types of PC Host D-packets are accepted. If the Debug Switch is equal to "Target System Code Download", the target system object code is loaded into external RAM by the Downloader code at a location following the present invention Work Area as shown in FIG. 3. A field within the "Target System Code Download" D-packet contains an address indicating where the D-packet's object code record is to be placed in RAM. Downloading is complete when a "Target System Code Download" D-packet is received from the Host in which the executable object code field is null. After downloading is complete, the Downloader branches to the target system code 40 in external RAM at the address following the present invention Work Area as shown in the memory map layout of FIG. 3.

8031 microcontrollers have hardcoded interrupt vectors starting at address 0. Specifically, these are:

Power On Reset, vector address 0000

d External Interrupt 0 (INT0), vector address 0003h

Timer 0 Overflow Interrupt, vector address 000Bh

External Interrupt 1 (INT1), vector address 0013h

Timer 1 Overflow Interrupt, vector address 001Bh

Serial Receive and Transmit Interrupt, vector address 0023h

Timer 2 Overflow Interrupt, vector address 002Bh (8052, 8032, 8752 only)

Program memory is organized with a 2 kb present invention Bootstrap ROM 30 and 62 kb of RAM with the seven interrupt vectors at location zero assembled to point to an Interrupt Vector Jump Table as shown in FIG. 3. Referring to FIG. 3, these vectors, except for the Power On Reset vector, Serial Interrupt vector, and INT0 Interrupt vector, are coded to point to the Interrupt Vector Jump Table in RAM. The Power On Reset vector points to the present invention bootstrap ROM 30 POR routine. After power on, the bootstrap ROM 30 POR code will initialize the Interrupt Vector Jump Table so that all interrupts can be serviced by the default handlers contained in the ROM. The default interrupt handlers for Timer 0, Timer 1, Timer 2, and External Interrupt 1 (INT1), contain only one instruction which is the return from interrupt instruction, RETI. The purpose of the Interrupt Vector Jump Table is to provide a means for the target system code, once downloaded, to chain to, hook to, or replace these jump vectors so that the target system code can service the hardware interrupts. LJMP instructions are used in the Interrupt Vector Jump Table so that the address can be obtained from the operand of the LJMP, for the purpose of chaining or hooking to these vectors.

The term "hook" will differ from "chaining" in that "chaining" involves executing the new, or chained, routine followed by the old, or existing, routine specified in the operand field of the jump instruction located in the Interrupt Vector Jump Table, without having first been called from a precursive routine at the time of interrupt. "Hooking" involves first executing a precursive routine at the time of interrupt, then executing the new, or hooked, routine followed by the old, or existing, routine specified in the operand field of the jump instruction located in the Interrupt Vector Jump Table. In the preferred embodiment, only the INT0 interrupt vector jump instruction in