Method and apparatus for synchronizing data in a host memory with data in target MCU memory

Claims

We claim:

1. A method for synchronizing data in a Target Memory with a copy of that data located in a Host Memory on a Host Computer, wherein:

data is organized in the Target Memory in a plurality of Target Data Lines,

each one of the plurality of Target Data Lines comprises a corresponding fixed number of bits,

each one of the plurality of Target Data Lines is uniquely identified by a corresponding Target means for identification,

each of the plurality of Target Data Lines has a corresponding Target Line Dirty Flag,

data is organized in the Host Memory in a plurality of Host Data Lines,

each one of the plurality of Host Data Lines comprises a corresponding fixed number of bits,

each one of the plurality of Host Data Lines is uniquely identified by a corresponding host means for identification,

each of the plurality of Host Data Lines has a corresponding Host Line Dirty Flag,

each of the plurality of Host Data Lines corresponds to a different one of the plurality of Target Data Lines,

said method comprising the steps of:

a) determining whenever one or more bits in one of the plurality of Target Data Lines has been modified, wherein:

the Target Data Line determined to have been modified is a Modified Target Data Line;

b) whenever the Station Controller determines in step (a) that one or more bits of the Target Data Line have been modified, determining whether the corresponding Target Line Dirty Flag is set;

c) whenever the Station Controller determines in step (a) that one or more bits in the Modified Target Data Line have been modified and that the corresponding Target Line Dirty Flag is determined in step (b) not to be set, the following substeps are performed:

1) sending a First Message from the Station Controller to the Host Computer comprising an indication that the Modified Target Data Line has been modified, and

2) setting the Target Line Dirty Flag corresponding to the Modified Target Data Line;

d) whenever a First Message sent in step (c) is received by the Host Computer, setting a Host Line Dirty Flag corresponding to the Modified Target Data Line;

e) sending a Second Message from the Host Computer to the Station Controller indicating the identity of a Host Data Line that has its corresponding Host Line Dirty Flag set;

f) sending a Third Message from the Station Controller to the Host Computer in response to the Second Message received in step (f), wherein said Third Message comprises:

an ordered sequence of bits corresponding to the bits in the Host Data Line requested in the Second Message, and

means for identifying the Host Data Line that corresponds to the ordered sequence of bits in the Third Message;

g) clearing the Target Line Dirty Flag corresponding to the Target Data Line corresponding to the Host Data Line identified by the Third Message sent in step (f);

h) when the Third Message is received by the Host Computer, updating the Host Data Line identified by the Third Message with the ordered sequence of bits in the Third Message; and

i) when the Third Message is received by the Host Computer, clearing the Host Line Dirty Flag corresponding to the Host Data Line identified by the Third Message.

2. The method in claim 1 wherein each of the corresponding fixed number of bits is an integer multiple of sixty-four (64).

3. The method in claim 1 wherein:

the Target Memory is a dual ported memory shared between the Station Controller and a Target Computer.

4. The method in claim 3 wherein within step (a):

the Station Controller determines whether one or more bits in the plurality of Target Data Lines has been modified by comparing the Target Memory with a Secondary Copy of the Target Memory.

5. The method in claim 3 wherein within step (a):

the Station Controller determines whether one or more bits in the plurality of Target Data Lines has been modified by computing a checksum for each of the Target Data Lines and comparing each of the checksums with one or more saved checksums of each of the Target Data Lines saved from a prior checksum computation.

6. The method in claim 1 wherein the First Message, the Second Message, and the Third Message are communicated between the Host computer and the Station Controller over an RS-232 connection.

7. The method in claim 1 wherein the Host Computer delays sending the Second Message for a specified Host Data Line until:

the Host Line Dirty Flag for the Host Data Line is set, and the Host Data Line is in a Visible Memory.

8. A method for real time modification of Target Memory by a Host Computer Debugger executing on a Host Computer with a Host Memory, wherein:

data is organized in the Target Memory in a plurality of Target Data Lines,

each one of the plurality of Target Data Lines comprises a corresponding fixed number of bits,

each one of the plurality of Target Data Lines is uniquely identified by a corresponding Target means for identification,

each of the plurality of Target Data Lines has a corresponding Target Line Dirty Flag,

data is organized in the Host Memory in a plurality of Host Data Lines,

each one of the plurality of Host Data Lines comprises a corresponding fixed number of bits,

each one of the plurality of Host Data Lines is uniquely identified by a corresponding host means for identification,

each of the plurality of Host Data Lines has a corresponding Host Line Dirty Flag,

each of the plurality of Host Data Lines corresponds to a different one of the plurality of Target Data Lines,

said method comprising the steps of:

a) determining whenever one or more bits in one of the plurality of Target Data Lines has been modified, wherein:

the Target Data Line determined to have been modified is a Modified Target Data Line;

b) whenever the Station Controller determines in step (a) that one or more bits of the Target Data Line have been modified, determining whether the corresponding Target Line Dirty Flag is set;

c) whenever the Station Controller determines in step (a) that one or more bits in the Modified Target Data Line have been modified and that the corresponding Target Line Dirty Flag is determined in step (b) not to be set, the following substeps are performed:

1) sending a First Message from the Station Controller to the Host Computer comprising an indication that the Modified Target Data Line has been modified, and

2) setting the Target Line Dirty Flag corresponding to the Modified Target Data Line;

d) whenever a First Message sent in step (c) is received by the Host Computer, setting a Host Line Dirty Flag corresponding to the Modified Target Data Line;

e) sending a Second Message from the Host Computer to the Station Controller indicating the identity of a Host Data Line that has its corresponding Host Line Dirty Flag set, wherein:

the identity of the Host Data Line in the Second Message corresponds to the Modified Target Data Line;

f) sending a Third Message from the Station Controller to the Host Computer in response to the Second Message received in step (f), wherein said Third Message comprises:

an ordered sequence of bits corresponding to the bits in the Host Data Line requested in the Second Message, and

means for identifying the Host Data Line that corresponds to the ordered sequence of bits in the Third Message;

g) clearing the Target Line Dirty Flag corresponding to the Target Data Line corresponding to the Host Data Line identified by the Third Message sent in step (f);

h) when the Third Message is received by the Host Computer, updating the Host Data Line identified by the Third Message with the ordered sequence of bits in the Third Message;

i) when the Third Message is received by the Host Computer, clearing the Host Line Dirty Flag corresponding to the Host Data Line identified by the Third Message;

j) sending a Fourth Message from the Host Computer to the Station Controller that comprises:

means for specifying which bits in the Target Memory are to be modified, and

one or more Replacement Data Bits to replace the corresponding bits in the Target Memory; and

k) when the Fourth Message has been received by the Station Controller, replacing the bits of Target Memory specified in the Fourth Message with the Replacement Data Bits in the Fourth Message.

9. The method in claim 8 which further comprises the step of:

1) when the Third Message has been received by the Host Computer, updating a display of the Target Memory in the Host Computer Debugger with corresponding bits from the ordered sequence of bits from the Third Message.

10. A method for synchronizing data in a Target Memory with a copy of that data located in a Host Memory on a Host Computer, wherein:

data is organized in the Target Memory in a plurality of Target Data Lines,

the Target Memory is a dual ported memory shared between the Station Controller and a Target Computer,

each one of the plurality of Target Data Lines comprises a corresponding fixed number of bits,

each one of the plurality of Target Data Lines is uniquely identified by a corresponding Target means for identification,

each of the plurality of Target Data Lines has a corresponding Target Line Dirty Flag,

data is organized in the Host Memory in a plurality of Host Data Lines,

each one of the plurality of Host Data Lines comprises a corresponding fixed number of bits,

each one of the plurality of Host Data Lines is uniquely identified by a corresponding host means for identification,

each of the plurality of Host Data Lines has a corresponding Host Line Dirty Flag,

each of the plurality of Host Data Lines corresponds to a different one of the plurality of Target Data Lines,

said method comprising the steps of:

a) determining whenever one or more bits in one of the plurality of Target Data Lines has been modified, wherein:

the Target Data Line determined to have been modified is a Modified Target Data Line, and

the Station Controller determines whether one or more bits in the plurality of Target Data Lines has been modified by comparing the Target Memory with a Secondary Copy of the Target Memory;

b) whenever the Station Controller determines in step (a) that one or more bits of the Target Data Line have been modified, determining whether the corresponding Target Line Dirty Flag is set;

c) whenever the Station Controller determines in step (a) that one or more bits in the Modified Target Data Line have been modified and that the corresponding Target Line Dirty Flag is determined in step (b) not to be set, the following substeps are performed:

1) sending a First Message from the Station Controller to the Host Computer comprising an indication that the Modified Target Data Line has been modified, and

2) setting the Target Line Dirty Flag corresponding to the Modified Target Data Line;

d) whenever a First Message sent in step (c) is received by the Host Computer, setting a Host Line Dirty Flag corresponding to the Modified Target Data Line;

e) sending a Second Message from the Host Computer to the Station Controller indicating the identity of a Host Data Line that has its corresponding Host Line Dirty Flag set;

f) sending a Third Message from the Station Controller to the Host Computer in response to the Second Message received in step (f), wherein said Third Message comprises:

an ordered sequence of bits corresponding to the bits in the Host Data Line requested in the Second Message, and

means for identifying the Host Data Line that corresponds to the ordered sequence of bits in the Third Message;

g) clearing the Target Line Dirty Flag corresponding to the Target Data Line corresponding to the Host Data Line identified by the Third Message sent in step (f);

h) when the Third Message is received by the Host Computer, updating the Host Data Line identified by the Third Message with the ordered sequence of bits in the Third Message; and

i) when the Third Message is received by the Host Computer, clearing the Host Line Dirty Flag corresponding to the Host Data Line identified by the Third Message.

11. An apparatus for synchronizing data in a Target Memory with a copy of that data located in a Host Memory on a Host Computer, wherein:

data is organized in the Target Memory in a plurality of Target Data Lines,

each one of the plurality of Target Data Lines comprises a corresponding fixed number of bits,

each one of the plurality of Target Data Lines is uniquely identified by a corresponding Target means for identification,

each of the plurality of Target Data Lines has a corresponding Target Line Dirty Flag,

data is organized in the Host Memory in a plurality of Host Data Lines,

each one of the plurality of Host Data Lines comprises a corresponding fixed number of bits,

each one of the plurality of Host Data Lines is uniquely identified by a corresponding host means for identification,

each of the plurality of Host Data Lines has a corresponding Host Line Dirty Flag,

each of the plurality of Host Data Lines corresponds to a different one of the plurality of Target Data Lines,

said apparatus comprising of:

a) means for determining whenever one or more bits in one of the plurality of Target Data Lines has been modified, wherein:

the Target Data Line determined to have been modified is a Modified Target Data Line;

b) means for determining whether the corresponding Target Line Dirty Flag is set whenever element (a) determines that one or more bits in the Modified Target Data Line have been modified;

c) means for invoking the following subelements whenever element (a) determines that one or more bits in the Modified Target Data Line have been modified and, element (b) determines that the corresponding Target Line Dirty Flag is not set:

1) means for sending a First Message from the Station Controller to the Host Computer comprising an indication that the Modified Target Data Line has been modified, and

2) means for setting the Target Line Dirty Flag corresponding to the Modified Target Data Line;

d) means for setting a Host Line Dirty Flag corresponding to the Modified Target Data Line in response to a receipt of the First Message received by the Host Computer;

e) means for sending a Second Message from the Host Computer to the Station Controller indicating the identity of a Host Data Line that has its corresponding Host Line Dirty Flag set;

f) means for sending a Third Message from the Station Controller to the Host Computer in response to the Second Message received in step (f), wherein said Third Message comprises:

an ordered sequence of bits corresponding to the bits in the Host Data Line requested in the Second Message, and

means for identifying the Host Data Line that corresponds to the ordered sequence of bits in the Third Message;

g) means for clearing the Target Line Dirty Flag corresponding to the Target Data Line corresponding to the Host Data Line identified by the Third Message sent in step (f);

h) means for updating the Host Data Line identified by the Third Message with the ordered sequence of bits in the Third Message in response to a receipt of the Third Message by the Host Computer; and

i) means for clearing the Host Line Dirty Flag corresponding to the Host Data Line identified by the Third Message in response to a receipt of the Third Message by the Host Computer.

12. The apparatus in claim 11 wherein each of the corresponding fixed number of bits is an integer multiple of sixty-four (64).

13. The apparatus in claim 11 wherein:

the Target Memory is a dual ported memory shared between the Station Controller and a Target Computer.

14. The apparatus in claim 13 wherein within element (a):

the means for determining whether one or more bits in the plurality of Target Data Lines has been modified compars the Target Memory with a Secondary Copy of the Target Memory.

15. The apparatus in claim 13 wherein within element (a):

the means for determining whether one or more bits in the plurality of Target Data Lines has been modified computes a checksum for each of the Target Data Lines and compares each of the checksums with one or more saved checksums of each of the Target Data Lines saved from a prior checksum computation.

16. The apparatus in claim 11 wherein the First Message, the Second Message, and the Third Message are communicated between the Host computer and the Station Controller over an RS-232 connection.

17. The apparatus in claim 11 wherein the Host Computer delays sending the Second Message for a specified Host Data Line until:

the Host Line Dirty Flag for the Host Data Line is set, and the Host Data Line is in a Visible Memory.

18. An apparatus for real time modification of Target Memory by a Host Computer Debugger executing on a Host Computer with a Host Memory, wherein:

data is organized in the Target Memory in a plurality of Target Data Lines,

each one of the plurality of Target Data Lines comprises a corresponding fixed number of bits,

each one of the plurality of Target Data Lines is uniquely identified by a corresponding Target means for identification,

each of the plurality of Target Data Lines has a corresponding Target Line Dirty Flag,

data is organized in the Host Memory in a plurality of Host Data Lines,

each one of the plurality of Host Data Lines comprises a corresponding fixed number of bits,

each one of the plurality of Host Data Lines is uniquely identified by a corresponding host means for identification,

each of the plurality of Host Data Lines has a corresponding Host Line Dirty Flag,

each of the plurality of Host Data Lines corresponds to a different one of the plurality of Target Data Lines,

said apparatus comprising of:

a) means for determining whenever one or more bits in one of the plurality of Target Data Lines has been modified, wherein:

the Target Data Line determined to have been modified is a Modified Target Data Line;

b) means for determining whether the corresponding Target Line Dirty Flag is set whenever element (a) determines that one or more bits in the Modified Target Data Line have been modified;

c) means for invoking the following subelements whenever element (a) determines that one or more bits in the Modified Target Data Line have been modified and, element (b) determines that the corresponding Target Line Dirty Flag is not set:

1) means for sending a First Message from the Station Controller to the Host Computer comprising an indication that the Modified Target Data Line has been modified, and

2) means for setting the Target Line Dirty Flag corresponding to the Modified Target Data Line;

d) means for setting a Host Line Dirty Flag corresponding to the Modified Target Data Line in response to a receipt of the First Message received by the Host Computer;

e) means for sending a Second Message from the Host Computer to the Station Controller indicating the identity of a Host Data Line that has its corresponding Host Line Dirty Flag set, wherein:

the identity of the Host Data Line in the Second Message corresponds to the Modified Target Data Line;

f) means for sending a Third Message from the Station Controller to the Host Computer in response to the Second Message received in step (f), wherein said Third Message comprises:

an ordered sequence of bits corresponding to the bits in the Host Data Line requested in the Second Message, and

means for identifying the Host Data Line that corresponds to the ordered sequence of bits in the Third Message;

g) means for clearing the Target Line Dirty Flag corresponding to the Target Data Line corresponding to the Host Data Line identified by the Third Message sent in step (f);

h) means for updating the Host Data Line identified by the Third Message with the ordered sequence of bits in the Third Message in response to a receipt of the Third Message by the Host Computer;

i) means for clearing the Host Line Dirty Flag corresponding to the Host Data Line identified by the Third Message in response to a receipt of the Third Message by the Host Computer;

j) means for sending a Fourth Message from the Host Computer to the Station Controller that comprises:

means for specifying which bits in the Target Memory are to be modified, and

one or more Replacement Data Bits to replace the corresponding bits in the Target Memory; and

k) means for replacing the bits of Target Memory specified in the Fourth Message with the Replacement Data Bits in the Fourth Message in response to the receipt of the Fourth Message by the Station Controller.

19. The apparatus in claim 18 which further comprises:

1) means for updating a display of the Target Memory in the Host Computer Debugger with corresponding bits from the ordered sequence of bits from the Third Message in response to the receipt of the Third Message by the Host Computer.

20. An apparatus for synchronizing data in a Target Memory with a copy of that data located in a Host Memory on a Host Computer, wherein:

data is organized in the Target Memory in a plurality of Target Data Lines,

the Target Memory is a dual ported memory shared between the Station Controller and a Target Computer,

each one of the plurality of Target Data Lines comprises a corresponding fixed number of bits,

each one of the plurality of Target Data Lines is uniquely identified by a corresponding Target means for identification,

each of the plurality of Target Data Lines has a corresponding Target Line Dirty Flag,

data is organized in the Host Memory in a plurality of Host Data Lines,

each one of the plurality of Host Data Lines comprises a corresponding fixed number of bits,

each one of the plurality of Host Data Lines is uniquely identified by a corresponding host means for identification,

each of the plurality of Host Data Lines has a corresponding Host Line Dirty Flag,

each of the plurality of Host Data Lines corresponds to a different one of the plurality of Target Data Lines,

said apparatus comprising:

a) means for determining whenever one or more bits in one of the plurality of Target Data Lines has been modified, wherein:

the Target Data Line determined to have been modified is a Modified Target Data Line, and

Target Data Lines are determined to have been modified by by comparing the Target Memory with a Secondary Copy of the Target Memory;

b) means for determining whether the corresponding Target Line Dirty Flag is set whenever element (a) determines that one or more bits of the Target Data Line have been modified;

c) means for invoking the following elements whenever element (a) determines that one or more bits in the Modified Target Data Line have been modified and element (b) determines that the corresponding Target Line Dirty Flag are not to be set:

1) means for sending a First Message from the Station Controller to the Host Computer comprising an indication that the Modified Target Data Line has been modified, and

2) means for setting the Target Line Dirty Flag corresponding to the Modified Target Data Line;

d) whenever a First Message sent in step (c) is received by the Host Computer, means for setting a Host Line Dirty Flag corresponding to the Modified Target Data Line;

e) means for sending a Second Message from the Host Computer to the Station Controller indicating the identity of a Host Data Line that has its corresponding Host Line Dirty Flag set;

f) means for sending a Third Message from the Station Controller to the Host Computer in response to the Second Message received in step (f), wherein said Third Message comprises:

an ordered sequence of bits corresponding to the bits in the Host Data Line requested in the Second Message, and

means for identifying the Host Data Line that corresponds to the ordered sequence of bits in the Third Message;

g) means for clearing the Target Line Dirty Flag corresponding to the Target Data Line corresponding to the Host Data Line identified by the Third Message sent in step (f);

h) means for updating the Host Data Line identified by the Third Message with the ordered sequence of bits in the Third Message when the Third Message is received by the Host Computer; and

i) means for clearing the Host Line Dirty Flag corresponding to the Host Data Line identified by the Third Message when the Third Message is received by the Host Computer.

21. An apparatus for synchronizing data in a Target Memory with a copy of that data located in a Host Memory on a Host Computer, wherein:

data is organized in the Target Memory in a plurality of Target Data Lines,

each one of the plurality of Target Data Lines comprises a corresponding fixed number of bits,

each one of the plurality of Target Data Lines is uniquely identified by a corresponding Target means for identification,

each of the plurality of Target Data Lines has a corresponding Target Line Dirty Flag,

data is organized in the Host Memory in a plurality of Host Data Lines,

each one of the plurality of Host Data Lines comprises a corresponding fixed number of bits,

each one of the plurality of Host Data Lines is uniquely identified by a corresponding host means for identification,

each of the plurality of Host Data Lines has a corresponding Host Line Dirty Flag,

each of the plurality of Host Data Lines corresponds to a different one of the plurality of Target Data Lines,

said apparatus comprising:

a) a Station Controller connected to the Memory programmed to determine whenever one or more bits in one of the plurality of Target Data Lines has been modified, wherein:

the Target Data Line determined to have been modified is a Modified Target Data Line;

b) the Station Controller programmed to determine whether the corresponding Target Line Dirty Flag is set whenever the Station Controller determines in element (a) that one or more bits of the Target Data Line have been modified;

c) the Station Controller programmed to activate the following elements whenever the Station Controller determines in element (a) that one or more bits in the Modified Target Data Line have been modified and that the corresponding Target Line Dirty Flag is determined in element (b) not to be set:

1) the Station Controller programmed to send a First Message to the Host Computer comprising an indication that the Modified Target Data Line has been modified, and

2) the Station Controller programmed to set the Target Line Dirty Flag corresponding to the Modified Target Data Line;

d) a Host Computer Processor programmed to set a Host Line Dirty Flag corresponding to the Modified Target Data Line whenever a First Message sent in step (c) is received by the Host Computer;

e) the Host Computer Processor programmed to send a Second Message to the Station Controller indicating the identity of a Host Data Line that has its corresponding Host Line Dirty Flag set;

f) the Station Controller programmed to send a Third Message to the Host Computer in response to the Second Message received wherein said Third Message comprises:

an ordered sequence of bits corresponding to the bits in the Host Data Line requested in the Second Message, and

means for identifying the Host Data Line that corresponds to the ordered sequence of bits in the Third Message;

g) the Station Controller programmed to clear the Target Line Dirty Flag corresponding to the Target Data Line corresponding to the Host Data Line identified by the Third Message sent in step (f);

h) the Host Computer Processor programmed to update the Host Data Line identified by the Third Message with the ordered sequence of bits in the Third Message when the Third Message is received by the Host Computer; and

i) the Host Computer Processor programmed to clear the Host Line Dirty Flag corresponding to the Host Data Line identified by the Third Message when the Third Message is received by the Host Computer.

CROSS REFERENCE TO RELATED APPLICATION

This application is related to our copending patent application entitled METHOD AND APPARATUS FOR AUTOMATICALLY RECONFIGURING A HOST DEBUGGER BASED ON A TARGET MCU IDENTITY, application Ser. No. 08/485,330 filed on Jun. 7, 1995, of even date herewith and assigned to the assignee hereof.

This application is related to our copending patent application entitled METHOD AND APPARATUS FOR RESTORING A TARGET MCU DEBUG SESSION TO A PRIOR STATE, application Ser. No. 08/485,333, filed on Jun. 7, 1995, of even date herewith and assigned to the assignee hereof.

This application is related to our copending patent application entitled METHOD AND APPARATUS FOR DYNAMICALLY RECONFIGURING A PARSER, application Ser. No. 08/485,330, filed on Jun. 7, 1995, of even date herewith and assigned to the assignee hereof.

1. Field of the Invention

The present invention generally relates to circuit testing, and more specifically to providing an interactive embedded Microcontroller Unit (MCU).

2. Background of the Invention

When manufacturers of consumer products wish to modernize their end products (by adding features, reducing cost, by improving reliability, or simply accomplishing things that were not heretofore possible) they frequently will employ a microcontroller in their products. The microcontroller is said to be embedded in their products. In an embedded microcontroller, software developers will typically "embed" their programs, which usually means they are programmed into the ROM of the MCU. The product developers need a method to develop the software (or computer program) which will execute in the completed product. They will use a cross-compiler or cross-assembler to develop the code. In order to integrate, test, and debug that code, they need a debugger which is closely coupled to the cross compiler or cross assembler.

Due to shortening design cycle-time (time to market pressure), it is necessary for a debugger to make testing and debugging as productive as possible for a developer. Also, program development for "embedded" systems tends to be more tedious than for regular desktop computers since the constraints are different. This is due to the fact that "embedded" systems rely extensively on real-time operation which make interrupts and other external events very crucial to the correct operation of the system. Also, unlike desktop systems, the processor in an "embedded" system is just one portion of the overall system and is not the main processing unit. Lack of a console for debugging (no input/output support) also hinders developing applications because it denies developers the window they need into the state of their applications. This elevates the role that a debugger plays in the overall embedded application development cycle because a developer relies heavily upon his debugger to provide him with information regarding his application running in the microcontroller.

On mainstream development platforms such as UNIX.TM. or Microsoft Windows.TM. the development tools support is fairly sophisticated and mature. However for "embedded" applications, there tends to be a disconnect in the development tools between the cross compilers/assemblers and the debuggers. Also, all the project management utilities that the developer uses are not tied in closely with his development toolset. This often has a significant impact on a developer's cycle time because the toolset disconnect usually means that he has to relearn a new interface everytime he decides to make a change in his development methodology. Developers need a development environment which provide them with a familiar interface across all aspects of application development--coding, compiling, debugging and managing. This flees developers from having to go up the learning curve everytime they starts a new project.

Real time support currently provided by debuggers tends to be fairly immature. Commercially available "embedded" debuggers are not closely tied into the MCU that they support. This usually means that these debuggers do not cover all aspects of being a "real-time debugger" in that they cover half of the bases. A developer must not only be able to observe the execution of his application in real-time, but also be able to change parameters of his application, and be able to generate events in real-time in order to modify program flow-control. This functionality would give the developer a better feel for the execution of his application.

SUMMARY OF THE INVENTION

In accordance with the invention, a copy of data in a Host Computer is synchronized with a version located in Shared Memory in a Modular Development System (MDS). Whenever a change in one or more bits in a Line of Data in Shared Memory are detected, a MDS Line Dirty Flag is checked. If the Flag is not set, it is set and a message is sent to the Host Computer that the Line of Data is now dirty. Whenever the Host Computer receives this message for a Line of Data in its visible memory, it sends a request to the MDS to read that Line from Shared Memory and send it to the Host Computer. Otherwise, a Host Line Dirty Flag is set. The Host Computer also sends a request to read a Line of Data when that Line of Data is scrolled onto a screen and the corresponding Host Line Dirty Flag is set.

These and other features, and advantages, will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings. It is important to point out that there may be other embodiments of the present invention which are not specifically illustrated.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram showing the hardware components of the host portion of the MCUdebug system, in accordance with the present invention;

FIG. 2 is a block diagram showing the hardware components of the Modular Development System (MDS), in accordance with the invention;

FIG. 3 is a flowchart showing how the host MCUdebug program determines the identity of the Target MCU, in accordance with the present invention;

FIG. 4 is a flow chart showing the Autoloader function of the MCUdebug program, in accordance with the present invention;

FIG. 5 is a flow chart showing the operation of the test for P&E format module, in accordance with the present invention;

FIG. 6 is a flow chart showing the COFF Format Read procedure, in accordance with the present invention;

FIG. 7 is a program structure chart showing the relationship among the high level modules in the monitor program executed by the Station Controller, in accordance with the present invention;

FIG. 8 is a state chart showing in accordance with the present invention the state transitions encountered by the Station Controller when executing commands;

FIG. 9 is a procedure call diagram showing the operation of the Station Controller Executive module, in accordance with the present invention;

FIG. 10 shows a typical memory map of a Target MCUr;

FIG. 11 is a block diagram showing the interaction between the Target MCU memory and a real time display of the memory on the Host Computer, in accordance with the present invention;

FIG. 12 is a flow chart that shows in accordance with the present invention part of the monitor activity of the Station Controller;

FIG. 13 is a flow chart that shows in accordance with the present invention the actions taken by the Host Computer when a Line Dirty message is received from the MDS, in accordance with the present invention;

FIG. 14 is a flow chart that shows in accordance with the present invention the actions taken by the Station Controller when it receives a request that a specified Line of Text be read from Shared Memory and sent to the Host Computer;

FIG. 15 is a flow chart that shows in accordance with the present invention the actions taken by the Host Computer when it receives a Line of Text from the MDS;

FIG. 16 is a flow chart that shows in accordance with the present invention the actions taken by the Host Computer when the MCUdebug operator scrolls the Window by moving the scroll button in the scroll bar;

FIG. 17 is a flow chart in accordance with the present invention showing the actions of the Host Computer taken to synchronize versions when updating the Shared Memory;

FIG. 18 is a flow chart showing in accordance with the present invention the actions taken by the Station Controller when receiving a Write or Update Command from the Host Computer;

FIG. 19 is a flow chart showing in accordance with the present invention the operation of the MCUdebug restart facility.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

As embedded microcontroller units (MCUs) have become increasingly popular, the diversity in architectures available continues to grow in leaps and bounds. Unfortunately, until now, the sophistication of the development tools available for software development for these embedded microcontrollers has not kept pace. Highly integrated tools available on mainstream platforms such as Microsoft Visual C++.TM. for personal computers and SUN Microsystems SPARCworks.TM. for UNIX.TM. workstations offer users a productivity boost in application development. Until now, similar kinds of tools for embedded system development have not been available.

Integrated development environments provide users with the capability to design and develop their applications from within the same interface. Development environments allow the user to develop effective applications without having to climb up the learning curve on all the different tools that they use to build their applications. They also reduce the busy work that goes along with developing an application such as writing and updating a "makefile" and the constant switching that goes on between editors, compilers, and debuggers.

The MCUdebug software system is an application development and debugging environment for embedded microcontrollers. It allows users to edit, build, and debug their applications all within the same graphical user interface. It dynamically supports a variety of execution targets, including in-circuit emulators, evaluation systems and boards, and instruction set simulators.

MCUdebug allows the user to define the toolset they are using to develop their application. On building the application a makefile is automatically generated and the application is built (with any errors encountered displayed in an output window). MCUdebug is an integrated development environment that can be used to successfully develop embedded applications.

Developing applications for an embedded system poses many challenges compared to developing an application for a personal computer or a workstation. MCUs typically do not support an on-chip operating system to provide resource allocation support to applications. Therefore, application have no mechanism for memory management functions, input/output (disk, console window, ports), or other support functions. Multiple processes or tasks on an MCU can only be supported (to a limit) with the use of a real-time operating system. The following sections outline some other fundamental aspects of embedded software development.

Due to the lack of an operating system, applications must be developed on a different platform (such as a personal computer or a workstation), and then downloaded into the MCU memory for execution and debugging. For example, one could develop his application for a Motorola MC68HC08.TM. microcontroller using tools available for either Microsoft Windows.TM. or UNIX.TM.. Using a debugger, the object code generated can then be downloaded into the target evaluation system for executing and debugging the application.

Since embedded MCUs do not support basic input/output, a console window is not available where a developer can observe the execution of his application. Also, no interaction can take place between an application and its developer during program execution. Normally, a debugger can be used to provide something close to a console, since it allows a user to observe the state of his application at any point. Debuggers also allow a user to perform traditional debugging operations like instruction tracing and programmed breakpoints.

Embedded MCUs tend to lack extensive on-chip memory resources such as RAM and ROM. This forces users to make decisions regarding memory usage and allocation (something the operating system linker/loader does automatically for a user). It also requires the development and availability of highly optimizing compilation tools which make very efficient use of the instruction set and the limited memory resources. Techniques such as overlays and allocation of data to either RAM or ROM as appropriate must be available.

MCUs are mostly used as a "processing element" in embedded systems. They are normally used as a portion of a larger, complex system. That means that they tend to perform an action as a result of a certain request. For example, an MCU might need to update a counter as a result of an interrupt. Since there is no guarantee as to when a request might be made, receiving and processing of asynchronous events tends to play an important role in embedded applications. Developers need to ensure that the time to process interrupts will not exceed the minimum period between interrupts in target systems, so that events are not lost.

Many toolsets are available for microcontroller development, but there is very little cohesiveness amongst them. For example, they do not support the same syntax for C or Assembly, do not generate the same object file formats, and do not provide the same functionality. Even error message formats differ between toolsets of different vendors. Lack of such standards causes problems in portability of applications among toolsets. That usually results in extra development effort to port applications between microcontrollers and toolsets, and usually causes a change in the performance of the application.

The previous section focused on some of the aspects of developing embedded applications. In the next section, we will take a closer look at some of the necessities for developing embedded applications.

There are certain attributes that every application being developed possesses. For example, there are source files, object files, and a toolset used to generate the project. All of these attributes can be grouped under the concept of a "project". Under traditional development conditions, a user is burdened with keeping track of the state of the object files with respect to the source files, and making consistent use of toolset options. A developer can define a project, and then make changes to it as development progresses.

In an integrated development environment, the environment takes care of keeping applications up to date: i.e., if a source file changes, it must flag the user to recompile it or if source files are added/deleted to a project, it must automatically regenerate a makefile. In this scenario, the only work developers must do is to add or delete source files, define their toolset used to build the application, and the rest of the work is taken care of by the development environment.

Bus State Analysis capabilities tend to be very important in embedded systems, since these capabilities allow a user the capability to track the exact flow of control through his application. These capabilities can be used without stopping program execution, and thus are particularly useful in real-time systems for which breakpointing would be inconvenient.

The success of an environment is very closely tied to its "look and feel" and how it allows the user to get the job done. An application might overpower its developer if information is not presented in a coherent manner. Applications must allow user customization so that users can customize their applications to make them look or operate like some other tool they might be familiar with.

Most integrated development environments are built around a single proprietary toolset. In the embedded systems development arena, there are generally a variety of cross assemblers and cross compilers available. Frequently users will become familiar with a particular toolset and will wish to standardize development around that toolset. It would be desirable to allow any favorite tool to be integrated into an integrated development environment.

In the next section, we shall show all the phases in the development of a simple embedded application. Applications normally follow the lifecycle of application design: writing the application, project definition/application generation and debugging/verification of program correctness. In this next section, we shall actually go through the various development cycles and point out important facts to look out for when developing embedded applications.

One example application is a modified version of the Paced Loop Framework program from Understanding Small Microcontrollers, by James M. Sibigtroth. The program is a general purpose software structure that can be used in a wide variety of MCU applications. Under control of the output compare interrupt timer of the Motorola MC68HC05.TM. MCU, the program polls various peripheral devices, servicing any that require service. The timing of the paced loop is designed to provide time to service during the time period of the loop, thus polling each device once each time through the loop. MCUdebug is used throughout the development of the application to demonstrate the features of the software. The program is included herein as the Appendix.

Even though the above described application contains only a single source file, project management is still helpful. Toolset definition occurs only once and thereafter makefile generation and application builds are automated. For example, a dialog window "Edit Window" allows a user to add/delete source files from the project. A "Toolset Options" dialog allows a user to setup options which are used to generate the makefile. The "Customize Assembler" dialog is an example of a dialog which a user can use to setup his application generation assembler.

F