JPH1011112A - Monitor device for developing and monitoring firmware for system, developing method, and in-generic-circuit emulator device - Google Patents

Abstract

PROBLEM TO BE SOLVED: To access the contents of a memory and a register in real time and alter them irrelevantly to differences of a target processor by providing a host computer with a monitor system to monitor a target system in real time and hold its monitor result. SOLUTION: A host monitor system 10 consists of a host processor 11, modules 13-18, and a host bus 12 which interconnects them and connected mutually to the target system 30 through a communication protocol given by using a communication line 39. The target system 30 consists of the target processor 34, processor firmware 35, system hardware 36, a communication module, and an internal bus 31. Then the host monitor system 10 is used to develop and test the target system 30, and present on the host computer system so as to monitor the target system 30 in real time and hold the monitor result.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

The present invention relates to an apparatus used for developing and testing firmware for an embedded processor system.

[0002]

BACKGROUND OF THE INVENTION The use of embedded processor systems is widespread. Its applications range from simple consumer electronics to advanced aerospace systems. Apart from the hardware design, the firmware program must be written so that the embedded processor works as specified.

[0003] Testing and bug removal in real-time systems is time consuming and tedious. Processors use a time division strategy to service the various software modules of the system in real time. For this reason, it is difficult to determine the execution state of the processor at a certain point in time.

At present, in-circuit emulators are used to assist in the development of firmware programs and the removal of bugs with the help of code trace and step equipment. In-circuit emulators use a remote pad that plugs into the processor's socket to search and test the processor's signals. The interface allows a user to monitor and intervene in the operation of the processor. An in-circuit emulator allows breakpoints to be set at specific locations in the code. The contents of internal memory and registers can only be examined when the processor is stopped.

[0005] In-circuit emulators work exclusively for processors that they are designed to emulate. It is not possible to transfer the use of an emulator from one class of processor to a completely different set of processors. Emulators are therefore special processors.

Software equivalent to an in-circuit emulator can be used to verify the functionality of the firmware. Software emulators are software used to simulate the resources and behavior of a particular processor. However, this test method cannot investigate the effect of firmware on the associated hardware connected to the processor.

A hardware device that monitors the input / output signals of the target processor is used. This device allows data or command signals to be introduced at the input pins of the processor. This monitors the processor's response to a given input pin.

The hardware device and in-circuit emulator described above are two independent firmware bug removal systems. However, they are used together to form an integrated development and test system.

Testing and bug removal of firmware in real-time embedded systems is tedious and time consuming. One such system is provided in the field of consumer electronics.

[0010] Many electronic devices incorporate a real-time clock with an event that is activated at a specific time preset by the user. Testing and bug elimination performed in such a system is time consuming because the real time must wait for the event schedule to be activated. If the firmware changes, the system must be tested again. These lengthy and repetitive test cycles significantly increase the time required to test the system. No equipment is provided for unsupervised verification of events related to real-time clocks.

[0011] One such example is the timer and clock subsystem in consumer audio products. The timer has a wake-up and sleep mode. The specific time when the audio device enters or operates in a standby mode (sleep mode) can be preset. To test such a system, a wake-up or sleep time is first set. Real-time must elapse before testing to see if the correct event occurs. The time to activate sleep or standby mode can be many hours apart.
As a result, many wait times elapse before an appropriate event occurs. For example, if the current time is 07:00 and the wake-up time is set to 19:00, 12
It will be a waiting time. This long waiting time is time consuming and needs to be reduced.

There is a need to investigate the contents of memory and registers during bug removal in a real-time system. Current in-circuit emulators only allow changes to the memory contents when the processor is in a halt or reset state. Changing the memory by the in-circuit emulator is not possible when the processor is running.

The in-circuit emulator is an expensive and special processor. In an environment where many combinations of processors are available, it is not economically feasible to get a respective emulator. Time is also required to allow users to become familiar with the operation of each new emulator. Emulators that can target different processors are not available. As the transfer from use of one processor to another in a typical system occurs, the program variable arrays and labels used in current and previous firmware sets are usually different. Third parties who attempt to troubleshoot firmware will have difficulty understanding the code as variables and labels because the same function is named differently.

A low cost integrated device for testing, bug removal and monitoring of a system under development, including a subset or full set of common emulators, greatly enhances the development and bug removal of firmware for embedded processor systems. A tool that can be promoted.

An object of the present invention is to provide a monitor device for developing and testing firmware for a processor system which is more versatile, a development method, and an in-circuit emulator device.

[0016]

SUMMARY OF THE INVENTION In a first aspect of the present invention, a real-time monitor for testing and removing bugs in firmware in an embedded processor-based system is disclosed. The apparatus includes a host computer subsystem, a target subsystem representing an embedded processor system, a communication link subsystem connecting the host computer subsystem and the target subsystem,
And a monitor subsystem existing in the host computer subsystem for real-time monitoring operation of the target subsystem and holding the monitor result.

In another aspect of the invention, a standardized development of a communication primitive that allows one of a plurality of target subsystems, each having a different control processor, to be tested using a host monitor system. A method is disclosed. The method comprises the steps of a user interface subsystem, a processor resource data warehouse subsystem, a test database engine subsystem, an autotester subsystem, a general emulator hardware subsystem, and a general remote processor pod subsystem.

From the present invention, an economical and efficient system has been devised which allows the contents of memories and registers to be accessed and modified in real time. The system can monitor the operation of any type of processor. The system facilitates the operation of the processor,
It includes means for monitoring the memory and register resources of the target processor in real time, means for different groups of processors to be monitored using the same host and communication subsystem.

The host processor subsystem is a means for storing and documenting test cases for a particular test, a means for performing tests over an extended period of time without human intervention, and a means for describing the internal resources of the target processor to the monitor system. Means for accepting user input and providing feedback to the user, means for encoding user input, and means for sending information to the target subsystem.

The target processor subsystem includes means for decoding the information sent by the host monitor subsystem, means for reading and writing from memory and registers according to the requirements of the monitor subsystem, and means for sending information to the monitor subsystem.

Whenever a new processor is used, a general-purpose emulator device is provided to address the problem of having to use a new emulator. The apparatus uses only one set of hardware to implement target processor bug elimination across different platforms and manufacturers, a means for storing and editing the internal resource configuration of different processors in a processor data repository, Means for initializing and setting up the general purpose emulator for use with the new processor, for extracting the processor data from the storage location for setting up, for providing a standardized user interface independent of the target processor used, A means for reading and writing memory in real time while in use, and a means for a remote processor pod to accommodate processors having different packages and pin configurations.

To address the problem of variable use of variable arrays and label names by different developers across different processors, in a preferred embodiment to standardize the names of variables, means are used and labels are provided. .

[0023]

FIG. 1 shows a host monitor system 10 interconnected to a target system 30 via a communication protocol provided using a communication line 39. FIG. The host monitor system 10 is used for software development and testing of the target system 30. The host monitor system 10 includes a user command interface module 18, a communication module including a hardware interface 13 to a communication line 39 and a communication primitive module 14, a monitor module 15, a database engine module 17, an automatic test module 16, a set of target systems. Specification storage unit 19, host processor 1
1 and a host bus 12 interconnecting the module and the host processor 11.

The target system 34 of FIG.
, A processor firmware 35 for the target processor 34, typically formed in ROM internal or external to the target processor, a system hardware 34 including any devices controlled by the target processor, a communication line 39. It comprises a communication module including a primitive 33 and a hardware interface 32 for communicating with the host monitor system via the host monitor system; In particular, system hardware 36 may include a real-time clock that operates as described above.

The user command interface 18 accepts user input. The user first specifies a particular type of target processor to be used in development and testing. Application specific attribute values and settings are issued to allow initialization of the target processor 34. The user interface 18 also displays the response returned by the target processor 34 to inform the user of the results of the input.

The user interface 18 transmits / receives information to / from the target system 30 via the user command 28 and the monitor response 29 via the monitor module 15.
Communicate with The monitor module 16 reads the set of the target system specification storage unit 19 and forms a communication command 22 sent to the communication module together with the input from the user interface 18.

A collection of independent primitives of a standardized processor resides in the communication primitives module 14. The set of primitives provides access to data in ROM and registers in target processor 34. A corresponding set of primitives is also needed to execute the command. To achieve a higher degree of encapsulation so that differences in the hardware structure of different processors can be hidden, primitives for executing commands are provided differently across the various processors that can be used as target processors 34. Regardless of the processor platform, primitives are named similarly, and those with the same name are always functionally related. Using this approach, differences in the structure of different target processors are hidden from the host system 10.

The target system specification storage unit 19 contains not only application specification information of the target system 30 but also processor specification information. The processor specification information includes the register configuration of the target processor 34 and the RAM / ROM
Contains the map. Application specification information is RA
Includes a description of the assignment and use of M. The use of variable names of programs for similar functions can be standardized across different processor platforms. However, the address locations of similarly named variables can be different.

The automatic test module 16 derives its inputs from a pre-programmed sequence of test operations. The test operation is sent to the monitor module 15 as a test sequence 24. The monitor module 15 sends an appropriate command 22 to the communication module together with the processor specification collected from the target system specification storage unit 19.

The monitor module 15 receives an input from the target system 30 via the communication module 15,
The result is resent to the automatic test module 16 as a series of test results. The automatic test module 16 sends the result to the storage device 27 in the database engine module 17. Further, the automatic test module 16 can interpret the result received from the monitor module 15 and take appropriate action. For example, if the target processor 34 detects an execution error condition and cannot proceed without human intervention, the test can be terminated.

The database engine module 17
Used to formulate the response of the target system 30.
The database engine module 17 also stores the different test sequences required to test the custom target system. The database record is
It can include application types, processor types, test types, test documentation, and lists of commands used. The database engine module 17 arranges records for each field or for each keyword in the field.

Communication primitives are well-defined commands that represent the minimum functionality required for communication. For example,
The function of receiving one single byte <1 byte 0> from the communication port is that if 1 byte is 1 for a particular processor,
If it is a word, it can be classified as a primitive. The <1 byte 0> command would need to be called 10 times to receive 10 bytes.

The collection of communication primitives interprets information received from communication lines and performs appropriate actions. These actions can include ingesting or writing data to the target system 30.

The communication primitive set is sent to the target system 3
The code set at 0 is held separately from the application firmware 35. The number of primitives is
It is kept to a minimum so as not to unduly interfere with the performance of processor 34 on target system 30. Also, the complexity of each of the primitives is minimized so that they are easily installed and do not prevent the processor 34 from running too many cycles.

The host processor 11 generates a <service request> signal to the target processor 34 whenever a service is required. The target processor 34 detects and interprets the request sent from the host processor 11,
You need to have the means to service. The means for detecting the request signal depends on the configuration of the selected firmware 34. The selected mechanism must not introduce interference into the target system being monitored.

The request line from the host processor 11 is thus connected to the interrupt pin of the target processor 34, so that an interrupt signal can be generated whenever there is a request from the host processor 11. The priority of the interrupt assigned to the incoming request needs to be selected so that reasonable service can be obtained from the host processor 34.

Alternatively, a polling strategy can be used, whereby the target processor 34 actively and periodically polls the state of the pin connected to the request line. The configuration of the firmware determines how polling of requests and services are performed. The firmware is organized into a number of sub-modules with a main control module that calls each sub-module in turn.
In such a case, the polling and service functions can be installed as one of the sub-modules called by the main module. Target processor 34
The upper firmware 35 can be organized into tasks that can be triggered sequentially or when other wake-up conditions are satisfied with respect to the timer source. The polling operation for the request signal can be set up as a single task that is periodically triggered by the scheduler.

The communication protocol for the arrangement of FIG. 1 defines a standard that the target system 30 and the host monitor system 10 must adhere to in exchanging information. It is important to note that in a given application, the ports of the target processor 34 can be almost fully utilized. There must not be many available ports communicating with the host monitor system 10. If the monitored target system 30 is a real-time system with stringent timing requirements, the host monitor system 10 must not affect the capabilities of the target processor 34 to meet its timing requirements.

When all of the communication ports of the target processor 34 are being used by subsystems external to it, it is necessary to multiplex these communication ports. This is shown in FIG. 2 and will be described in detail later in this specification. Using this method, additional control lines can be used to customize the assignment of communication lines.

With the help of the control line, the target system 30
Can detect the moment when the host monitor system 10 requests a service. The goal system 34
If there is a request from the own subsystem, the service of the monitor system 10 can be selected to be postponed. This ensures that any requests from its external subsystems will be serviced with minimal or no delay. Conversely, the monitoring system 10 can also detect service requests from the target system 30. In response, the monitoring system relinquishes the communication line so that the target processor 34 can engage in communicating with its external subsystem.

The target processor 34 and the monitor system 10
The data transfer between and can be performed in either a serial form or a simultaneous form. For serial transfer, a synchronous transmission mechanism is preferred. This is because such a mechanism can be applied to a wider selection of processors than an asynchronous mechanism.
In a synchronization scheme, a bit clock is sent along with the bit stream, and the receiver latches the data as it arrives. Parallel transfer of data is required to allow the language clock to latch in the language of the data.

A number of possible configurations exist for establishing a communication protocol. The choice of configuration depends on the number of available ports, the level of error immunity and the required recovery, and the presence of external subsystems attached to the target processor system 30.

Further, the monitor system 10 is used together with a device (not shown) for analyzing input / output signals of the target processor 34. The signal analyzer also captures the logic level at the target processor 34 and sends an indication of the level to the host monitor system 10. The analyzer may also send appropriate signals to the target processor 34. Thus, the response of target processor 34 can be monitored from its output pin. The use of such a device in conjunction with the monitor system 10 allows a user to access information on pins within and outside the embedded processor.
The integrated test and diagnostic subsystem has the ability to access data from both the RAM and registers and pins of the target processor 34.

FIG. 3 is a diagram showing an outline of the general-purpose emulator device 80. The system 80 includes a standardized user interface 90, a processor resource data warehouse module 89, a test database engine module 88, an automatic tester module 87, a general purpose emulator software module 86, a general purpose emulator hardware module 83, a general purpose remote processor pod module 85, It comprises a host processor 81 and a host bus 82 interconnecting the modules and the host processor 81.

[0045] The standardized user module 90 provides the user with an emulator and target processor system 30.
Allow to communicate with. Unlike conventional emulators, the user can view the contents of the memory and registers of the target processor all in real time while the processor is executing. In addition, various bug removal tools are available such as setting breakpoints in code and trace functions. Regardless of the processor 34, monitoring and usage of the interface remains the same. No lead time is needed to adapt itself to the new environment in the case of the new emulator. The user interface 90 sends and receives commands 98 and data 99 through a general-purpose emulator software engine module 86.

The type of target processor 34 is selected from the processor data repository module 89 to initialize and configure the emulator device 80. This module contains processor categories, input / output pin arrangements, packaging types, register and memory maps, unique resources that exist inside the processor, and other definitions to completely define the processor. This module also has facilities for adding, editing, searching and deleting information about the processor.

Test database engine module 8
8 tabulates the response of the target system 30 to commands issued by the automatic tester module 87.
Database 88 also stores the different test sequences required to verify the functionality of a particular application. The database record can contain: Application type, processor type, test type, test material, and
This is a list of commands used.

The test database engine 88 aligns records for each field or for each keyword in the field. The automatic tester module 87 obtains the command sequence set from the general-purpose emulator software engine module 88. These commands are sequentially issued to the general-purpose emulator software engine module 86 as a test sequence 93. The response of the target system to the command stream is returned to the automatic tester module 87 as a series of test results 94.

The ability to handle various processors is enabled by having a general purpose emulator software engine 86. This is central to the entire emulator device and derives its operation settings and modes from information retrieved from the data repository module 89 of the processor. Commands 98 from the user interface module 90 are returned to the engine 86 for processing. The received command 98, along with the previously selected processor type, is translated into a predetermined format before being issued as an output bit stream 91 to the general-purpose emulator hardware module 83. Conversely, the input bit stream data 92 obtained from the hardware module 83
Is decoded according to the format of the processor and the data line 9
9 to the user interface module 90.

The general-purpose emulator hardware module 83 coordinates between the software engine 86 and the remote processor pod 85. A communication strategy is used that allows very high speed data transfer between communication lines 84 to allow the contents of registers and memory to be viewed in real time.

The package and the pin arrangement of the processor are as follows.
Varies by processor group and manufacturer. A typical remote processor pod 85 has an adapter that contains a package and pin configuration that identifies each processor.

Returning to FIG. 1, a particular embodiment of the arrangement shown here in which the targeting system 30 is formed by a consumer product such as a CD radio cassette player can be described. The host monitor system 10 is typically on a personal computer, and the host processor 11 represents a control processor of the personal computer that coordinates and controls all the different modules that make up the host monitor system 10.

The database engine module 17
Arm wear development of CD radio cassette player
Performs all functions necessary to document any program flaws detected during the testing process. Repair and test sequences that verify the absence of each fault are all stored in a database. A search engine is included to allow the retrieval of information regarding the shortcomings of a particular program using keywords.

The automatic tester module 16 generates a command sequence to the CD radio cassette player without the need for human intervention and obtains its input from a script file. Each script file employs special tests to ensure certain functions of the CD radio cassette player. This module is used heavily for firmware verification tests involving events that depend on the player's real-time clock and sends any test results to a database module.

The monitor module 15 receives the test sequence 24 from the automatic tester module 16 or the user command 28 from the user interface 18 and based on the previously selected CD radio cassette player specification, the communication primitive module 14 Generates a specific command 22 to the application. Conversely, a response from the player obtained via the communication primitive module 14 is sent to the user interface 18 as an automatic tester module 16 and a monitor response 29 as a test result.

Detailed information on the different microcontrollers and their memory maps that can be used in a CD radio cassette player can be found in the target system specification repository 19.
Is stored in Prior to testing, a special microprocessor model is selected. Data on the use of the special microcontroller and its memory is provided on monitor 15
And sent to the automatic tester module 16. This method uses the same user command and test sequence 24
To be used across different microprocessors on a CD radio cassette player.

The user interface 18 is fully equipped with a graphical user interface (GUI) used to generate multiple data views to display the contents of the player's memory registers.
The contents are changed simply by changing the data displayed in various fields of view. A script file viewer and editor also exist to be integrated to form a monitor interface. There are also additional views showing the time and data status of the player. The database engine module 17 is completely contained within the user interface. Any commands entered by the user are directed to the monitor module 15.

The communication primitive module 14 obtains commands from the monitor module and translates them into well-defined communication primitives. The set of primitives is transferred to the hardware interface in the form of an output bit stream. The communication primitive module receives the input bit stream 21 from the CD radio cassette player via the hardware interface, interprets the received information and sends it to the monitor module.

The hardware interface 13 is installed using a printed circuit card inserted in an expansion slot of a personal computer. Communication between the card and the communication module is performed using hardware interrupts. This card contains circuitry for generating and receiving signals from the hardware interface 32 of the CD radio cassette player. Input / output registers are used to buffer the transfer of data between the personal computer and the player.

FIG. 2 shows the host computer system 10.
Communication line 3 between CD radio cassette player
FIG. 9 is a diagram showing 9 in detail. Coordination and control of all processes in the player are performed by the target processor module 34.
Is handled by the microprocessor of the hardware of the CD radio cassette player represented by. The player design allows for different models of microprocessors to be used. Changing the microprocessor will require that new information be selected for use in the target system specification repository 19.

Various devices residing on a CD radio cassette player, namely a CD player, a tuner, a display, and a real-time clock are depicted by reference numerals. These devices are controlled by a microprocessor. The processor firmware 35 sends an operation command to the microprocessor. The communication primitive module 33 obtains commands from the host 10 in the form of a bit stream 38 via the hardware interface 32 of the player. This module interprets the received information and directs it via the bus 31 to the microcontroller 34 in the form of commands. Information and data from the microcontroller 34 for the host monitor system 10
The communication primitives are sent to the module 33 for translation and then form the output bit stream.

The hardware interface 32 of the CD radio cassette player functions as a connection and buffer between the communication link 39 and the microcontroller 34.

FIG. 2 shows how the communication, arbitration and interrupt lines are connected between the host monitor system 10, the CD radio cassette player microcontroller 50 (34), and the player CDLSI module 51. . The CD LSI module 51 is sometimes
The subcode data 58 is sent to the microcontroller 50, and the serial data line 5
4 and the serial clock line 54 are used.

The arbitration and request line 52 is used to determine the direction of data flow between the host monitor system 10 and the player. In addition, line 52 also serves as a means for indicating a service request to target microcontroller 50. A party indicating a certain logic level in the arbitration line 52 notifies other parties that there is data to send. Whenever the microcontroller 50 intends to send data to the host system 10, a check is made to see if the arbitration line 52 is clearly shown. If line 52 has not been previously identified by host system 10, line 52 is asserted and clock 55 and a series of data 53 are sent to host system 50. The signal level on the arbitration line 52 is also used to control a switch 56 that enables or disables communication between the CD LSI module 51 and the microcontroller.

The serial data line 53 carries the bit stream from the player's microcontroller to the host monitor system 10. Serial data line 54
Is provided to convey command and data bit streams from the host monitor system 10 to the player's microcontroller and CD subcode data from the CDLSI module 51. The check signal on serial clock line 55 is used for synchronous communication and is always generated by the player's microcontroller. The use of line 55 is shared between microcontroller 50 and CDLSI module 51. The microcontroller 50 is connected to the host system 10
Is notified that it is about to transmit data, it generates a clock signal on serial clock line 55 to retrieve information from host 10. During this time, the connection between the CD LSI module 51 and the microcontroller 50 must be disabled.

The interrupt request line 59 is provided as shown, and its signal is generated from the CDLSI module 51. When the CDLSI module 51 requests a service from the microcontroller 50, an interrupt request signal is generated. A special interrupt request line 59 is also connected to the host monitor system 10 so that the CD
The LSI module 51 is connected to the serial data lines 54 and 5
Inform that you are about to occupy 5 uses. If the host monitor system 10 is in the process of transmitting or receiving, the current word of information before releasing the use of line 54 to allow serial communication between the microcontroller 50 and the CD LSI module 51 to occur. First, the transmission or reception of is completed. CDLSI module 5
As soon as an interrupt is received from the microcontroller 50, the microcontroller 50 completes execution of the current command before generating a clock signal for collecting data from the CDLSI module 51. After executing the interrupt service routine, the microcontroller 50
Prior to the interruption to 0, a signal is written on the arbitration line 52 to notify that the previous operation can be resumed.

The switch 56 is voltage-controlled, and the CDLS
It is used to enable or disable the connection of the I-module 51 to the communication link 59. When the switch 56 is open, the serial clock 57 and the subcode data outline 58 of the CD LSI module 51 are disconnected. The communication can be regarded as the host system 10. When the switch 56 is closed, the host system 10 disables the communication module, and exchange of data between the CD LSI module 51 and the microcontroller 50 becomes possible.

The embodiment described above is applied to FIG.
The host processor 81 indicates that adjustment and control of all modules constituting the emulator are performed inside a personal computer in which a general-purpose emulator device exists.

The test base engine 88 documents the shortcomings of the program detected during the development and testing of the firmware. The solutions and test sequences needed to verify the absence of each fault are also stored in a database. Search engines are embedded to allow the retrieval of information about the shortcomings of a particular program through the use of keywords.

The automated testing of the firmware is accomplished using an automated tester module 87. Module 87 generates a series of commands 93 to target processor 50 without the need for human intervention. This module extracts input from a script file. Each script file performs special tests to verify certain features of the firmware. This module is heavily used for firmware testing involving events that depend on the real-time clock. Any test results are sent to the database engine 88.

The general-purpose emulator software engine module 86 forms the center of the general emulator device 80 and receives its input from both the user interface in the form of user commands and from the processor resource data warehouse module 89 in the form of processor definitions. Pull out. Module 86 processes the two sets of data by mapping user commands for resources within selected processor 50. These processed commands are sent to the hardware interface 83
Sent to Similarly, the hardware interface 8
3 is decrypted and transferred to the user interface module 90. This method allows the emulator to provide the flexibility to allow the emulator to target a wide variety of processors. A series of commands 93 are issued from the automatic tester module 87 to the software engine 86. The commands 93 are handled in the same manner as the individual commands received from the user interface module 90.

Information that fully defines the internal resources and characteristics of the various target processors 30 that can be used is stored in a processor resource data warehouse module 89 that has facilities for adding, editing, searching, and retrieving data. The user initializes the hardware and software of the emulator 80 by selecting the appropriate type of processor from the repository. The recovered information is sent to the universal emulator software engine 86 to allow the translation of commands and memory maps according to the processor selected for the generic emulator software engine 86. Further, the data is used to configure a universal remote processor pod module 85.

User interface module 90
Is implemented as a graphical user interface (GUI). Multiple windows and data views are used to display various memory segments and registers in real time. Data for the different fields of view is obtained from the universal emulator software engine module 86. The contents of the memory can be changed by directly changing the data displayed in the field of view.
These changes are sent to the general purpose emulator software engine module 86 as user commands. User interface 90 also implements code trace, branch and breakpoint features. The choice of processor type can be made from within the user interface.

The hardware interface 83 is implemented entirely by a printed circuit card that is inserted into an expansion slot of a personal computer and allows high-speed data exchange with a general purpose remote processor pod module 85. The communication protocol used features detection and correction of data errors for reliable operation. Communication with the general-purpose remote processor pod module 85 is performed using hardware interrupts. Registers are used to buffer incoming and outgoing data. The communication link 84 between the hardware interface 83 and the universal remote processor pod module 85 is designed to handle the bandwidth of the most demanding processors available.

General Purpose Remote Processor Pod Module 85
Is generally inserted into the processor socket of the target system 30. Its ability to accommodate a wide variety of processors is made possible by the use of hardware adapter choices according to the different packages and pin requirements of the various processors.

FIG. 4 is a flowchart of a real-time operation system formed for the real-time operation system scheduler 120. The various firmware segments are grouped according to the particular application function to which they belong. Furware is
Thus, the code groups (122, 124, 126, 1)
28, 130). Processor 34 takes care of many application functions, using a time division strategy to cycle through different groups. When the processor 34 approaches one group and finds that service is not required, it proceeds in turn to take care of the next group. Thus, the frequency with which a group of group codes is serviced depends on the total number of groups that the processor 34 must cycle through. Solving software with too many groups causes application unresponsiveness because the average latency of the service increases. A compromise must be made to allow an optimal number of program groups with given timing constraints. This approach to firmware design allows the generation of real-time monitors with minimal disruption to existing application programs.

Host processor 11 and target processor 3
Communication between the four is performed by a communication software group 122 including a routine for detecting and interpreting a <service request> signal from the host processor 11. Other routines that read and modify the memory register area of the processor fall into this group. CD player software group 124 contains routines that perform any necessary CD player functions.

The software routines required to implement the tuner function are included in tuner software group 126.

The operation of the cassette player is managed by a program in the cassette player software group 128.

The program that handles the display of the CD radio cassette player is the display software group 130
Represented by

The previous method of enabling firmware was tedious and time consuming, especially for events related to real-time clocks. With the ability to remotely read and write target processor registers and memory manually or automatically through the use of script file commands, the currently disclosed systems are required to test firmware or verify special firmware changes. Time is significantly reduced. With the use of standardized communication primitives, the same monitor system can be applied to a wide variety of processors as long as the primitives are implemented in the processor's firmware. This causes a faster development of the firmware development.

The use of the general purpose emulator device of the preferred embodiment results in improved cost efficiency by eliminating the need to obtain a conventional processor-specific emulator collection. Productivity is also achieved by using standardized interfaces rather than adapting to different interfaces used by different emulators.

Standardization of variable arrays and label names across processors for similar classes of applications reduces the tedium of understanding a new set of code for the same application. The lead time required from use of one processor to use of another processor in one particular implementation is reduced by this strategy.

The foregoing description describes only some embodiments of the invention, and modifications obvious to those skilled in the art may be added thereto without departing from the spirit and scope of the invention.

[0085]

According to the real-time monitor for testing and removing bugs in the firmware of the embedded processor system of the present invention, the contents of the memory and the register can be accessed and changed in real time regardless of the difference between the target processors.

In a standardized development method of a communication primitive for allowing testing of one of a plurality of target subsystems, each having a different control processor, with the use of a host monitor system according to the present invention, the control line is assigned a communication line assignment. Can be made optional.

In a general purpose in-circuit emulator for developing and testing one of a plurality of target systems, each of which has a control target processor, the target systems of the present invention can target different groups of pro sensors and operate the processors. The memory can be changed in real time even during the operation.

[Brief description of the drawings]

FIG. 1 is a block diagram illustrating various functional modules in a host and target system according to one embodiment of the present invention and showing how they interact.

FIG. 2 is a schematic block diagram illustrating the common use of communication and control lines between a host, target and external devices in a particular system.

FIG. 3 is a schematic block diagram depicting the operation between various functional modules of the general purpose emulator of the preferred embodiment.

FIG. 4 is a schematic flowchart of a real-time operation system of a target processor.

[Explanation of symbols]

 DESCRIPTION OF SYMBOLS 10 ... Host monitor system 11 ... Host processor 12 ... Host bus 13 ... Hardware interface 14 ... Communication primitive module 15 ... Monitor module 16 ... Automatic test module 17 ... Database engine module 18 ... User command interface module 19 ... Target system use storage part DESCRIPTION OF SYMBOLS 30 ... Target system 34 ... Target processor 35 ... Processor firmware 36 ... System hardware 39 ... Communication line 80 ... General purpose emulator 81 ... Host processor 82 ... Host bus 83 ... General purpose emulator hardware module 85 ... General purpose remote processor pod module 86 ... General-purpose emulator software module 87 ... Automatic tester module 88 ... Test database engine module Module 89: Processor resource data warehouse module 90: user interface

 ──────────────────────────────────────────────────続 き Continuing on the front page (72) Inventor Satoshi Endo Singapore 469332 Singapore, Bedok South Avenue 1, No. 202 Matsu Matsu Electronics (S) Private Limited (72) Inventor Kum Yuen・ Yan Singapore 798725 Singapore, Loron Tangham 24th (72) Inventor Tuse Tsung Theo Singapore 640542 Singapore, Number 01-1070, Jurong West Avenue 1st Block 543

Claims (26)

[Claims] 1. A real-time monitor for testing and removing bugs in firmware in an embedded processor-based system, comprising: a host computer subsystem; a target subsystem representing the embedded processor subsystem; and a host computer subsystem and a target subsystem. A communication link subsystem for monitoring the target subsystem in real time, and a monitor subsystem existing on a host computer subsystem for an operation of retaining the monitoring result. 2. The monitor of claim 1, wherein the host computer subsystem comprises a host processor interconnected with a user command console through which user commands are input to said host subsystem. Monitor device. 3. The monitoring device according to claim 1, wherein said target subsystem comprises an embedded target subsystem and a peripheral device external to said target processor, and is controlled by said target processor. Monitor device. 4. The monitoring device according to claim 1, wherein said communication link subsystem interconnects data, clock and control lines interconnecting said host and target subsystems, and data between said host and target subsystems. And a communication protocol for establishing a transfer of control, and a set of communication primitives in the target subsystem. 5. The monitoring device of claim 4, wherein said communication line serves as a minimum and sufficient number of links through which data and control signals are exchanged between said host target subsystems. Characteristic monitor device. 6. The monitoring device according to claim 4, wherein the communication protocol is a command that the host and the target subsystem must adhere to in exchanging information.
A monitoring device characterized in that the data, arbitration and control signals are in a predetermined or standardized form. 7. The monitoring device according to claim 6, wherein the set of communication primitives present in the host subsystem interprets signals on signal lines and handles reception and transmission of commands and data according to the protocol. Characteristic monitor device. 8. The monitoring device according to claim 6, wherein said set of communication primitives present in the target subsystem interprets signals on signal lines and handles the reception and transmission of commands and data according to said protocol. Characteristic monitor device. 9. The monitoring device according to claim 6, wherein said monitoring subsystem includes at least a user interface subsystem, a target memory monitoring subsystem, an automatic tester subsystem, and a database subsystem. Monitor device. 10. The monitor device according to claim 9, wherein the monitor subsystem receives an input from a user and displays a current status and data of an operation state from a target subsystem. 11. The monitoring device according to claim 9, wherein the target memory monitoring subsystem allows a user to change a memory area of the target subsystem. 12. The monitoring device according to claim 9, wherein the user of the automatic tester subsystem is notified without user intervention and reporting of the results of the test and any errors or exclusions identified therein. A monitoring device, which allows a test sequence or a pre-program for automatic testing of a target subsystem. 13. The monitoring device according to claim 9, wherein in the database subsystem, the database subsystem documents the abnormality together with its cause and remedy. 14. The monitoring device according to claim 1, further comprising a device for monitoring an external input / output signal of the target processor to achieve an analysis of a target subsystem operation. . 15. A method of standardized development of communication primitives for allowing testing of one of a plurality of target subsystems, each having a different control processor, using a host monitor system, the method comprising: (a) providing the target subsystem; Means for standardizing the variable names in each application field and retaining some in the host monitor system; and (b) for each of the different control processors and the control host processor of the host monitor system and A method of development comprising means for standardizing communication primitives between them and holding them inside said host monitor. 16. The method of development according to claim 15, wherein the understanding of the variable names is of a similar type, such that given variable names are always synonymous, even if the internal installation or address location is different. A development method characterized by giving similar names to items of use and functions. 17. The method of development according to claim 15, wherein the understanding of the communication primitives results in similar functions even if the primitives are implemented differently across the different processors to achieve the same functionality. A method of development characterized by using similar names. 18. A general-purpose in-circuit emulator for developing and testing one of a plurality of target systems, each of said target systems having a control target processor, comprising: a user interface subsystem; a processor resource data warehouse subsystem; An emulator device in a general-purpose circuit, comprising: a test database engine subsystem; a general-purpose emulator software air engine subsystem; a general-purpose emulator hardware subsystem; and a general-purpose remote processor pod subsystem. 19. The general in-circuit emulator of claim 18, wherein the user interface subsystem displays the contents of registers and memory resources of the target processor in real time while the target processor is executing. A general-purpose in-circuit emulator device, which permits issuing of system commands and corrections. 20. The emulator apparatus of claim 18, wherein the standardized user interface subsystem is configured to update the contents of registers and memory resources of the target processor in real time while the target processor is executing. A general purpose in-circuit emulator device characterized in that it is displayed in time and its appearance and practices remain the same regardless of the type of processor used. 21. The emulator apparatus of claim 18, wherein said processor resource data warehouse subsystem has sufficient facilities to add, edit, search, and delete any data relating to a target processor. A general purpose in-circuit emulator device characterized in that it contains all the information necessary to fully define a particular one of the target processors. 22. The general-purpose in-circuit emulator according to claim 18, wherein the database subsystem documents the abnormality of the target system together with its possible causes and remedies. 23. The in-circuit emulator of claim 18, wherein the automatic tester subsystem pre-configures the user with a test sequence or test case that can be used for automated testing of the target subsystem without user intervention. Emulator device, which allows the user to program the device and then report the test results, any errors or exclusions. 24. The emulator device of claim 18, wherein the general purpose emulator software engine subsystem includes the flexibility to configure itself to handle a wide variety of target processors. A general-purpose in-circuit emulator device characterized by providing all necessary functions and logics for execution. 25. The emulator device according to claim 21, wherein the general-purpose emulator hardware subsystem is capable of high-speed data transfer and error correction necessary for viewing the contents of registers and memories in real time. A general-purpose in-circuit emulator device, wherein the general-purpose emulator software subsystem is adjusted to perform the above-mentioned operations. 26. The general in-circuit emulator of claim 18, wherein the general-purpose remote processor pod is used across a wide variety of target processors by having adapters to accommodate different packages and pin configurations of the target processor. A general-purpose in-circuit emulator device having the ability to