Peripheral breakpoint signaler

Details Peripheral breakpoint signaler Peripheral breakpoint signaler

1999-06-01

2003-07-22

Beausoliel, Robert (Department: 2184)

Error detection/correction and fault detection/recovery

Data processing system error or fault handling

Reliability and availability

C714S044000

Reexamination Certificate

active

06598178

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates generally to enhancing development capabilities for software developers. More particularly, it relates to an enhanced breakpointing technique wherein a processor device is halted in response to a breakpoint reached in a peripheral device.
2. Background of Related Art
In general, a digital system may contain one or more processor devices that control the operation of the digital system. In order to provide functionality to the digital system, computer programmers develop application programs, including operating systems, for execution in the processor device.
As the source program code is developed, errors or “bugs” are found and removed from the source program code. The task of finding these errors is called debugging.
Typically, during the debugging process, an engineer will develop program code by monitoring the functionality of the processor device being debugged as it proceeds through individual lines of the source program code. This technique is typically called tracing. Trace functions allow an engineer the ability to observe intermediate results within the processor device being debugged as individual or group of lines of the program code are executed. For instance while tracing, a status of selected registers and/or memory locations may be viewed before and/or after each instruction of the program code, or after a predetermined group of instructions of program code (e.g., a particular routine) is executed by the processing device. By reflecting the status of these registers and/or memory, the trace function provides the engineer with very detailed information about the internal state of a processor device as well as the value of data input or output therefrom, from the perspective of the processor device at any particular time. With this information, many types of errors in the software and/or hardware relating to the processor device being debugged can be identified and subsequently corrected.
Tracing functions are typically accomplished in conventional processor devices by a debug support circuit which is connected to a system bus that connects the processor device to external memory and/or other peripheral devices. Addresses, instructions and data regarding the functions of the processor device being debugged can often by viewed from monitoring the system bus.
In advanced breakpointing techniques, the program can proceed until the particular breakpoint condition has been reached a certain number of times. Other techniques look for particular data patterns on a data bus instead of looking for a particular line of code (or address) in memory. In any event, a particular scenario is established within the processing device for defining a breakpoint.
Oftentimes, monitoring the execution of individual lines of program code, e.g., using a trace function is intense and may require the review of many parameters at any particular line of program code. The engineer or programmer can typically step line-by-line through the program code, but as development proceeds this may become a time consuming and expensive task to reach an advanced point of interest in the program code. Therefore, a stopping point, or breakpoint is often set at a particular line of code, and the processing device is allowed to operate at normal (or high) speed until the program code executes an instruction satisfying the breakpoint criteria (e.g., reaching a particular address, accessing a particular peripheral or memory location, etc. At that point, the processor device will automatically halt.
The breakpoint or event that the engineer or programmer typically selects to halt operation of the processor device is commonly known as a debug exception. Typically, debug exceptions may be based on data and/or instruction breakpoints, wherein data breakpoints halt operation of the program when the processing device accesses a specified address in memory, and instruction breakpoints halt operation of the program when the processor device executes a specified instruction. In order to respond to the debug exception event, the processor device often executes a series of operations, entitled a debug exception service routine, in response to generation of the breakpoint. The debug exception service routine leads to a user interface for the engineer or programmer to explore the status of the processor device being debugged as preserved by the stoppage at the breakpoint. Peripherals and other devices may be halted by the processor when it receives a debug exception.
FIG. 5
shows a conventional system for monitoring the occurrence of a breakpoint event set within an emulator system by a processor device.
As illustrated in
FIG. 5
, an emulator system
400
for a processor
406
typically has a breakpoint or watchpoint monitor
402
monitoring the system bus,.typically comprising a data bus
412
and an address bus
410
.
When the breakpoint monitor
402
detects the occurrence of a breakpoint, the breakpoint monitor
402
will typically issue a trap/halt signal
404
to halt the normal flow of the processor
406
. At this point, the emulated processor
406
may be operated line by line, forward or backward, etc., by the engineer or programmer using the breakpoint exception routine to locate a particular hardware or software bug related to the processor
406
.
As useful as the breakpoint and tracing functions are, the debugging process may become more difficult as the number of devices increases in a digital system. For instance, a digital system may have many processor devices (e.g., microprocessors, digital signal processors (DSPs), microcontrollers, programmable logic devices, etc.) therein communicatively operating with one another. Moreover, many digital systems include one or more processing device which operate on information asynchronously, obtained from another device, e.g., a coder/decoder (CODEC) operating on a fixed data frame basis.
The debugging process may become more complex and time intensive as the number of peripherals or non-processor devices in the digital system increases. Problems or bugs occurring with respect to a peripheral device must be typically inferred from an inspection of a processor device or memory system when halted due to a particular breakpoint due to the processor and not the peripheral. Oftentimes, a developer must go back and forth in their tracing from one processor device to the next processor device, or between processor device and a peripheral device halting one with a suitable emulation device and inspecting from the perspective of the halted device. Accordingly, back and forth testing and debugging of individual devices may not provide a complete understanding of the full digital system at the time when the relevant device is halted. Testing and debugging becomes a problem of not only testing and debugging individual components but of testing and debugging the interaction of a plurality of devices working together in a digital system.
There is a need for a breakpointing technique which allows a more accurate evaluation of a plurality of separate devices at a desired instant in time.
SUMMARY OF THE INVENTION
In accordance with the principles of the present invention, a device is disclosed to initiate and then synchronize a breakpoint from a peripheral to a processor. The device comprises a peripheral generating a breakpoint signal dependent on a user defined event for the peripheral. The device further comprises circuitry to process the breakpoint signal, independent of information passed on the busses associated with a processor, to activate a halt input of the processor.
A method for synchronizing a breakpoint is disclosed. The method comprises generating a breakpoint signal in a peripheral where the breakpoint signal is generated by a user defined event. After the breakpoint signal is generated, processing the breakpoint signal by circuitry to activate a halt input of a processor where the processing is independent of information passed on busses associated with the processor.
In accordance to the

Affiliated with

Also associated with

Rating

Peripheral breakpoint signaler does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Peripheral breakpoint signaler, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Peripheral breakpoint signaler will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3012238