CN113626310B - Development and debugging system, equipment to be tested and debugging method - Google Patents
Development and debugging system, equipment to be tested and debugging method Download PDFInfo
- Publication number
- CN113626310B CN113626310B CN202110780359.5A CN202110780359A CN113626310B CN 113626310 B CN113626310 B CN 113626310B CN 202110780359 A CN202110780359 A CN 202110780359A CN 113626310 B CN113626310 B CN 113626310B
- Authority
- CN
- China
- Prior art keywords
- host
- debugging
- module
- reset
- tested
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 42
- 238000011161 development Methods 0.000 title claims abstract description 22
- 238000004891 communication Methods 0.000 claims abstract description 105
- 230000003993 interaction Effects 0.000 claims abstract description 67
- 230000002452 interceptive effect Effects 0.000 claims abstract description 25
- 238000012360 testing method Methods 0.000 claims description 166
- 230000001360 synchronised effect Effects 0.000 claims description 23
- 238000012795 verification Methods 0.000 claims description 19
- 230000008859 change Effects 0.000 claims description 18
- 230000006870 function Effects 0.000 description 29
- 230000008569 process Effects 0.000 description 13
- 238000010586 diagram Methods 0.000 description 8
- 238000004590 computer program Methods 0.000 description 7
- 238000012986 modification Methods 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 230000001960 triggered effect Effects 0.000 description 4
- 230000004075 alteration Effects 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 230000000630 rising effect Effects 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 230000002045 lasting effect Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/3648—Software debugging using additional hardware
- G06F11/3656—Software debugging using additional hardware using a specific debug interface
Landscapes
- Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Test And Diagnosis Of Digital Computers (AREA)
Abstract
The embodiment of the application provides a development and debugging system, equipment to be tested and a debugging method, wherein the development and debugging system comprises a host and the equipment to be tested, the equipment to be tested comprises a reset interface, a debugging module and a reset module, and the host is connected with the debugging module and the reset module through the reset interface; the host is used for sending interactive data to the debugging module and the resetting module through the resetting interface; the debugging module is used for judging whether the interaction data are correct, and if so, executing debugging operation according to the interaction data; and the reset module is used for executing reset operation according to the interactive data under the condition that the communication rate of the interactive data is smaller than the reset period of the equipment to be tested. Through setting up the communication rate of interactive data, can distinguish debugging signal and reset signal, and then can realize debugging interface and reset interface multiplexing, need not set up the debugging interface alone, solved PCB space and IC pin and occupy too much problem.
Description
Technical Field
The application relates to the technical field of debugging, in particular to a development and debugging system, equipment to be tested and a debugging method.
Background
A debug interface scheme commonly used in the industry is a standard JTAG (Joint Test Action Group, joint test working group) boundary scan interface, which contains at least 4 input-output lines: test clock, test mode, test data input and test data output. As at least 4 debug signal lines are required, it is increasingly difficult to realize the circuit board (Printed Circuit Board ) space and IC (integrated circuit, integrated circuit) pins are increasingly scarce due to miniaturization of electronic products.
While the industry has a small-size debug protocol set 1149.7 (IEEE Standard for Reduced-Pin and Enhanced-Functionality Test Access Port and Boundary-Scan Architecture) defined by IEEE (Institute of Electrical and Electronics Engineers ), a small-size two-wire debug protocol is provided: cJTAG. But the standard is very complex (documents longer than a thousand pages) and the primary design goal in any JTAG protocol family (1149. X) is to provide boundary scan functionality, not to provide interactive debug functionality. Thus, the JTAG protocol family provides functions that are not much useful for RISC-V (fifth generation reduced instruction set computers), is not efficient for interactive debug transmission for RISC-V, and the two-wire debug protocol cJTAG included in this standard requires the use of special IO ports and asynchronous timing protocols, making the cJTAG protocol difficult to implement.
In one aspect, ARM (Advanced RISC Machines) proposes a SWD two-wire debug scheme. Similar to cJTAG, it can be multiplexed with both the test mode and the test clock of the JTAG interface. Thus also being compatible with the standard 4-wire JTAG protocol. This standard has become a real standard for two-wire debugging due to the ARM's share in the embedded market. It still occupies two pins and cannot be multiplexed with other functions at the same time.
On the other hand, the schematic semiconductor, although proposing a single-wire debug scheme of STM8, is a SWIM (Serial Wire Interface Module, single bus interface module) protocol. However, the SWIM protocol communication rate only has two fixed gears, the debugging of a non-STM 8 platform is not supported in the protocol design, the adaptability to the environment is limited, and the method has the defect of low practicability; and the debugging ports are required to be independently arranged, so that a certain occupation exists on the PCB space and the IC pins, and the use requirement is difficult to meet under the condition of shortage of system I/O resources.
Problems in the prior art:
the existing debugging interfaces are all arranged independently and can not coexist with other functions at the same time, and the problems of excessive occupation of PCB space and IC pins exist.
Disclosure of Invention
The embodiment of the application provides a development and debugging system, equipment to be tested and a debugging method, which solve the problem that the space of a PCB and the pins of an IC occupy too much by multiplexing a debugging interface and a resetting interface.
According to a first aspect of an embodiment of the present application, there is provided a development and debugging system, the development and debugging system including a host and a device to be tested, the device to be tested including a reset interface, a debugging module and a reset module, the host being connected to the debugging module and the reset module through the reset interface;
the host is used for sending interactive data to the debugging module and the reset module through the reset interface;
the debugging module is used for judging whether the interaction data are correct or not, and if so, executing debugging operation according to the interaction data;
the reset module is used for executing reset operation according to the interaction data under the condition that the communication rate of the interaction data is smaller than the reset period of the device to be tested.
According to a second aspect of the embodiment of the present application, there is provided a device to be tested, the device to be tested including a reset interface, a debug module, and a reset module, the debug module and the reset module being connected to a host through the reset interface;
the debugging module and the resetting module are both used for receiving the interaction data sent by the host through the resetting interface;
the debugging module is used for judging whether the interaction data are correct or not, and if so, executing debugging operation according to the interaction data;
the reset module is used for executing reset operation according to the interaction data under the condition that the communication rate of the interaction data is smaller than the reset period of the device to be tested.
According to a third aspect of an embodiment of the present application, there is provided a debugging method, the method being applied to a device to be tested, the device to be tested including a reset interface, a debugging module, and a reset module, the debugging module and the reset module being connected to a host through the reset interface, the method including:
the debugging module and the resetting module receive interaction data sent by the host;
the debugging module judges whether the interaction data is correct, if so, the debugging operation is executed according to the interaction data;
and the reset module executes reset operation according to the interaction data under the condition that the communication rate of the interaction data is smaller than the reset period of the equipment to be tested.
By adopting the development and debugging system, the equipment to be tested and the debugging method provided by the embodiment of the application, the development and debugging system comprises a host and the equipment to be tested, the equipment to be tested comprises a reset interface, a debugging module and a reset module, and the host is connected with the debugging module and the reset module through the reset interface; the host is used for sending interactive data to the debugging module and the resetting module through the resetting interface; the debugging module is used for judging whether the interaction data are correct, and if so, executing debugging operation according to the interaction data; and the reset module is used for executing reset operation according to the interactive data under the condition that the communication rate of the interactive data is smaller than the reset period of the equipment to be tested. Therefore, through setting the communication rate of the interactive data, the debugging signals and the reset signals can be distinguished, so that the multiplexing of the debugging interface and the reset interface can be realized, the debugging interface is not required to be independently arranged, and the problem that the PCB space and the IC pins occupy too much is solved.
Drawings
The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this specification, illustrate embodiments of the application and together with the description serve to explain the application and do not constitute a limitation on the application. In the drawings:
FIG. 1 is a schematic diagram of a development and debugging system according to an embodiment of the present application;
FIG. 2 is a schematic flow chart of a debugging method according to an embodiment of the present application;
FIG. 3 is a flowchart illustrating another debugging method according to an embodiment of the present application;
fig. 4 is a flow chart of another debugging method according to an embodiment of the present application.
Detailed Description
In the process of realizing the application, the inventor finds that the current debugging interfaces are all arranged independently and are not multiplexed with other functions, and the problems of excessive occupation of PCB space and IC pins exist.
In view of the above problems, embodiments of the present application provide a development and debugging system, a device to be tested, and a debugging method, which can distinguish between a debug signal and a reset signal by setting a communication rate of interactive data, so as to realize multiplexing of a debug interface and a reset interface, and solve the problem that excessive occupation of PCB space and IC pins is not required to be separately set up.
The scheme in the embodiment of the application can be realized by adopting various computer languages, such as object-oriented programming language Java, an transliteration script language JavaScript and the like.
In order to make the technical solutions and advantages of the embodiments of the present application more apparent, the following detailed description of exemplary embodiments of the present application is provided in conjunction with the accompanying drawings, and it is apparent that the described embodiments are only some embodiments of the present application and not exhaustive of all embodiments. It should be noted that, without conflict, the embodiments of the present application and features of the embodiments may be combined with each other.
Referring to fig. 1, a schematic structural diagram of a development and debugging system 100 according to an embodiment of the present application is provided, the development and debugging system 100 includes a host 110 and a device under test 120, the device under test 120 includes a reset interface 121, a debugging module 122 and a reset module 123, and the host 110 is connected to the debugging module 122 and the reset module 123 through the reset interface 121.
Host 110 is configured to send interaction data to debug module 122 and reset module 123 via reset interface 121; the debugging module 122 is configured to determine whether the interaction data is correct, and if so, execute a debugging operation according to the interaction data; the reset module 123 is configured to perform a reset operation according to the interaction data when the communication rate of the interaction data is less than the reset period of the device under test 120.
It should be understood that when the host 110 performs a debug operation with the device under test 120, since the debug interface of the device under test 120 is multiplexed with the reset interface 121, in order to prevent the debug signal from falsely triggering the reset function of the device under test 120. If the interaction data sent by the host 110 is a debug signal, the communication rate of the interaction data should be set to be greater than the reset period; if the interactive data sent by the host 110 is a reset signal, the communication rate of the interactive data should be less than the reset period. Because the reset module 123 is only triggered by the interaction data with the communication rate smaller than the reset period, the debug signal and the reset signal are distinguished by setting different communication rates, and the multiplexing function of the debug interface and the reset interface 121 is further realized.
The reset period is understood to mean the period of the reset signal.
In order to further prevent the debug signal from falsely triggering the reset of the device under test 120, the reset module 123 is further configured to perform a reset operation according to the interaction data if the communication rate of the interaction data is less than a preset multiple of the reset period. The preset multiple may be 10 times, that is, the communication rate of the interaction data is less than 10 times of the period of the reset signal of the device under test 120.
For example, if the reset module 123 of the device under test 120 needs to receive a low level reset signal lasting 1ms to trigger the reset function, the communication rate of the debug signal must not be lower than 10Kbps.
By setting the preset multiple, the communication rate of the debug signal can be more obviously distinguished from the period of the reset signal, so that the distinction between the debug signal and the reset signal is larger. And thus, errors of the debug signal can be avoided, and the reset module 123 is triggered by errors to perform a reset operation.
It should be understood that, instead of setting the communication rate of the interactive data according to the period of the reset signal, the debug signal and the reset signal are distinguished; the method can also be used for setting the level width of the interaction data according to the level width of the reset signal, and the exchange signal and the reset signal are newly distinguished.
For example, the level width of the debug signal should be smaller than the level width of the reset signal, and the level width of the debug signal may be set to be one tenth of the level width of the reset signal. If the reset module 123 needs a low level long enough to trigger the reset function; in order to avoid that the debug signal erroneously triggers the reset function, the low level width of the debug signal should be smaller than the low level width of the reset signal.
In this embodiment, since the debug module 122 and the reset module 123 both receive the interaction data sent by the host 110, that is, when the interaction data is a reset signal, the debug module 122 and the reset module 123 both receive the reset signal, the debug module 122 determines whether the reset signal is correct, and since the reset signal is not a debug signal, the debug module 122 determines that the reset signal is incorrect, and does not perform the debug operation; the reset module 123 is triggered by a reset signal. When the interaction data is a debug signal, the debug module 122 and the reset module 123 both receive the debug signal, the debug module 122 determines whether the debug signal is correct, and if the debug signal is correct, the debug operation is executed; in the event that the debug signal is incorrect, debug module 122 does not perform a debug operation; since the communication rate of the debug signal is greater than the reset period, the reset module 123 is not triggered by the debug signal to reset.
In this embodiment, the interaction data includes verification information and command information. In other words, when the interactive data is a debug signal, the debug signal includes verification information and command information.
Debug module 122 is also used to determine if the verification information and command information are correct; if either of the check information and the command information is incorrect, the debug module 122 is further configured to send an error hint message to the host 110; if the verification information and the command information are both correct, the debug module 122 is further configured to execute a debug operation according to the command information.
It should be appreciated that the debug module 122 checks whether the verification information is correct, and if not, sends an error hint message to the host 110; if the verification information is correct, the debug module 122 checks whether the command information is correct, and if not, sends error prompt information to the host 110; if the command information is correct, the debug module 122 performs a debug operation according to the command information.
In this embodiment, the debug module 122 is further configured to check the status of the debug operation, and send reply frame information to the host 110 after the debug operation is performed; the host 110 is also used for checking whether the reply frame information is correct; if not, the host 110 is further configured to send a repeat upload command to the debug module 122 through the reset interface 121; the debug module 122 is further configured to send new reply frame information to the host 110 according to the repeat upload command; the host 110 is further configured to stop sending the repeat upload command to the debug module 122 through the reset interface 121 if the reply frame information is correct or the number of times of sending the repeat upload command reaches a preset number of times.
The reply frame information may enable the host 110 to obtain the debug status of the debug module 122, so that the host 110 can know the debug status of the device under test 120 in real time, determine whether a fault exists in the debug process of the device under test 120, and respond in time in the case of the fault.
The host 110 again transmits the repeat upload command to the debug module 122 in case that the reply frame information is incorrect, and stops transmitting the repeat upload command to the debug module 122 in case that the reply frame information is correct or the number of times of transmitting the repeat upload command reaches a preset number of times.
It should be understood that the reply frame information includes verification information, after the host 110 receives the reply frame information, it checks whether the verification information of the reply frame information is correct, if not, the host 110 sends a repeat upload command to the device to be tested 120, and the device to be tested 120 sends new reply frame information to the host 110 again according to the repeat upload command; the host 110 confirms whether the verification information of the new reply frame information is correct according to the new reply frame information sent again by the device to be tested 120, if not, the host 110 continues to send a repeat uploading command to the device to be tested 120, and repeats the operation until the number of times that the host 110 continuously sends the repeat uploading command to the device to be tested 120 reaches the preset number of times, or the verification information of the reply frame information received by the host 110 is correct.
It should be understood that, if the execution of the command information is completed, the content of the reply frame information sent by the device under test 120 to the host 110 may be implemented in the following two ways. One of the modes is as follows: the reply frame information includes acknowledgement information, and if the execution command information is completed and the device under test 120 does not need to return the data load of the host 110, the device under test 120 feeds back the acknowledgement information to the host 110. Another way is: the reply frame information includes reply data, and if the execution command information is completed and the device under test 120 needs to return to the data load of the host 110, the device under test 120 sends the reply data to the host 110.
The debug signal can adopt a coded data format, namely the debug signal format can comprise a 1 start bit, an 8 data bit, a 1 odd check bit and a 1 stop bit, command information is arranged in the data bit, and check information is arranged in the odd check bit; if the check information and the data are bit-wise exclusive-or 1, the correct check information is represented, and if the check information and the data are bit-wise exclusive-or 0, the wrong check information is represented; the command information format may include a command word, a result of a bit-wise reversal of the command word, an optional data payload, and an accumulated checksum; the reply data includes the command word in the command information and the data payload that needs to be returned to the host 110.
The command word contains the following contents: control instructions, setting instructions, resetting debugging signals, information acquisition instructions, safety information and communication rate setting instructions; the control instruction is used for controlling shutdown, breaking point, writing memory, running program and the like of the control part of the device under test 120; the setting instruction includes reading and writing data such as memory, register value and the like of the data portion of the device under test 120, so that the host 110 can perform functions such as programming, parameter setting and the like on the device under test 120; the reset debugging signal is a reset debugging signal of the range of the selectable reset domain of the reset module 123 of the device under test 120, so that the device under test 120 which may work abnormally can be reset in a soft or hard mode, and returns to a normal state; the information acquisition instruction is an instruction sent by initializing the host 110 and the device 120 to be tested in the handshake process, and the host 110 can acquire the hardware model, the core model, the capability and the revision of the device 120 to be tested by acquiring the information instruction; the security information may include a password, and the host 110 and the device to be tested 120 may implement an authentication function by exchanging respective preset passwords, that is, may verify whether the host 110 has authority to access the device to be tested 120, and the device to be tested 120 may reject the authorized debug access; the host 110 can set the communication rate of the device 120 to be tested according to the communication rate setting instruction, and can select different communication rates under different scenes, so that the stability and the speed of communication are improved; a data payload may be understood as a specific data content stored at the device under test 120; the accumulated checksum is used to characterize whether the command information is complete and correct.
The debug signal is in encoded data format, and host 110 can be designed to multiplex the serial transceiver of an existing system without having to generate special length low levels in program or special hardware, so that host 110 can be implemented relatively simply using a generic platform without requiring complete redesign.
Before the host 110 and the device under test 120 perform normal communication, a handshake process is required between the host 110 and the device under test 120, and after handshake is successful, normal communication can be performed between the host 110 and the device under test 120. The handshake process includes communication rate synchronization between the host 110 and the device under test 120, and initialization setting between the host 110 and the device under test 120.
The working principle of the handshake flow can be as follows: the host 110 is configured to send a synchronization trigger signal to the device under test 120; the device under test 120 is configured to send a synchronization code to the host 110 according to the synchronization trigger signal; wherein the synchronization code is obtained according to the clock frequency of the device under test 120; the host 110 is further configured to obtain a communication rate of the device under test 120 according to the synchronization code; the host 110 is further configured to perform initialization setting with the device under test 120 based on the communication rate; if the initialization settings of the host 110 and the device under test 120 are successful, the handshake between the host 110 and the device under test 120 is successful.
It should be appreciated that the synchronization trigger signal may be a low level of a certain length, or may be a PWM (Pulse Width Modulation ) signal.
The host 110 sends a synchronization trigger signal to the reset interface 121 of the device under test 120, so that the level width of the synchronization trigger signal should be smaller than the level width of the reset signal in order to avoid the synchronization trigger signal from triggering the reset function by mistake. If a sufficiently long low level width is required to trigger the reset function, the low level width of the synchronous trigger signal should be smaller than the low level width of the reset signal. In order to reduce the probability of false triggering of the reset function, the low level width of the synchronous trigger signal should be less than one tenth of the low level width of the reset signal.
The synchronization code is obtained from the clock frequency of the device under test 120. It should be understood that after the device under test 120 receives the synchronization trigger signal, the synchronization trigger signal is treated as an error frame, and the device under test 120 sends an error code, i.e. a synchronization code, to the host 110 at the current communication rate. The error code may be understood as an error prompt signal fed back by the device under test 120 according to the synchronization trigger signal.
The communication rate of the device under test 120 is generated according to the clock frequency of the device under test 120, and the communication rate may be the clock frequency, or may be obtained by frequency division according to the clock frequency, so that the communication rate of the device under test 120 may be set according to the actual situation.
Wherein, after synchronization, the highest communication rate should be one sixteenth of the clock frequency, and when the clock frequency is 16MHz, the communication rate should be 1Mbps.
The host 110 measures the pulse width length of the synchronous code; the host 110 obtains the communication rate of the device under test 120 according to the pulse width length of the synchronization code. The host 110 includes a timer, which starts counting when the host 110 detects a rising edge of the synchronization code, and stops counting when the host 110 detects a falling edge of the synchronization code. And obtaining the pulse width length of the synchronous code according to the time length of the timer between the adjacent rising edge and the adjacent falling edge of the synchronous code.
After obtaining the communication rate of the device under test 120, the host 110 may use the communication rate of the device under test 120 to perform data transmission, so as to achieve the consistent communication rate between the host 110 and the device under test 120, that is, the host 110 and the device under test 120 have achieved physical communication synchronization.
After communication synchronization is achieved between the host 110 and the device under test 120, data interaction can be performed between the host 110 and the device under test 120 to achieve initialization setting. The principle of implementing initialization setting between the host 110 and the device under test 120 may be: the host 110 sends an information acquisition instruction to the device under test 120 based on the communication rate; the device under test 120 feeds back the characteristic information to the host 110 according to the information acquisition instruction; the host 110 performs initialization setting according to the feature information.
The initialization setting may be that the host 110 determines functions supported by the device under test 120 according to the feature information of the device under test 120, and the host 110 sends instructions according to the functions supported by the device under test 120. The feature information includes the chip model number, core model number, and supported function information of the device under test 120.
It should be understood that, the host 110 sends the instruction for obtaining information to the device under test 120 based on the communication rate of the device under test 120, because the communication rate of the host 110 sending the instruction and the communication rate of the device under test 120, the device under test 120 can correctly receive the instruction for obtaining information, and feedback the characteristic information to the host 110 according to the instruction for obtaining information. The feature information includes chip type, core type and function information of the device under test 120, the host 110 can determine functions supported by the device under test 120 based on the chip type, core type and function information of the device under test 120, and the host 110 sends corresponding instructions according to the functions supported by the device under test 120.
In an alternative embodiment, host 110 may also send host 110 characteristic information to device under test 120. The device under test 120 can determine the functions supported by the host 110 according to the feature information of the host 110. The feature information of the host 110 includes, among others, a debug specification followed by the host 110, supported function information, and the like.
The handshake process includes communication rate synchronization and initialization setting, and before the initialization setting is performed, the communication rate synchronization needs to be ensured. After the initialization setting is successful, the handshake flow ends.
In this embodiment, the synchronization function is moved to the host 110 to be implemented, so that the chip area of the device under test 120 can be reduced, the timing can be improved, and the verification is simpler.
In an alternative embodiment, since the clock frequency of the device under test 120 changes, the communication rate of the corresponding device under test 120 also changes, and since the host 110 also communicates with the device under test 120 based on the communication rate before the change of the device under test 120, the communication rate between the host 110 and the device under test 120 is in an unsynchronized state. In the event of a change in the communication rate of the device under test 120, synchronization can also be maintained between the host 110 and the device under test 120. The application also provides a heavy handshake process, the working principle of which is as follows: if the clock frequency of the device under test 120 changes, the device under test 120 is further configured to send the updated synchronization code to the host 110; the host 110 is further configured to obtain an updated communication rate of the slave according to the updated synchronization code.
It should be appreciated that as the clock frequency of the device under test 120 changes, the communication rate of the device under test 120 correspondingly changes. Under the condition that the communication rate of the device under test 120 is changed, if the host 110 performs data interaction with the device under test 120 according to the communication rate corresponding to the clock frequency of the device under test 120 before the change, the host 110 and the device under test 120 are not in a communication synchronization state because the communication rate of the host 110 is inconsistent with the communication rate of the device under test 120, and normal communication between the host 110 and the device under test 120 is impossible. Therefore, after the clock frequency of the device under test 120 is changed, the device under test 120 actively transmits the updated synchronization code to the host 110.
The host 110 may obtain the updated communication rate of the device under test 120 according to the updated synchronization code, and the host 110 performs data interaction with the device under test 120 through the updated communication rate, so that the communication rates of the host 110 and the device under test 120 are kept consistent again, and the host 110 and the device under test 120 are continuously in a communication synchronization state.
It can be seen that, through the above-mentioned heavy handshake procedure, in the case that the clock frequency of the device under test 120 is changed, the device under test 120 actively sends the updated synchronization code to the host 110, so that the communication rate of the host 110 is correspondingly updated. It is ensured that synchronization can be continued between the host 110 and the device under test 120 in the event of a change in the communication rate of the device under test 120.
Before the device under test 120 sends the updated synchronization code to the host 110, the device under test 120 is further configured to send a frequency change signal to the host 110; the host 110 is further configured to stop communication with the device under test 120 according to the frequency change signal.
It should be appreciated that the device under test 120 may generate the frequency change signal in response to a clock frequency change instruction that is generated by the device under test 120 in response to an external operation, which may be understood as a clock frequency change operation by a worker.
When the device under test 120 generates the frequency change signal, the clock frequency of the device under test 120 is not changed, and the device under test 120 determines that the clock frequency of the device under test 120 is to be changed according to the clock frequency change instruction, and then sends the frequency change signal to the host 110 before the clock frequency of the device under test 120 is changed.
Since the clock frequency of the device under test 120 will change, in order to avoid communication failure due to the change of the clock frequency of the device under test 120 during the data interaction between the host 110 and the device under test 120. The host 110 stops communicating with the device under test 120 before the clock frequency of the device under test 120 changes, and after the clock frequency of the device under test 120 changes, and the host 110 resynchronizes with the device under test 120, the host 110 resumes communicating with the device under test 120.
After the handshake process or the heavy handshake process is finished, the host 110 transmits the interaction data to the device under test 120 based on the communication rate of the device under test 120.
In this embodiment, if the device under test 120 does not know that the clock frequency will change, that is, if the device under test 120 does not actively send the frequency change signal, the host 110 may actively walk through the handshake process again, so as to avoid an unsynchronized phenomenon of communication between the host 110 and the device under test 120.
The principle of the host 110 actively walking through the handshake procedure again is: if the device under test 120 feeds back the interaction data timeout or error to the host 110, the host 110 is further configured to determine that the clock frequency of the device under test 120 changes, and send a synchronization trigger signal to the device under test 120; the device under test 120 is further configured to send an updated synchronization code to the host 110 according to the synchronization trigger signal; the host 110 is further configured to obtain an updated communication rate of the device under test 120 according to the updated synchronization code.
It should be understood that if the clock frequency of the device under test 120 is changed, the communication rate of the device under test 120 is correspondingly changed, and the host 110 also communicates with the device under test 120 based on the communication rate corresponding to the device under test 120 before the clock frequency is changed, where the communication rate of the host 110 is inconsistent with the communication rate of the device under test 120. The host 110 and the device under test 120 are not in a communication synchronization state, and normal communication between the host 110 and the device under test 120 is not possible.
In the case that the host 110 and the device under test 120 are not in a communication synchronization state, the interaction data fed back by the device under test 120 to the host 110 may have a phenomenon of timeout or error; that is, if the host 110 does not receive the interactive data fed back by the device under test 120 within the preset time, or receives the erroneous interactive data fed back by the device under test 120 within the preset time; the host 110 determines that the clock frequency of the device under test 120 has changed, and resends the synchronization trigger signal to the device under test 120, and then walks through the handshake process again to complete synchronization between the host 110 and the device under test 120.
The device under test 120 re-transmits the updated synchronization code to the device under test 120 according to the synchronization trigger signal transmitted by the host 110, where the updated synchronization code is obtained according to the clock frequency of the device under test 120 after being changed. That is, since the communication rate of the device under test 120 is generated according to the clock frequency of the device under test 120, when the clock frequency of the device under test 120 is changed, the communication rate of the device under test 120 is correspondingly changed, and thus the synchronization code sent by the device under test 120 to the host 110 at the changed communication rate is correspondingly changed.
Since the device under test 120 transmits the updated synchronization code to the host 110 at the changed communication rate, the host 110 measures the pulse width length of the updated synchronization code and obtains the updated communication rate of the device under test 120 according to the pulse width length of the updated synchronization code. The host 110 performs data interaction with the device under test 120 based on the updated communication rate of the device under test 120, the communication rates of the host 110 and the device under test 120 are kept consistent, and communication synchronization is completed between the host 110 and the device under test 120 again.
In the handshake process, the host 110 and the device to be tested 120 communicate through the reset interface 121, and in order to avoid false triggering of the reset function, in addition to setting the level width of the synchronization trigger signal, the communication rate of the device to be tested 120 needs to be set, that is, the communication rate after the host 110 and the device to be tested 120 are synchronized is set. If the reset operation is needed, the synchronous communication rate is smaller than the reset period; if the debugging operation is required, the communication rate after synchronization should be greater than the reset period.
It should be understood that the host 110 may be a burner (e.g., a computer and a debugger), an offline programmer, etc., and the slave may be a chip to be detected and a chip to be programmed.
Referring to fig. 2, fig. 2 is a schematic flow chart of a debugging method provided by the embodiment of the present application, on the basis of the device under test 120 shown in fig. 1, the debugging method may include the following steps:
s201, the debugging module and the resetting module receive interaction data sent by the host.
S202, the debugging module judges whether the interaction data are correct, and if so, the debugging operation is executed according to the interaction data.
S203, the reset module executes reset operation according to the interaction data under the condition that the communication rate of the interaction data is smaller than the reset period of the device to be tested.
Referring to fig. 3, a flowchart of another debugging method according to an embodiment of the present application is shown, where S202 includes the following steps:
s202a, the debugging module judges whether the check information and the command information are correct.
S202b, if any one of the check information and the command information is incorrect, the debugging module sends error prompt information to the host.
S202c, if the verification information and the command information are both correct, the debugging module executes debugging operation according to the command information.
Referring to fig. 4, a flowchart of another debugging method according to an embodiment of the present application is shown, and based on the description of fig. 3, S202 further includes the following steps:
s202d, the debugging module checks the state of the debugging operation and sends reply frame information to the host after the completion of executing the debugging operation.
S202e, the debugging module receives a repeated uploading command sent by the host.
S202f, the debugging module sends new reply frame information to the host according to the repeated uploading command.
It should be appreciated that the foregoing device under test 120 may implement the contents of S201-S203 and sub-steps S202a-S202 f.
In summary, the application provides a development and debugging system, a device to be tested and a debugging method, wherein the development and debugging system comprises a host and the device to be tested, the device to be tested comprises a reset interface, a debugging module and a reset module, and the host is connected with the debugging module and the reset module through the reset interface; the host is used for sending interactive data to the debugging module and the resetting module through the resetting interface; the debugging module is used for judging whether the interaction data are correct, and if so, executing debugging operation according to the interaction data; and the reset module is used for executing reset operation according to the interactive data under the condition that the communication rate of the interactive data is smaller than the reset period of the equipment to be tested. Therefore, through setting the communication rate of the interactive data, the debugging signals and the reset signals can be distinguished, so that the multiplexing of the debugging interface and the reset interface can be realized, the debugging interface is not required to be independently arranged, and the problem that the PCB space and the IC pins occupy too much is solved.
It will be appreciated by those skilled in the art that embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
While preferred embodiments of the present application have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. It is therefore intended that the following claims be interpreted as including the preferred embodiments and all such alterations and modifications as fall within the scope of the application.
It will be apparent to those skilled in the art that various modifications and variations can be made to the present application without departing from the spirit or scope of the application. Thus, it is intended that the present application also include such modifications and alterations insofar as they come within the scope of the appended claims or the equivalents thereof.
Claims (12)
1. The development and debugging system is characterized by comprising a host and equipment to be tested, wherein the equipment to be tested comprises a reset interface, a debugging module and a reset module, and the host is connected with the debugging module and the reset module through the reset interface;
the host is used for sending interactive data to the debugging module and the reset module through the reset interface;
the debugging module is used for judging whether the interaction data are correct or not, and if so, executing debugging operation according to the interaction data;
the reset module is used for executing reset operation according to the interactive data under the condition that the communication rate of the interactive data is smaller than the reset period of the equipment to be tested;
the host is also used for sending a synchronous trigger signal to the equipment to be tested;
the device to be tested is also used for sending a synchronous code to the host according to the synchronous trigger signal; the synchronous code is obtained according to the clock frequency of the equipment to be tested;
the host is also used for acquiring the communication rate of the equipment to be tested according to the synchronous code;
the host is also used for carrying out initialization setting on the basis of the communication rate and the equipment to be tested;
if the initialization setting of the host and the equipment to be tested is successful, the handshake between the host and the equipment to be tested is successful.
2. The development and debugging system of claim 1, wherein the reset module is further configured to perform a reset operation according to the interaction data if the communication rate of the interaction data is less than a preset multiple of the reset period.
3. The development and debugging system of claim 1, wherein the interaction data comprises verification information and command information;
the debugging module is also used for judging whether the check information and the command information are correct or not;
if any one of the check information and the command information is incorrect, the debugging module is further used for sending error prompt information to the host;
and if the verification information and the command information are both correct, the debugging module is further used for executing the debugging operation according to the command information.
4. The development and debugging system of claim 1, wherein the debugging module is further configured to check a status of the debugging operation and send reply frame information to the host after performing the debugging operation is completed;
the host is also used for checking whether the reply frame information is correct;
if not, the host is further configured to send a repeat upload command to the debug module through the reset interface;
the debugging module is also used for sending new reply frame information to the host according to the repeated uploading command;
and the host is further configured to stop sending the repeated upload command to the debug module through the reset interface when the reply frame information is correct or the number of times of sending the repeated upload command reaches a preset number of times.
5. The development and debugging system of claim 1, wherein the device under test is further configured to send an updated synchronization code to the host if the clock frequency of the device under test changes;
the host is also used for acquiring the updated communication rate of the equipment to be tested according to the updated synchronous code.
6. The development and debugging system of claim 5, wherein the device under test is further configured to send a frequency change signal to the host;
the host is also used for stopping communication with the device to be tested according to the frequency change signal.
7. The device to be tested is characterized by comprising a reset interface, a debugging module and a reset module, wherein the debugging module and the reset module are connected with a host through the reset interface;
the device to be tested is used for receiving the synchronous trigger signal sent by the host; sending a synchronous code to the host according to the synchronous trigger signal; the synchronous code is obtained according to the clock frequency of the equipment to be tested; the host is used for acquiring the communication rate of the equipment to be tested according to the synchronous code, and carrying out initialization setting on the basis of the communication rate and the equipment to be tested; if the initialization setting of the host and the equipment to be tested is successful, the handshake between the host and the equipment to be tested is successful;
the debugging module and the resetting module are both used for receiving the interaction data sent by the host through the resetting interface;
the debugging module is used for judging whether the interaction data are correct or not, and if so, executing debugging operation according to the interaction data;
the reset module is used for executing reset operation according to the interaction data under the condition that the communication rate of the interaction data is smaller than the reset period of the device to be tested.
8. The device under test of claim 7, wherein the interaction data comprises verification information and command information;
the debugging module is also used for judging whether the check information and the command information are correct or not;
if any one of the check information and the command information is incorrect, the debugging module is further used for sending error prompt information to the host;
and if the verification information and the command information are both correct, the debugging module is further used for executing the debugging operation according to the command information.
9. The device under test of claim 7, wherein the debug module is further configured to check a status of the debug operation and send reply frame information to the host after performing the debug operation is complete;
the debugging module is also used for receiving a repeated uploading command sent by the host; wherein the repeated uploading command is generated by the host under the condition that the reply frame information is incorrect;
the debugging module is also used for sending new reply frame information to the host according to the repeated uploading command;
and the host stops sending the repeated uploading command to the debugging module when the reply frame information is correct or the number of times of the repeated uploading command sent by the host reaches a preset number of times.
10. The method is applied to equipment to be tested, the equipment to be tested comprises a reset interface, a debugging module and a reset module, the debugging module and the reset module are connected with a host through the reset interface, and the method comprises the following steps:
the device to be tested receives a synchronous trigger signal sent by the host; sending a synchronous code to the host according to the synchronous trigger signal; the synchronous code is obtained according to the clock frequency of the equipment to be tested; the host is used for acquiring the communication rate of the equipment to be tested according to the synchronous code, and carrying out initialization setting on the basis of the communication rate and the equipment to be tested; if the initialization setting of the host and the equipment to be tested is successful, the handshake between the host and the equipment to be tested is successful;
the debugging module and the resetting module receive interaction data sent by the host;
the debugging module judges whether the interaction data is correct, if so, the debugging operation is executed according to the interaction data;
and the reset module executes reset operation according to the interaction data under the condition that the communication rate of the interaction data is smaller than the reset period of the equipment to be tested.
11. The method of claim 10, wherein the interaction data includes verification information and command information, and wherein the step of the debug module determining whether the interaction data is correct comprises:
the debugging module judges whether the check information and the command information are correct or not;
if any one of the check information and the command information is incorrect, the debugging module sends error prompt information to the host;
and if the verification information and the command information are correct, the debugging module executes the debugging operation according to the command information.
12. The method of claim 11, wherein if the verification information and the command information are both correct, the debug module performs the step of debugging operations based on the command information, the method further comprising:
the debugging module checks the state of the debugging operation and sends reply frame information to the host after the completion of executing the debugging operation;
the debugging module receives a repeated uploading command sent by the host; wherein the repeated uploading command is generated by the host under the condition that the reply frame information is incorrect;
the debugging module sends new reply frame information to the host according to the repeated uploading command;
and the host stops sending the repeated uploading command to the equipment to be tested.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110780359.5A CN113626310B (en) | 2021-07-09 | 2021-07-09 | Development and debugging system, equipment to be tested and debugging method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110780359.5A CN113626310B (en) | 2021-07-09 | 2021-07-09 | Development and debugging system, equipment to be tested and debugging method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113626310A CN113626310A (en) | 2021-11-09 |
| CN113626310B true CN113626310B (en) | 2023-11-24 |
Family
ID=78379448
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110780359.5A Active CN113626310B (en) | 2021-07-09 | 2021-07-09 | Development and debugging system, equipment to be tested and debugging method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113626310B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114564414B (en) * | 2022-04-28 | 2022-08-09 | 武汉慧联无限科技有限公司 | Debugging method, device and storage medium |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101140298A (en) * | 2007-02-27 | 2008-03-12 | 中兴通讯股份有限公司 | Reset device of test accesses terminal port of JTAG chain circuit used on board |
| US8732526B1 (en) * | 2011-06-24 | 2014-05-20 | Maxim Integrated Products, Inc. | Single-wire data interface for programming, debugging and testing a programmable element |
| CN106055497A (en) * | 2016-06-02 | 2016-10-26 | 广东盈科电子有限公司 | Communication method of circuit board and circuit board |
| CN112738259A (en) * | 2020-12-31 | 2021-04-30 | 广州航天海特***工程有限公司 | Ethernet data transmission method, device, equipment and storage medium |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8737526B2 (en) * | 2010-06-30 | 2014-05-27 | Qualcomm Incorporated | Predistortion of complex modulated waveform |
-
2021
- 2021-07-09 CN CN202110780359.5A patent/CN113626310B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101140298A (en) * | 2007-02-27 | 2008-03-12 | 中兴通讯股份有限公司 | Reset device of test accesses terminal port of JTAG chain circuit used on board |
| US8732526B1 (en) * | 2011-06-24 | 2014-05-20 | Maxim Integrated Products, Inc. | Single-wire data interface for programming, debugging and testing a programmable element |
| CN106055497A (en) * | 2016-06-02 | 2016-10-26 | 广东盈科电子有限公司 | Communication method of circuit board and circuit board |
| CN112738259A (en) * | 2020-12-31 | 2021-04-30 | 广州航天海特***工程有限公司 | Ethernet data transmission method, device, equipment and storage medium |
Non-Patent Citations (1)
| Title |
|---|
| 程明等.《无人值班变电站监控技术》.北京：中国电力出版社,1999,(第1版),219-234. * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113626310A (en) | 2021-11-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN1902596B (en) | Programmable measurement method, equipment and system for a serial point to point link | |
| US20100095159A1 (en) | Apparatus and method for automatic testing of software or digital devices | |
| CN113626310B (en) | Development and debugging system, equipment to be tested and debugging method | |
| EP1615164A2 (en) | IC card with self-diagnostic function | |
| CN100476780C (en) | Automatic method for identifying signal interfaces of electronic equipment | |
| CN113612565B (en) | Development and debugging system, handshake method and device | |
| CN113645093B (en) | Equipment to be tested, development and debugging system and communication method | |
| CN116340073B (en) | Test method, device and system | |
| CN101267350B (en) | Debugging method and debugging system | |
| CN112799887A (en) | Chip FT test system and test method | |
| US9495315B2 (en) | Information processing device and data communication method | |
| CN113986600B (en) | Test method and device for chip serial interface and chip | |
| CN106649187A (en) | Chip automatic peripheral device protocol selection method | |
| US20050256984A1 (en) | Implementation of a master loopback mode | |
| RU170434U1 (en) | Programmable JTAG - Diagnostic Module | |
| CN114996179B (en) | Graphics processor assisted management system and method | |
| US11334437B2 (en) | Method to recover an error state in a serial communication with an integrated circuit card, corresponding system and computer program product | |
| CN104038309A (en) | Simulation system communication method and simulation system | |
| CN110492979B (en) | Incremental data transmission method and device, slave and storage medium | |
| US20230011127A1 (en) | Introduction and Detection of Parity Error in a UART | |
| CN111309529B (en) | System and method for complete testing of communication links within a processor based on processor information | |
| CN113364564A (en) | Data transmission method, microprocessor, data transmission device and storage medium | |
| JP2007036850A (en) | Character recognizing circuit | |
| CN108932200B (en) | Test circuit and software debugging method | |
| CN117389806A (en) | Mainboard debugging system and method and electronic equipment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |