TWI884076B - Real-time active firmware debug method and device under test - Google Patents

Abstract

A real-time active firmware debug method used to actively monitor the device under test in real time for debugging, and has steps as follows: sequentially reading a plurality of monitoring point addresses stored in a plurality of monitoring point address registers; sequentially reading a plurality of operation values ​​stored in a plurality of measuring point data registers corresponding to monitoring point addresses; ​​temporarily storing the read operation values in a plurality of monitoring point data registers; and combining at least a part of the operation values in the monitoring point data registers to generate a monitoring signal, and making the device under test actively and continuously outputs the operation values ​​in the monitoring signal sequentially through a preset output pin of the device under test, wherein the monitoring point data registers is electrically connected to the measuring point data registers.

Description

Active real-time firmware debugging method and device under test

The present invention relates to a firmware debugging technology, and in particular to an active real-time firmware debugging method and a device under test capable of running the real-time firmware debugging method.

The most annoying thing for a firmware developer is the time spent on debugging. However, as the speed of microcontroller units is getting faster and faster, and the application environment of microcontroller units is usually running on very small carriers (ex: low pin count), debugging projects are becoming more and more difficult for firmware developers. The technology of microcontroller units is changing with each passing day, whether in process, power consumption, size, application, etc., it can be said that it is advancing by leaps and bounds, but the debugging support for firmware still needs further improvement and improvement by industry professionals.

For chips or microcontroller units, existing debugging tools such as in-circuit emulators (ICE) or joint test group (JTAG) have complete debugging functions, so they can be used in conjunction with integrated development environment (IDE) tools to achieve tracker and backward capabilities. However, such debugging tools are only suitable for firmware development and are not for debugging after commercialization. For example, such debugging tools often change the execution speed of the microcontroller unit, resulting in the inability to reproduce the problem after the debugging tool is connected, or the use environment does not allow, for example, in-circuit emulator (ICE) or joint test group (JTAG) pins to be planned as general purpose input and output (GPIO) pins. In addition, this type of debugging tool uses a query-response method to perform debugging, that is, the debugging tool needs to issue a query command to allow the microcontroller unit to respond to related operating values, making it impossible to perform real-time debugging.

Another type of debugging tool can be a universal asynchronous transceiver, which is currently the most common debugging method after commercialization. The advantage is simplicity, because the transmit (TX) pin of a universal asynchronous transceiver can see the relevant operating values. However, this debugging tool must first embed a large amount of text information (TXT message) in the source code, especially for real-time operating systems (RTOS). These message prints (message print) will change the task switching timing of the real-time operating system. In this way, adding debugging information of the asynchronous transceiver will have different problem manifestations. On the other hand, this debugging tool cannot see extremely subtle transient problems, such as interrupt service functions that enter and exit quickly, or even the real-time operating system running the firmware entering an idle state or a firmware dead lock, which will result in the inability to send internal status information. In short, this debugging tool can only roughly check the firmware process and detect simple problems. For real-time operating systems that perform task switching, it is almost useless for debugging.

It can be understood from the above description that the purpose of the present invention is to provide a simple active real-time firmware debugging method that can actively and instantly perform firmware debugging and a device under test that can run the real-time firmware debugging method.

Based on one of the purposes of the present invention, an embodiment of the present invention provides an active real-time firmware debugging method. The active real-time firmware debugging method is used to actively monitor a device under test in real time to debug the device under test. The device under test has a plurality of test points, and the plurality of test points correspond to a plurality of test point data registers. Each test point data register stores a plurality of running values of the corresponding test point. The active real-time firmware debugging method at least includes the following steps: sequentially reading a plurality of monitoring point addresses stored in a plurality of monitoring point address registers; sequentially reading a plurality of monitoring point addresses stored in a plurality of monitoring point address registers; The method comprises the steps of: reading a plurality of operating values stored in a plurality of corresponding test point data registers; temporarily storing the read plurality of operating values in a plurality of monitoring point data registers; and combining at least a portion of the plurality of operating values in the plurality of monitoring point data registers to generate a monitoring signal, and enabling the device under test to actively and continuously output the plurality of operating values in the monitoring signal in sequence through its preset output pins, wherein the monitoring point data register is electrically connected to the test point data register.

Based on one of the purposes of the present invention, an embodiment of the present invention provides a device under test, which includes a plurality of electrically connected hardware circuits, wherein the plurality of hardware circuits are configured with a processing core, a plurality of test points, a plurality of test point data registers, a plurality of monitoring point address registers and a plurality of monitoring point data registers, and the device under test is capable of executing the above-mentioned active real-time firmware debugging method.

As mentioned above, the active real-time firmware debugging method and the device under test capable of running the real-time firmware debugging method provided by the present invention are simple and do not require complex interfaces or excessive source code content. They are fast and flexible and can be performed in a dynamic measurement manner.

The main purpose of the present invention is to provide an active real-time firmware debugging method that does not require a complex interface, does not require adding too much source code content, has a fast running speed, is flexible, and can be performed in a dynamic measurement manner, and to provide a device under test that can execute the active real-time firmware debugging method, wherein the device under test can continuously and actively send out multiple running values of the latest monitoring signal for the firmware debugger to know. The following will be accompanied by a diagram to explain in detail the possible implementation methods of the present invention, but it should be noted that the following implementation details are not used to limit the scope of the patent application claimed by the present invention, but are only for the convenience of understanding by those with ordinary knowledge in the relevant technical field.

First, please refer to Figures 1, 2, 3 and 5, Figure 1 is a schematic diagram of multiple monitoring point address registers and multiple mask registers of the device under test in an embodiment of the present invention, Figure 2 is a schematic diagram of multiple test point data registers of the device under test in an embodiment of the present invention, Figure 3 is a schematic diagram of the monitoring signal output by the preset output pin of the device under test in an embodiment of the present invention, and Figure 5 is a flow chart of the active real-time firmware debugging method of the embodiment of the present invention.

The device under test for executing the active real-time firmware debugging method of the present invention includes a plurality of electrically connected hardware circuits, wherein the plurality of hardware circuits are configured with a processing core, a plurality of test points (not shown), a plurality of test point data registers 102a, 102b, a plurality of monitoring point address registers 100a, 100b, a plurality of mask registers 101a, 101b, and a plurality of monitoring point data registers (not shown). In addition, the device under test can be, for example, but not limited to, a microcontroller unit.

The plurality of test points are a plurality of components of different types of the device under test, such as a timer, an analog-to-digital converter, an event detector, and a task execution unit, and the present invention is not limited thereto. The plurality of test points correspond to a plurality of test point data registers 102a, 102b, and each test point data register 102a, 102b stores a plurality of operating values of the corresponding test point. In one embodiment, the plurality of hardware circuits do not configure the plurality of mask registers 101a, 101b, that is, the plurality of mask registers 101a, 101b are optional configuration components of the device under test of the present invention.

The active real-time firmware debugging method provided by the embodiment of the present invention can be used to actively monitor the device under test in real time to debug it, and the steps of the active real-time firmware debugging method are described as follows. First, in step S500, a plurality of monitoring point addresses stored in a plurality of monitoring point address registers 100a, 100b are read in sequence. Then, in step S501, a plurality of running values stored in a plurality of test point data registers 102a, 102b corresponding to the plurality of monitoring point addresses are read in sequence. Taking FIG. 1 and FIG. 2 as examples, the address values 0x4000_1000 and 0x5000_1000 in the monitoring point address registers 100a and 100b are read in sequence, indicating that the multiple running values stored in the test point data registers 102a and 102b of the test point address values 0x4000_1000 and 0x5000_1000 are read. If it is necessary to observe and monitor multiple different test points, it is only necessary to modify the firmware code so that the monitoring point addresses stored in the monitoring point address registers 100a and 100b are changed.

In step S502, the read multiple running values are temporarily stored in multiple monitoring point data registers (not shown). Then, in step S503, multiple mask signals stored in multiple mask registers 101a and 101b corresponding to the multiple monitoring point data registers (not shown) are sequentially read, wherein the mask signal has multiple bits, and the values of the multiple bits are respectively used to indicate whether the multiple running values of the monitoring point data registers (not shown) are selected as part of the monitoring signal.

Taking FIG. 1 and FIG. 2 as examples, the mask signal stored in the mask register 101a is "10010", which means that the second and fifth bits of the running value stored in the corresponding monitoring point data register will be selected as part of the monitoring signal, wherein the second and fifth bits of the running value stored in the monitoring point data register are the interrupt flag value INT_FLAG and the over-run flag value O stored in the test point data register 102a. VER_RUN; and the mask signal stored in the mask register 101a is "11000", which means that the fourth and fifth bits of the running value stored in the corresponding monitoring point data register will be selected as part of the monitoring signal, wherein the second and fifth bits of the running value stored in the monitoring point data register are the status values STATUS_0 and STATUS_1 stored in the test point data register 102b.

Then, in step S504, at least a portion of the multiple running values in the multiple monitoring point data registers are combined to generate a monitoring signal, and the device under test actively and continuously outputs the multiple running values in the monitoring signal in sequence through its preset output pins, wherein at least a portion of the multiple running values in the multiple monitoring point data registers are combined according to a plurality of mask signals, and the multiple monitoring point data registers are electrically connected to the test point data registers 102a, 102b. Taking FIG. 1 to FIG. 3 as an example, the interrupt flag value INT_FLAG and the over-run flag value OVER_RUN stored in the test point data register 102a and the status values STATUS_0 and STATUS_1 stored in the test point data register 102b form a monitoring signal, and the monitoring signal adopts Manchester coding, which includes a prefix value PRE and the interrupt flag value INT_FLAG, the over-run flag value OVER_RUN and the status values STATUS_0 and STATUS_1 following the prefix value PRE in sequence.

Please note that in some embodiments, the active real-time firmware debugging method does not have step S503, and step S504 can combine at least a portion of the multiple running values in the multiple monitoring point data registers according to a specific rule, for example, the specific rule is to combine all the multiple running values, or to combine the multiple running values of specific bits in the multiple monitoring point data registers.

Please note that the device under test outputs multiple running values of the monitoring signal in sequence at the sampling frequency of the sampling clock signal through the preset output pin. The sampling clock signal comes from a clock signal source outside the device under test. The sampling frequency is an integer multiple of the clock signal frequency of the clock signal source and is related to the total number of multiple running values in the multiple monitoring point data registers to be combined into the monitoring signal. Taking Figure 3 as an example, the sampling frequency is 5 times the clock signal frequency of the clock signal source (the monitoring signal includes the interrupt flag value INT_FLAG, the over-run flag value OVER_RUN, the status values STATUS_0, STATUS_1 and the prefix value PRE to be monitored).

Preferably, in order to reduce the pins occupied by the device under test, the device under test only outputs the monitoring signal through a preset output pin, but the present invention is not limited to this. However, if the number of pins that can be used by the device under test is sufficient, the device under test can also output the monitoring signal through a plurality of preset output pins to reduce the sampling frequency. On the other hand, the present invention enables the device under test to run an active real-time firmware debugging method, and the execution of the firmware can be handed over to the execution memory access (DMA) device of the device under test, so even if the processing core in the device under test is not started (for example, in sleep mode or the execution of the firmware enters a deadlock) or does not exist, the active real-time firmware debugging method can enable the device under test to actively and continuously output multiple running values in the monitoring signal in sequence through its preset output pins. In addition, since the multiple test points can be multiple components of different types of the device under test, the multiple running values in the monitoring signal are not limited in type and do not have specific properties.

Furthermore, please refer to FIG. 4, which is a schematic diagram of a plurality of monitoring point address registers, a plurality of mask registers, a plurality of test point data registers and a monitoring signal output by a preset output pin of another embodiment of the present invention. The active real-time firmware debugging method of the present invention can be used to debug the situation where the device under test executes multiple tasks. As shown in FIG4 , the monitoring point address of the monitoring point address register 100a is the address value CURRENT_TASK_ID, which points to the test point data register 102a that records the multiple running values of the current multiple task identifications ID1 to ID3, and the monitoring point addresses of the multiple monitoring point address registers 100b are the address value TARGET_i (i is, for example, 1, 2, or 3, indicating that there are 3 tasks to be executed), which point to the multiple addresses of the multiple test point data registers of the multiple tasks corresponding to the multiple task identifications ID1 to ID3. Therefore, _the monitoring signal in FIG4 includes the prefix value PRE, the running values of the task identifications ID0-ID2, and three running values _{X1X1X1X1X1X1 , X2X2X2X2X2} , _{X3X3X3X3X3X3 corresponding} to the task identifications _{ID0 - ID2} . Thus, _{the active} real- _time firmware debugging method of the present invention _{has a} sharing _function in terms of time.

In summary, the active real-time firmware debugging method and the device under test capable of executing the active real-time firmware debugging method provided by the present invention have the following beneficial technical effects: (1) no complex interface is required, and only one output pin of the device under test needs to be preset to output multiple operating values to be monitored; (2) no excessive source code content needs to be added, and the firmware release version (firmware release (3) The debugging runs fast, so it is possible to see conditions that even the firmware cannot detect, and it is instantaneous without any time delay. (4) It is flexible and can monitor the running values of the test point data registers at any accessible address on the internal bus of the device under test, such as the running values in the test point data registers of various types of components, and these running values may be the state of the firmware's finite state machine (FSM), the source code (process (5) Debugging is performed in a dynamic measurement manner. The object to be observed can be changed at any time during the operation of the device under test. For example, when the system of the device under test enters sleep mode, the status of the interrupt source is measured, and when the system of the device under test is awakened, the charging status of the charger is measured.

The present invention is disclosed in this article only with preferred embodiments. However, anyone familiar with the technical field should understand that the above embodiments are only used to describe the present invention and are not used to limit the scope of the patent rights claimed by the present invention. Any changes or substitutions that are equal or equivalent to the above embodiments should be interpreted as being included in the spirit or scope of the present invention. Therefore, the protection scope of the present invention should be based on the scope defined by the following patent application.

100a, 100b: multiple monitoring point address registers 101a, 101b: multiple mask registers 102a, 102b: test point data registers S500~S504: steps 0x4000_1000, 0x5000_1000, CURRENT_TASK_ID, TARGET_i: address value PRE: prefix value OVER_RUN: over-run flag value INT_FLAG: interrupt flag value ID0~ID2: task identification STATUS_0, STATUS_1: status value _{X1 X1 X1 X1 X1 , X2 X2 X2 X2 X2 , X3 X3 X3 X3 X3 :} running value

In order to make the above and other purposes, features, advantages and embodiments of the present invention more clearly understandable, the attached drawings are described as follows: Figure 1 is a schematic diagram of a plurality of monitoring point address registers and a plurality of mask registers of a device under test of an embodiment of the present invention; Figure 2 is a schematic diagram of a plurality of test point data registers of a device under test of an embodiment of the present invention; Figure 3 is a schematic diagram of a monitoring signal output by a preset output pin of a device under test of an embodiment of the present invention; Figure 4 is a schematic diagram of a plurality of monitoring point address registers, a plurality of mask registers, a plurality of test point data registers and a monitoring signal output by a preset output pin of a device under test of another embodiment of the present invention; and Figure 5 is a flow chart of the active real-time firmware debugging method of an embodiment of the present invention.

S500~S504: Steps

Claims (10)

An active real-time firmware debugging method is used to actively monitor a device under test in real time to debug it. The device under test has a plurality of test points, and the plurality of test points correspond to a plurality of test point data registers. Each of the test point data registers stores a plurality of running values of the corresponding test point. The active real-time firmware debugging method includes: Sequentially reading a plurality of monitoring point addresses stored in a plurality of monitoring point address registers; Sequentially reading the plurality of running values stored in the plurality of test point data registers corresponding to the plurality of monitoring point addresses; The plurality of operating values read are temporarily stored in a plurality of monitoring point data registers; and At least a portion of the plurality of operating values in the plurality of monitoring point data registers are combined to generate a monitoring signal, and the device under test actively and continuously outputs the plurality of operating values in the monitoring signal in sequence through a preset output pin, wherein the monitoring point data register is electrically connected to the test point data register. The active real-time firmware debugging method as described in claim 1 further includes: Sequentially reading a plurality of mask signals stored in a plurality of mask registers corresponding to the plurality of monitoring point data registers, wherein the mask signal has a plurality of bits, and the values of the plurality of bits are respectively used to indicate whether the plurality of running values of the monitoring point data register are selected as part of the monitoring signal, and combining at least a portion of the plurality of running values in the plurality of monitoring point data registers according to the plurality of mask signals. The active real-time firmware debugging method as described in claim 1, wherein the device under test sequentially outputs the plurality of operating values in the monitoring signal at a sampling frequency of a sampling clock signal through the preset output pin. The active real-time firmware debugging method as described in claim 1, wherein the device under test outputs the monitoring signal only through the default output pin. An active real-time firmware debugging method as described in claim 3, wherein the sampling clock signal comes from a clock signal source outside the device under test, the sampling frequency is an integer multiple of the clock frequency of the clock signal of the clock signal source, and is related to a total number of the multiple running values in the multiple monitoring point data registers to be combined into the monitoring signal. An active real-time firmware debugging method as described in claim 1, wherein even if a processing core in the device under test is not started or does not exist, the active real-time firmware debugging method enables the device under test to actively and continuously output the multiple operating values in the monitoring signal in sequence through its default output pin. An active real-time firmware debugging method as described in claim 1, wherein the plurality of test points are a plurality of components of different types in the device under test. An active real-time firmware debugging method as described in claim 1, wherein a first monitoring point address of a first monitoring point address register among the plurality of monitoring point address registers points to the test point data register recording the plurality of running values of the current plurality of task identifications, and a plurality of second monitoring point addresses of a plurality of second monitoring point address registers among the plurality of monitoring point address registers point to a plurality of addresses of the plurality of test point data registers of the plurality of tasks corresponding to the plurality of task identifications. A device under test includes a plurality of electrically connected hardware circuits, wherein the plurality of hardware circuits are configured with a processing core, a plurality of test points, a plurality of test point data registers, a plurality of monitoring point address registers and a plurality of monitoring point data registers, wherein the steps of executing active real-time firmware debugging on the device under test include: Sequentially reading a plurality of monitoring point addresses stored in a plurality of monitoring point address registers; Sequentially reading a plurality of operating values stored in the plurality of test point data registers corresponding to the plurality of monitoring point addresses; The plurality of operating values read are temporarily stored in a plurality of monitoring point data registers; and At least a portion of the plurality of operating values in the plurality of monitoring point data registers are combined to generate a monitoring signal, and the device under test actively and continuously outputs the plurality of operating values in the monitoring signal in sequence through a preset output pin, wherein the monitoring point data register is electrically connected to the test point data register. The device under test as described in claim 9, wherein the step of performing active real-time firmware debugging of the device under test further includes: Sequentially reading a plurality of mask signals stored in a plurality of mask registers corresponding to the plurality of monitoring point data registers, wherein the mask signal has a plurality of bits, and the values of the plurality of bits are respectively used to indicate whether the plurality of running values of the monitoring point data register are selected as part of the monitoring signal, and combining at least a portion of the plurality of running values in the plurality of monitoring point data registers according to the plurality of mask signals.

Images