Error detection/correction and fault detection/recovery – Data processing system error or fault handling – Reliability and availability
Reexamination Certificate
1997-07-01
2001-06-19
Beausoliel, Jr., Robert W. (Department: 2785)
Error detection/correction and fault detection/recovery
Data processing system error or fault handling
Reliability and availability
Reexamination Certificate
active
06249881
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to electronic control and data processors and in particular, to debugging such processors as part of an embedded system while running a real time application. More particularly the present invention relates to an interrupt based debug method that allows critical interrupts to be transparently enabled and transparently serviced in real time while a debug interrupt service routine is running on the target system.
2. Description of the Related Art
An embedded system is typically a special purpose, preprogrammed processor that is built into another device, such as an automobile, a camera, a copy machine, or a disk drive. Software development for such embedded systems is distinct from software development for general-purpose platforms, such as personal computers and workstations. This is primarily because the software for embedded systems is typically very application specific and tied very closely to the underlying system hardware. In other words the application defines the hardware. In contrast, general purpose platforms, by definition, are designed to embrace a large variety of applications which are very loosely related to the underlying hardware platform, if at all. Thus, the architecture of an embedded processor requires special considerations for software development and debug.
Various approaches, with varying degrees of sophistication and effectiveness, in debugging computer systems, including embedded systems, have been developed. In fact, often times, multiple approaches must be employed to maximize the effectiveness of debugging.
One traditional approach employed by many computer systems is to provide diagnostic ports and corresponding read/write registers. An example of this approach is I/O Port 80H and its corresponding read/write register provided on a standard ISA system. Typically, external decode logic is coupled to the diagnostic ports for decoding the content of the registers and displaying diagnostic messages on a display device, for example, an array of LEDs. This approach is simple to implement. However, the obvious disadvantage is its limited functionality and poor usability.
Another traditional approach employed by many computer systems is to provide emulation support logic and a special emulation pin to the processor. The emulation support logic, when activated, floats all output to the processor. An example of this approach is found in the on-board circuit emulation pin of the “Intel386 TM SL” processor, manufactured by Intel Corporation of Santa Clara, Calif. Typically, an external emulation module with emulation logic is coupled to the special emulation pin to drive the output signals, thereby permitting testing of the overall computer system with the processor installed. This approach is more difficult to implement, but it provides more debugging functions then the previous approach. However, usability is still generally poor. In addition, this approach also has the inherent disadvantage that execution is not performed at the system's normal execution speed. Thus, certain problems, particularly hardware and software specific timing problems, might not be detectable.
Yet another traditional approach employed by many computer systems is to provide a software emulator for the computer system. The ICE-386 SL Emulator provided for the “Intel386 TM SL Superset” microprocessor system is an example of an emulator. This approach is more difficult to implement, but it provides more functions and better usability than the two previous approaches. The obvious disadvantage is the fact that execution is only emulated. Thus, many hardware problems may be undetectable and therefore, this approach is not useful for debugging embedded systems.
Thus, it is desirable to have an improved approach to debugging a computer system where the execution is not emulated and yet the debugging functions and their usability match or exceed those offered by the emulation approach. As will be described, these objects and desired results are among the objects and desired results achieved by the present invention.
Embedded software is usually developed on a host processor, such as a workstation. Once the program is complete, it is downloaded to the embedded processor from the host, executed, and debugged. A special purpose monitor function must exist on the embedded processor to enable this type of communication between the host and the embedded processor. The monitor must be able to receive the program from the host, store it in memory, execute it, and break the execution at a specified point to enable system debug. The monitor is typically part of the embedded processor and may be implemented in either software or in hardware. A software implementation actually runs on the embedded processor, similar to a special application, and a hardware implementation is included as part of the embedded processor itself. Software monitors are typically cheaper and more flexible to develop. They can also be later enhanced to support new debug features without having to change the silicon of the processor.
A software monitor communicates with the host via a special debug interrupt signal which initiates a debug interrupt service routine (ISR) or debug monitor routine. Typically, interrupts are immediately disabled upon starting any kind of interrupt service routine. This insures that the ISR can be started without being interrupted. This also allows the ISR to save the machine's context and then decide whether it wants to re-enable interrupts and support nested interrupts. Unlike regular ISRs however, prior art debug ISRs typically do not re-enable interrupts because during debug after a breakpoint, a programmer wants the processor to sit idle so he or she can examine the status of the machine without it changing.
For instance, if a breakpoint occurs, the embedded processor enters a debug ISR, the debug monitor takes over, interrupts are disabled, and the monitor awaits instructions from the host system. The embedded processor will only exit the debug ISR once the user, via the debugger running on the host processor, instructs the target system to continue with program execution. This can obviously take a long time relative to real time events that need to be serviced by the target system—anywhere from a few seconds to possibly hours. Such a period of ignoring critical interrupts for real time events could be devastating to a real time system that requires immediate attention to interrupts, such as hard disk drives. In a disk drive, if the servo loop is not maintained, the head may crash, causing irreversible damage. Less devastating but potentially problematic, in a modem, if arriving data interrupts are ignored, incoming data is lost.
In order to avoid this problem, what is needed is a way to service critical interrupts for real time events that should not be ignored even during debug. This will enable the development and debug of real time systems without putting the actual embedded system at risk. In addition, system operation may proceed throughout the debug session. Other examples of such systems are production control systems, speech and voice systems, communication systems, etc.
Prior art debug systems have failed to teach a method for transparently servicing critical interrupts. Typically, prior art systems disable interrupts during debug. Any prior art system that allow interrupt during debug require that the application programmer is aware of the need to service critical interrupts. Such prior art systems typically require the programmer to define special service routines just for handling interrupts that occur while the monitor is in control of the system.
Some prior art systems require the use of two separate tables for interrupt vectors: one for interrupts occurring while an application program is running and the second for interrupts occurring while a debugging program is running. Such a scheme requires a separate vector controller to map the interrupts to the appropriate vector table, dependi
Bar-Niv Amir
Porten Joshua
Beausoliel, Jr. Robert W.
Elisca Pierre Eddy
Limbach & Limbach L.L.P.
National Semiconductor Corporation
LandOfFree
Method for enabling and servicing critical interrupts while... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method for enabling and servicing critical interrupts while..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method for enabling and servicing critical interrupts while... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2460640