Abstract:
This document relates to apparatus and methods to store and retrieve trace information in on-chip system memory of microcontrollers. A microcontroller comprises a microprocessor and a memory device accessible through a data bus and an address bus coupled to the microprocessor. The microcontroller includes on-chip debug logic coupled to the microprocessor. Trace data can be retrieved from system memory using a debug port of the debug logic. A system in accordance with the present invention will lower the cost of implementation of trace features in microcontrollers, and strongly reduce the cost of supporting such features in debug tools.

Description:
RELATED APPLICATIONS 
     This application is a continuation of U.S. patent application Ser. No. 12/616,655 filed on Nov. 11, 2009 now U.S. Pat. No. 8,219,855, which is a continuation of U.S. patent application Ser. No. 11/148,049, filed on Jun. 7, 2005 now abandoned, which is incorporated herein by reference in its entirety. 
    
    
     TECHNICAL FIELD 
     The present invention relates generally to on-chip debug functionality in microcontrollers and microprocessors that contain on-chip memory and more specifically to storing trace information in and extracting such information from on-chip memory. 
     BACKGROUND 
       FIG. 1  shows a conventional debug system  10  with direct memory access and trace support. The debug system  10  comprises a host computer  12 , a debug tool  14 , a low speed debug interface  16 , a high speed trace capture and processing unit  18 , a low-speed debug port  15 , a high-speed trace port  17 , a microcontroller device  20  and a system memory  36 . The microcontroller device  20  includes an on-chip debug logic  22 , a frame buffer  24 , an on-chip debug control  26 , a bus monitor  28 , a memory interface  30 , a CPU  32  and a bus matrix  34 . Traditionally, electronic systems with advanced control or data processing requirements would contain separate CPU  32  and memory devices, soldered onto the same printed circuit board. During developing and debugging embedded software, it was thus possible to use logic analyzers to probe the system bus to identify and capture events useful for software debugging. With the advent of powerful microcontrollers with on-chip memories, the system bus resides within the device, and the bus events are no longer available for direct capture. The problem becomes particularly noticeable as microcontrollers become ever more complex, with a corresponding increase in software complexity. As many embedded systems involve real-time communication, control, or data processing, the debugging task becomes further complicated, as more debug features have to be non-intrusive, i.e., not disrupt the real-time software execution. 
     To avoid software development time increasing exponentially, on-chip debug (OCD) logic  22  is required to assist in observing and controlling the embedded processor through a set of debug features. A debug tool  14  interfaces between the development software on a host computer  12  and the OCD logic  22  through a debug port  15  (e.g. JTAG) and a trace port  17 . 
     The most basic debug features involve intrusive control of CPU  32  operation. This includes breakpoints, to selectively halt the CPU  32  based on a specific condition, and methods to examine the CPU  32  registers and restart the CPU  32  to normal operation. These debug features are normally controlled by a set of debug registers, accessible through a debug interface, e.g., JTAG. As all real-time events are handled by the OCD logic  22 , the debug tool  14  does not have to contain high-speed logic, and can be designed in a simple, low-cost fashion. 
     The basic debug features allow intrusive debug access to system memory  36  by halting the CPU  32 , and issuing instructions to examine or alter the system memory  36 . However, with the increasing complexity of embedded real-time systems, non-intrusive direct memory access to system memory  36  has become a requirement (e.g. Nexus 2.0 standard, IEEE ISTO5001™-2003, class 3). This enables the debug tool  14  to use the low-speed debug port  15  to observe and alter memory without requiring the CPU  32  to be halted. 
     More advanced are trace features which replace the traditional logic analyzers, and thus constitute an important part of on-chip debugging in complex microcontroller applications. This involves reconstructing the program or data flow of the embedded software to identify the point of incorrect program execution. This is accomplished by logging a sequence of characteristic debug events, collectively known as trace information, such as program branches, and system bus accesses, during the software execution. Data is supplied with each event to relate the event to the execution, allowing the exact execution sequence to be reconstructed. 
     Trace information is formatted into messages, consisting of frames, corresponding to one set of data on the trace port  17  of the device. The trace information is generated in bursts, resulting in a very high peak frame rate. The average frame rate is usually much lower, and it is therefore economical to keep the generated frames in a frame buffer  24 , and transmit them through the trace port  17  at a frame rate closer to the average frame rate. The trace information can then be captured, stored, and analyzed by the debug tool  14 . 
     The trace features are nevertheless very bandwidth intensive. The frame buffer  24  and dedicated trace port  17  add to the cost of the microcontroller  20 . The high bandwidth also strongly increases the cost of the debug tool  14 , which requires complex and expensive hardware to capture and process the vast amount of high-speed trace information. 
     The trace frames are normally stored in a large buffer within the debug tool  14 , allowing for a relatively long real-time trace sequence to be captured. However, many software debug situations do not require the entire trace sequence, only the first messages (e.g. exit from an interrupt handler), or last messages (e.g. illegal entry to a trap). Thus, trace implementations with a limited trace buffer would still be highly valuable. 
     Accordingly, what is needed is a system and method for lowering the cost of implementing trace features both for the microcontroller and for the debug tools. The present invention addresses such a need. 
     SUMMARY 
     It is the object of the present invention to provide a mechanism to store and retrieve trace information in on-chip system memory of microcontrollers. A microcontroller comprises a microprocessor and a memory device accessible through a data bus and an address bus coupled to the microprocessor. The microcontroller includes on-chip debug logic coupled to the microprocessor. The on-chip debug logic includes a debug port and a mechanism for temporarily storing trace data on the memory, wherein the trace data can be retrieved from the system memory via the debug port by a debug tool. 
     A method and system in accordance with the present invention will lower the cost of implementation of trace features in microcontrollers, and strongly reduce the cost of supporting such features in debug tools. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  shows a conventional debug system with direct memory access and trace support. 
         FIG. 2  illustrates a debug system in accordance with the present invention. 
         FIG. 3  illustrates the debug system with an expanded view of the trace extractor module and the system memory. 
         FIG. 4  shows RWD register organization. 
         FIG. 5  shows reconstructing a message from the trace buffer. 
     
    
    
     DETAILED DESCRIPTION 
     The present invention relates generally to on-chip debug functionality in microcontrollers and microprocessors that contain on-chip memory and more specifically to storing trace information in and extracting such information from on-chip memory. The following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application and its requirements. Various modifications to the preferred embodiments and the generic principles and features described herein will be readily apparent to those skilled in the art. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features described herein. 
     The present invention presents a mechanism for storing trace events in system memory and allowing them to be extracted over the low-speed debug port in the device. 
     The present invention includes an implementation of an on-chip trace buffer and a frame buffer, as well as a memory interface for non-intrusive memory access. Frames are extracted from the buffer and routed to the memory interface, to be stored in a circular trace buffer in system memory, instead of transmitted on a trace port. The position and size of the trace buffer in system memory are configured by debug registers, accessible by a debug tool. In a preferred embodiment, the high-speed trace port is eliminated, and the frame buffer can be reduced in size, as the bandwidth of the memory interface is close to the peak frame rate. 
     The trace sequence that can be captured is much smaller than when using an external debug tool for trace capture, since the trace buffer is limited to the size of the allocatable internal memory. However, as stated above, many debug situations do not require a large trace sequence, if the user can control which sequence is captured. In a system and method in accordance with the present invention, the user is presented with several options when the trace buffer becomes full: 
     1. Continue writing at the start of the buffer, overwriting the oldest frames. 
     2. Stop writing, discarding any further frames generated. 
     3. Halt the CPU automatically, to avoid further messages to be generated. 
     In any case, the debug tool can at any time halt the CPU explicitly, which prevents further trace information from being generated. The debug tool can subsequently extract the previous trace information by reading out the trace buffer from system memory, without any specific bandwidth requirement. Also, the regular debug port can be used to extract the information, eliminating the need for a dedicated trace port. In addition, mechanisms are provided to identify the portion of the buffer containing valid frames, and to extract remaining frames not yet written to the buffer. Finally, mechanisms are also provided to protect the CPU from accessing the system memory area reserved for the trace buffer, to prevent incorrect trace reconstruction. 
     To describe the features of the present invention in more detail refer now to the following description in conjunction with the accompanying figures. 
       FIG. 2  illustrates a debug system  100  in accordance with the present invention. The debug system  100  comprises a host computer  12 ′, a debug tool  114 , a microcontroller device  120  and system memory  36 ′. The microcontroller device  120  includes on-chip debug logic  121 , CPU  32 ′ and a bus matrix  34 ′. Although system memory  36 ′ is shown on-chip here, the memory can reside on-chip or off-chip depending on the implantation of the microcontroller device. The on-chip debug logic  121  comprises a trace extractor module  122 , a trace buffer protect module  129 , a frame buffer  124 , an on-chip debug control  126 , a bus monitor  128 , and memory interface  130 . In this architecture, the trace extractor module  122  is added to on-chip debug logic  121  provide a mechanism for storing trace events without adding significant cost to the microcontroller device  120 . The trace extractor module  122  is an extension of the memory interface, and contains a plurality of debug registers, which can be written by the debug tool  114 , and that configure the behavior of the on-chip memory trace mechanism. To describe the function of the trace extractor module  122  in more detail refer now to the following description in conjunction with the accompanying figure. 
       FIG. 3  illustrates the debug system  100  with an expanded view of the trace extractor module  122  and the system memory  36 ′.  FIG. 3  comprises a frame buffer  124 , on-chip debug control  126 , bus monitor  128 , CPU  32 ′, bus matrix  34 ′, memory interface  130 , and trace extractor module  122 . The trace extractor module  122  comprises a trace buffer  122 , a RWD register  202 , CNT register  204 , trace buffer access protection  206 , a RWA register  208 , status registers  210  and a plurality of control registers  212 . 
     As before mentioned, the trace extractor module  122  includes a plurality of debug registers which can be written by the debug tool  114 . The registers can be summarized as follows: 
     RWA register  208 : An automatically incremented register, reflecting the next system memory address to be written. 
     RWD register  202 : a register collecting frames into bus-sized units. 
     CNT register  204 : the logarithmic size of the trace buffer. 
     Control register  212 : a control register indicating the actions taken when the trace buffer is full. Valid states are WRAP, STOP, and BREAK. 
     Status registers  210 : a plurality of single-bit read-only registers indicating the status of the trace buffer  206 . 
     The following definitions describe the status of the trace buffer  206 : 
     WRAPPED: The trace buffer  206  has been overwritten, and old messages have been discarded. 
     NTBF: A breakpoint has been issued due to the trace buffer  206  being full. 
     NTAE: A breakpoint has been issued due to the CPU  32 ′ trying to access the trace buffer  206 . 
     Referring further to  FIG. 3 , the debug tool  114  reserves a portion of system memory  36 ′ for the trace buffer  206  by writing the RWA register  208  to the START_ADDRESS, and writing the CNT register  204  with the logarithmic buffer size, creating a buffer END_ADDRESS=(START_ADDRESS+2 CNT −1). The implicit address unit used is the system bus access width, e.g. word=32 bits. 
     The trace extractor module  122  accumulates frames from the frame buffer  124  into the RWD register  202 , which is the same width as the system data bus. This register  202  collects frames until full, e.g., if the frame size is 8 bits, and the data bus 32 bits, the RWD register  202  can hold 4 frames. 
     When RWD  202  is full, the contents of the register are written through the memory interface  130  to the system memory  36 ′ address pointed to by the RWA register  208 . After this operation, the RWA register  208  is auto-incremented to point to the next location in the buffer. The RWD register  202  is cleared, i.e., filled with only empty frames. 
     When RWA  208  increments beyond END_ADDRESS, the MODE register defines the resulting behavior: 
     In a =WRAP mode: the RWA register  208  is reset to START_ADDRESS, and the trace buffer  206  is overwritten without halting the CPU  32 ′. The WRAPPED status bit is set. The debug tool  114  must halt the CPU  32 ′ before reconstruction of trace data can begin. The captured trace data will contain the last frames before the CPU  32 ′ was halted. 
     In a =STOP mode: No further trace frames are written to system memory  36 ′, but the CPU  32 ′ is not halted. The debug tool must halt the CPU  32 ′ before reconstruction of trace data can begin. The captured trace data will contain the first frames after the capture sequence was started. 
     In a =BREAK mode: No further trace frames are written to system memory  36 ′, and the CPU  32 ′ is halted. The NTBF status is set, to identify this breakpoint. Reconstruction of the trace frames can commence immediately. The captured trace data will contain all frames after the capture sequence was started. 
     Once the CPU  32 ′ is halted, regardless of reason for the breakpoint, the debugger can read out the valid trace frames from the system memory  36 ′ using the low speed debug port  15  and the memory interface  130 . 
     The location of valid frames in the trace buffer  206  depends on whether the circular trace buffer in system memory  36 ′ was overwritten or not, as indicated by the WRAPPED status bit. The WRAP status bit has the following states: 
     WRAPPED=0: The trace buffer  206  contains valid trace frames from START_ADDRESS through (RWA-l). 
     WRAPPED=1: The trace buffer  206  contains valid trace frames from END_ADDRESS plus START_ADDRESS through (RWA-l). 
     Example 
     Assuming an implementation using 8-bit Nexus-compatible frames (2-bit MSEO control and 6-bit MDO data), and a big-endian 32-bit system bus, the RWD register  202  will be organized as shown in  FIG. 4 . Accordingly this register collects frames into bus-sized units. 
       FIG. 5  shows reconstructing a message from the trace buffer  206  ( FIG. 3 ). In this example a message from the trace buffer  206  is shown after the CPU  32 ′ has been halted, with the RWA register  208  starting at 0x1000 and the CNT register=10 (i.e. the buffer size is 1024 words, or 4096 frames). When the trace was stopped, the WRAPPED status bit is set and the RWA register  208 =0x1234, so the last word of frame data written to the memory is located at 0x1230. The last two frames of the message still reside in the RWD register  202 , which has been only partially filled. 
     If the RWD register  202  was not full by the time the breakpoint occurred, these frames are not written to the trace buffer  206 . If the debug tool intends to read out the trace buffer  206 , the last frames can be found by reading the RWD register  202 , after reading out to the trace buffer  206 . 
     If the debug tool  114  does not intend to read out the trace buffer  206 , e.g. due to a non-trace-related breakpoint, it can let the CPU  32 ′ return to normal operation, and the trace operation will continue, transparently to the debug tool  114 . 
     The mechanism described above assumes that the system memory  36 ′ is a shared resource between CPU and OCD logic. This means that a software error in the CPU  32 ′ can potentially corrupt the trace data by accidentally writing to the trace buffer  206  in system memory  36 ′. This is particularly unfortunate, since loss of trace data increases the difficulty in locating this software error. To prevent this, a trace buffer protection module  129  ( FIG. 2 ), containing a comparator unit, monitors CPU accesses to system memory  36 ′, ensuring that any accesses between START_ADDRESS and END_ADDRESS will result in halting the CPU  32 ′ through a breakpoint, with the NTAE status bit set. 
     A system and method in accordance with the present invention lowers the cost of implementing trace features for the microcontroller and for the debug tools by offering a mechanism to temporarily store data in on-chip memory, to allow this data to be retrieved at an arbitrarily low bandwidth via a low speed debug port by the debug tool at a later time. A system and method in accordance with the present invention eliminates the need for a dedicated trace port in the device, reduces the size of the frame buffer, and eliminates the need for high-speed logic in the debug tool. 
     A system and method in accordance with the present invention allows for the implementation of more powerful trace features in microcontrollers without increasing the pin cost of debug features. It also allows strongly improved support for third party debug tools with trace capability, allowing more customers to take advantage of microcontrollers with on-chip trace features. 
     Although the present invention has been described in accordance with the embodiments shown, one of ordinary skill in the art will readily recognize that there could be variations to the embodiments and those variations would be within the spirit and scope of the present invention. Accordingly, many modifications may be made by one of ordinary skill in the art without departing from the spirit and scope of the appended claims.