KR100600992B1 - Apparatus and method for logging history of mobile communication terminal - Google Patents

Abstract

The present invention relates to a history recording apparatus and method of a mobile communication terminal for recording a state variable history to track a cause of a problem occurring in a mobile communication terminal. A history updating unit which stores history data in RAM; An exception processing unit which is called by the application unit where an exception situation has occurred and processes the exception situation occurring in the application; A history log unit which is called by the exception processing unit and dumps the historical data recorded in the RAM to a nonvolatile memory; And a device driver for recording the historical data, which is called by the history log section and dumped to the nonvolatile memory, to the nonvolatile memory.

History, state variables, events, microprocessors, exception handlers

Description

Apparatus and method for recording history of mobile terminal {APPARATUS AND METHOD FOR LOGGING HISTORY OF MOBILE COMMUNICATION TERMINAL}             

1 is a view showing the configuration of a mobile communication terminal having a history recording apparatus according to an embodiment of the present invention by way of example.

2 is a flowchart illustrating a history recording method of a mobile communication terminal according to an embodiment of the present invention.

*** Explanation of symbols for the main parts of the drawing ***

10.SRAM, 20.Flash memory,

30. Application unit, 40. History update unit,

50. Exception handling section, 60. History logging section,

70. Device Drive

The present invention relates to a history recording apparatus and method for a mobile communication terminal, and more particularly, to a history recording apparatus and method for recording a state variable history to track the cause of a problem occurring in the mobile communication terminal. .

In a mass-produced embedded system such as a mobile communication terminal, a problem is discovered in the process of being used by a terminal user for an unexpected reason by a software developer. However, embedded systems used by large terminal users cannot monitor the operating status of the software in a centralized manner for various reasons.

Accordingly, a problem is found in the field, and there is a problem in that the analysis of the problem is not easy until the terminal is recovered to the service center because the terminal cannot be continuously used due to the found problem.

Among the problems found, the problem is simply reproduced, and the problem is reproduced by the terminal manufacturer, and the problem can be solved relatively easily. However, the problem is only confirmed as a result. It's often difficult to know what went wrong.

As described above, even if the resulting problem is confirmed, it is difficult to determine the cause of the problem because the found problem does not appear in a short time, but is accumulated through a use process for a certain length of time.

On the other hand, problems can appear in hundreds or thousands of ways, and the countermeasures are often difficult to cope with in several ways, but the microprocessors and the corresponding software constituting the terminal are the result of some minimal problems. It often comes down. One of them is the exception occurrence of the microprocessor and the execution result of the exception handler which is a software routine for handling the exception.

For example, a terminal is often designed to call an exception handler to handle a data interruption exception due to an invalid operation, output a data abort message from the exception handler, and stop the operation.

The present invention has been made to solve the above-described problem, by storing information in the non-volatile memory that can find the cause of the problem in the exception processing unit is called in accordance with the exception occurs, the situation can not be observed by the developer It is an object of the present invention to provide a history recording apparatus and a method of a mobile communication terminal to obtain a series of data for tracking the path of a problem.

According to an aspect of the present invention, there is provided a history recording apparatus of a mobile communication terminal, comprising: a history updating unit for storing history data generated according to a state change / event occurrence of an application unit in a normal operation; An exception processing unit which is called by the application unit in which an exception situation has occurred and processes the exception situation occurring in the application; A history log unit which is called by the exception processing unit and dumps the historical data recorded in the RAM to a nonvolatile memory; And a device driver for recording the historical data, which is called by the history log section and dumped to the nonvolatile memory, to the nonvolatile memory.

On the other hand, the history recording method of the mobile communication terminal according to an embodiment of the present invention, the process for defining the element necessary for problem analysis to any one of the state variable set ( S ) and the event set ( E ); Defining a subset (S, E) by selecting only the minimum elements necessary for problem tracking among the elements of the state variable set ( S ) and the event set ( E ); Updating the history (H _i ) for the elements in RAM according to the change of the elements constituting the defined subset (S, E); If an exception occurs while updating the history of the elements, the historical data (H = {H ₁ , H ₂ ,..., H _n }) stored in the RAM is stored in the nonvolatile memory until the exception occurs. It is preferable to include a process of dumping and storing.

Further, the history (H _i) is preferably made of the index i, the state change has occurred or not value, an event occurs, the changed status.

The history updating process may include determining whether there is a state change when an event e _i occurs; And then, if it is determined that the state change and reflect the modified state values for the state variable (s _i), set to a true (True) the values (b _i) that indicates the state change has occurred or not, a history of (H _i) in the RAM Updating; If it is determined that the state change, the state variable (s _i) to set to zero, and set to a value (b _i) a false (False) indicating a status change has occurred and then, updates the history (H _i) in the RAM Making a step; Determining if there is an additional state change, if there is an additional state change, increase the index (i) by 1, set the occurrence event variable (e _i ) to 0, and reflect the changed state value in the state variable (s _i ). Setting a value (b _i ) indicating whether or not a state change has occurred to True, and then updating the history (H _i ) to the RAM; If there is no additional state change as a result of the determination, the index i may be increased by one and waiting for the next event to occur.

Hereinafter, a history recording apparatus and method of a mobile communication terminal according to a preferred embodiment of the present invention will be described in detail with reference to the accompanying drawings.

1 illustrates a road, an SRAM 10, a flash memory 20, an application unit 30, and a history updater showing an exemplary configuration of a mobile communication terminal including a history recording device according to an embodiment of the present invention. 40), an exception processing section 50, a history log section 60, and a device driver 70.

In such a configuration, the SRAM 10 temporarily stores history data generated by a state change or an event occurrence in the application unit 30 that is operating normally, and the size of the RAM area in which the history data is stored is determined by the terminal. It depends on the total amount of RAM in hardware and the complexity of the software. Here, since the RAM area in which the history data is stored is limited, when all the data is recorded in the area allocated as the history data storage area, the oldest data is deleted and the new data is stored. It can be updated in such a way that it is updated like a queue.

The flash memory 20 stores historical data dumped from the SRAM 10 in a predetermined area in response to occurrence of an exception in the application unit 30.

As described above, instead of storing the historical data generated in the application unit 30 in the flash memory 20 from the beginning, the data is first stored in the SRAM 10 and dumped to the flash memory 20 when an exception occurs. The reason for storing is to prevent the history record from burdening the operation of the terminal software.

On the other hand, the application unit 30 stores the history data in the SRAM 10 through the history update unit 40 when a state change or an event occurs during normal operation, and if an exception occurs, calls the exception processing unit 50. Done.

The history updater 40 stores history data in the SRAM 10 when a state change or an event occurs in the application unit 30 that is operating normally.

The exception processing unit 50 is called by the application unit 30 in which the exception situation has occurred, processes the exception situation generated in the application unit 30, calls the history log unit 60, and the SRAM until just before the exception occurs. The history data recorded in (10) is dumped to the flash memory 20.

The history log unit 60 is called by the exception processing unit 50 to dump the history data stored in the SRAM 10 to the flash memory 20.

The device driver 70 is called by the history log unit 60 to store the history data dumped from the SRAM 10 in the flash memory 20.

The reason for using the low level device driver 70 in the present invention is as follows.

In general, when the software operates normally in the terminal, a file system is used to store data in the flash memory 20 which is a nonvolatile memory. However, when an exception occurs, the software execution itself becomes unreliable. For example, complex software such as file systems cannot be guaranteed to work properly. Accordingly, the history data should be stored in the flash memory 20 in a manner that does not depend on whether the software is normally operated.

Meanwhile, a flash memory that is widely used as a nonvolatile storage device in a mobile communication terminal can write specific data at a predetermined address in a relatively simple manner. Therefore, in the present invention, the device driver 70 is used to operate the flash memory 20 in a simple manner.

Hereinafter, a history recording method of a mobile communication terminal according to an embodiment of the present invention will be described.

First of all, prior to the description of the present invention, in the case of mobile communication terminal software using a microprocessor, if a microprocessor level execution error is detected due to an error in the software or an instability of the electrical signal of the hardware, an exception occurs. If it occurs, it branches to the exception handler located at the predefined address.

Accordingly, an exception processor address branched at each exception occurrence is stored in the exception vector table of the microprocessor.

On the other hand, the elements necessary for developers to reproduce and analyze the problem is not easy to unify in a simple form, the present invention defines the elements necessary to configure the terminal and analyze the problem in the following two ways. This can be changed in the aspect of the problem and the introduction of new technology, but whatever is introduced does not affect the gist of the present invention.

S : Full set of software state variables of mobile communication terminal

For example, the location of the UI (User Interface) application, the number of stored pictures, the channel currently being served, etc.

E : whole set of events occurring in the mobile communication terminal or authorized externally

For example, key press events, incoming calls, SMS received, etc.

Where S ∩ E = Ø

Here, S and E are sets that include all state variables and events that can configure the software of the terminal, and state that the state of the terminal software cannot be described using an element that does not belong to this set.

As mentioned earlier, S and E are a complete set that includes all the state variables and events that can configure the terminal's software, so using all the elements belonging to S and E to track problems is too many. There are too many realistic constraints because of the sheer volume.

Accordingly, in the present invention, a process of finding a minimum subset from S and E required for problem tracking is required.

That is, we define the subsets S and E and the elements s and e belonging to each subset as follows.

S⊂ S , E⊂ E

s _i ∈S, i = 1, 2,... , n

e _i ∈ @, i = 1, 2,... , m

For example, if a camera is mounted and other functions are the same terminal as a general terminal, S and E can be defined as follows.

S = {UI application ID, number of saved photos, number of saved SMS, remaining memory space (Kbytes), channel number currently being serviced, number of downloaded applications, caller ID data, caller ID, etc.}

E = {key1, key2,... , Send key, End key, Incoming Call, Outgoing Call, SMS Receive, Alarm Fire, etc.}

As described above, the history H is stored in the SRAM 10 according to the change of the elements belonging to the determined subset S and the subset E, and the history H stored in the SRAM 10 is changed to individual s. _i , e _i , s _i is stored whenever the status changes, and e _i is stored whenever an event occurs.

If you use a microprocessor that supports Memory Management Unit (MMU), Memory Protection, etc., because the RAM area is invaded when an exception occurs due to an error, the RAM area may be monitored. It's a good idea to only allow access with Mode) privileges. Accordingly, the application process invocation (API) used by the application unit 30 to record the history data in the SRAM 10 should be able to be executed in the monitoring mode.

As described above, the history H is stored in the SRAM 10 according to the change of the elements belonging to the subset S and the subset E, and the history H stored in the SRAM 10 is defined as follows. .

H = {e _i , s _j }

Where index changed from i = 1 to n, index changed from j = 1 to m

However, since the change of the state is not more frequent than the occurrence of the event, the history H is configured as follows to distinguish the state from the event.

H _i = {index i, presence or absence of state change (boolean value), occurrence event, [change state value]}

Where H _i ∈ H, i = 1, 2,... , k (k is the total number of history stored in SRAM)

As described above, an exception occurs in the application unit 30 while the application unit 30 calls the history update unit 40 to update the history data generated by the history update unit 40 each time an element is changed. When generated, the historical data stored in the SRAM 10 is stored in the flash memory 20 which is a nonvolatile memory.

2 is a flowchart illustrating a history recording method of a mobile communication terminal according to an embodiment of the present invention.

First, when the event e _i occurs in the application unit 30 (S10), the history updater 40 determines whether there is a state change (S12), and if there is a state change, the state variable _si is selected. The state value is set to the changed state, and a boolean value b _i indicating whether a state change occurs is set to true (S14).

On the other hand, if there is no changed state value as a result of the determination of step S12, the state variable s _i is set to 0, and a boolean value b _i indicating whether or not a state change occurs is set to False. (S16).

Thereafter, the history (H _i = i, b _i , e _i , s _i ) obtained through the above-described process S14 or process S16 is updated in the SRAM 10 (S18), and it is determined whether there is an additional state change ( S20).

In the case where there is an additional state change as a result of the determination of step S20, the index i is increased by 1, and since there is no new event e _i , the occurrence event e _i is set to 0 (S22). In step S14, the changed state value is reflected in the state variable s _i , and a boolean value b _i indicating whether a state change occurs is set to true.

On the other hand, if there is no additional state change as a result of the determination of the step S20, the index (i) is increased by one (S24), the process proceeds to the above step S10 and waits for the next event (e _i ) generation.

If an exception occurs in the application unit 30 while updating the history data in the SRAM 10 by repeatedly performing the above steps S10 to S24 (S26), the application unit 30 in which the exception occurred has occurred. Dump the history data (H = {H ₁ , H ₂ ,..., H _n }) recorded in the SRAM 10 to the flash memory 20 until an exception occurs in the called history log unit 60 ( In operation S28, the device driver 70 is called to store historical data dumped into the flash memory 20 in the flash memory 20 (S30).

As described above, the history data H stored in the flash memory 20 may be output later through a J-TAG or a specially manufactured tool. For example, a history analysis tool that can be run on a PC can change the historical data into easy-to-understand information, which allows the developer to know the history of the terminal that caused the problem, thereby identifying the cause of the problem. You can do it.

The history recording apparatus and method of the mobile communication terminal of the present invention are not limited to the above-described embodiments, and can be modified in various ways within the scope of the technical idea of the present invention.

According to the history recording apparatus and method of the mobile communication terminal of the present invention as described above, when an exception occurs when the history data generated during normal operation is updated in RAM, an exception processing unit, which is given control, is stored in RAM. By dumping data into non-volatile memory and storing it, you get a set of data that allows you to track the path of problems that occur in situations that developers cannot observe. As a result, it is possible to identify and take countermeasures to the problems found in a shorter time, and to reduce the waste of human resources or time for problem tracking.

Claims (4)

A history updating unit for storing history data generated according to a state change / event occurrence of the application unit in normal operation in a RAM; An exception processing unit which is called by the application unit where an exception situation has occurred and processes the exception situation occurring in the application; A history log unit which is called by the exception processing unit and dumps the historical data recorded in the RAM to a nonvolatile memory; And a device driver for recording the history data, which is called by the history log section and dumped to the nonvolatile memory, to the nonvolatile memory. Defining an element necessary for problem analysis as one of a state variable set S and an event set E ; Defining a subset (S, E) by selecting only the minimum elements necessary for problem tracking among the elements of the state variable set ( S ) and the event set ( E ); Updating the history (H _i ) for the elements in RAM according to the change of the elements constituting the defined subset (S, E); If an exception occurs while updating the history for the elements, the historical data (H = {H ₁ , H ₂ ,..., H _n }) stored in the RAM is non-volatile until the exception occurs. A history recording method of a mobile communication terminal comprising dumping into a memory and storing the same. The method of claim 2, wherein the history (H _i ), And a status change occurrence value, an occurrence event, and a changed state value. The method of claim 2, wherein the history update process comprises: When an event e _i occurs, determining whether there is a state change; And then, if it is determined that the state change and reflect the modified state values for the state variable (s _i), set to a true (True) the values (b _i) that indicates the state change has occurred or not, a history of (H _i) in the RAM Updating; If it is determined that the state change, the state variable (s _i) to set to zero, and set to a value (b _i) a false (False) indicating a status change has occurred and then, updates the history (H _i) in the RAM Making a step; Determining if there is an additional state change, if there is an additional state change, increase the index (i) by 1, set the occurrence event variable (e _i ) to 0, and reflect the changed state value in the state variable (s _i ). Setting a value (b _i ) indicating whether or not a state change has occurred to True, and then updating the history (H _i ) to the RAM; And if there is no additional state change as a result of the determination, increasing the index i by 1 and waiting for the next event to occur.

Images