CN113626310A - Development and debugging system, device to be tested and debugging method - Google Patents
Development and debugging system, device to be tested and debugging method Download PDFInfo
- Publication number
- CN113626310A CN113626310A CN202110780359.5A CN202110780359A CN113626310A CN 113626310 A CN113626310 A CN 113626310A CN 202110780359 A CN202110780359 A CN 202110780359A CN 113626310 A CN113626310 A CN 113626310A
- Authority
- CN
- China
- Prior art keywords
- host
- debugging
- module
- reset
- information
- 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.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 37
- 238000011161 development Methods 0.000 title claims abstract description 23
- 238000004891 communication Methods 0.000 claims abstract description 100
- 230000002452 interceptive effect Effects 0.000 claims abstract description 87
- 238000012360 testing method Methods 0.000 claims description 166
- 230000008859 change Effects 0.000 claims description 20
- 238000012795 verification Methods 0.000 claims description 14
- 230000003993 interaction Effects 0.000 claims description 12
- 230000001360 synchronised effect Effects 0.000 claims description 12
- 230000006870 function Effects 0.000 description 30
- 238000010586 diagram Methods 0.000 description 10
- 230000008569 process Effects 0.000 description 9
- 238000004590 computer program Methods 0.000 description 7
- 238000012986 modification Methods 0.000 description 5
- 230000004048 modification Effects 0.000 description 5
- 238000012545 processing Methods 0.000 description 4
- 230000001960 triggered effect Effects 0.000 description 4
- 230000004044 response Effects 0.000 description 3
- 238000012790 confirmation Methods 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 230000000630 rising effect Effects 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000011990 functional testing Methods 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
- 238000012546 transfer Methods 0.000 description 1
Images
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, 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 interactive data is correct or not, and if so, executing debugging operation according to the interactive 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 less than the reset period of the equipment to be tested. Through the setting to the communication rate of interactive data, can distinguish debugging signal and reset signal, and then can realize debugging interface and reset interface multiplex, need not establish the debugging interface alone, solved PCB space and IC pin and taken too much problem.
Description
Technical Field
The present application relates to the field of debugging technologies, and in particular, to a development and debugging system, a device under test, and a debugging method.
Background
A typical debug interface scheme used in the industry is a standard JTAG (Joint Test Action Group) boundary scan interface, which at least includes 4 input/output lines: test clock, test mode, test data input, and test data output. Due to the requirement of occupying at least 4 debug signal lines, it is increasingly difficult to implement under the condition of increasing shortage of PCB (Printed Circuit Board) space and IC (integrated Circuit) pins caused by miniaturization of electronic products.
Although the industry has a small debug protocol suite 1149.7(IEEE Standard for Reduced-Pin and Enhanced-functional Test Access and Boundary-Scan Architecture) as defined by the IEEE (Institute of Electrical and Electronics Engineers), which provides a small sized two-wire debug protocol: 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, rather than to provide interactive debug functionality. Therefore, the JTAG protocol suite provides a number of functions that are not useful to RISC-V (fifth generation reduced instruction set computer), is not efficient enough for interactive debug transfers of RISC-V due to the number of functions that are not useful, and the two-wire debug protocol cJTAG included in this standard requires the use of special IO ports and asynchronous timing protocols, making cJTAG protocols difficult to implement.
On the one hand, arm (advanced RISC machines) proposes a SWD two-wire debug scheme. Similar to cJTAG, it can be multiplexed with two pins of the test mode and test clock of the JTAG interface. Thus also being compatible with the standard 4-wire JTAG protocol. This standard has become a de facto standard for two-wire debug 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, although the single-Wire debug scheme of STM8 is proposed, the single-Wire debug scheme is a single bus Interface Module (SWIM) protocol. However, the SWIM protocol communication rate is only fixed two 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 practicability is not high; and a debugging port is required to be independently arranged, so that certain occupation exists on the PCB space and IC pins, and the use requirement is difficult to meet under the condition of shortage of system I/O resources.
Problems existing in the prior art:
the existing debugging interfaces are independently arranged and cannot coexist with other functions at the same time, and the problem that the space of a PCB and IC pins occupy too much exists.
Disclosure of Invention
The embodiment of the application provides a development and debugging system, a device to be tested and a debugging method, and the problem that too much PCB space and IC pins are occupied is solved by multiplexing a debugging interface and a reset interface.
According to a first aspect of the embodiments of the present application, a development and debugging system is provided, where the development and debugging system includes a host and a device to be tested, the device to be tested includes a reset interface, a debugging module, and a reset module, and the host is 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 resetting module through the resetting interface;
the debugging module is used for judging whether the interactive data is correct or not, and if the interactive data is correct, executing debugging operation according to the interactive 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 less than the reset period of the equipment to be tested.
According to a second aspect of the embodiments of the present application, there is provided a device to be tested, where the device to be tested includes a reset interface, a debugging module, and a reset module, and the debugging module and the reset module are connected to a host through the reset interface;
The debugging module and the resetting module are both used for receiving interactive data sent by the host through the resetting interface;
the debugging module is used for judging whether the interactive data is correct or not, and if the interactive data is correct, executing debugging operation according to the interactive 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 less than the reset period of the equipment to be tested.
According to a third aspect of the embodiments of the present application, there is provided a debugging method, where the method is applied to a device to be tested, the device to be tested includes a reset interface, a debugging module and a reset module, the debugging module and the reset module are connected to a host through the reset interface, and the method includes:
the debugging module and the resetting module receive interactive data sent by the host;
the debugging module judges whether the interactive data is correct or not, and if the interactive data is correct, debugging operation is executed according to the interactive data;
and the reset module executes reset operation according to the interactive data under the condition that the communication rate of the interactive data is less 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 interactive data is correct or not, and if so, executing debugging operation according to the interactive 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 less than the reset period of the equipment to be tested. Therefore, the debugging signal and the reset signal can be distinguished by setting the communication rate of the interactive data, so that the multiplexing of the debugging interface and the reset interface can be realized, the debugging interface does not need to be set independently, 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 application, illustrate embodiment(s) of the application and together with the description serve to explain the application and not to limit the application. In the drawings:
Fig. 1 is a schematic structural diagram of a development and debugging system according to an embodiment of the present application;
fig. 2 is a schematic flowchart of a debugging method according to an embodiment of the present application;
fig. 3 is a schematic flowchart of another debugging method provided in the embodiment of the present application;
fig. 4 is a schematic flowchart of another debugging method provided in the embodiment of the present application.
Detailed Description
In the process of implementing the present application, the inventor finds that the current debugging interfaces are all independently arranged and are not multiplexed with other functions, and the problem that the space of a PCB and the occupation of IC pins are excessive exists.
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 a debugging signal and a reset signal by setting a communication rate of interactive data, and further can realize multiplexing of a debugging interface and a reset interface, and do not need to separately set up a debugging interface, thereby solving the problem that a PCB space and an IC pin occupy too much.
The scheme in the embodiment of the application can be implemented by adopting various computer languages, such as object-oriented programming language Java and transliterated scripting language JavaScript.
In order to make the technical solutions and advantages of the embodiments of the present application more apparent, the following further detailed description of the exemplary embodiments of the present application with reference to the accompanying drawings makes it clear that the described embodiments are only a part of the embodiments of the present application, and are not exhaustive of all embodiments. It should be noted that the embodiments and features of the embodiments in the present application may be combined with each other without conflict.
Referring to fig. 1, which is a schematic structural diagram of a development and debugging system 100 according to an embodiment of the present disclosure, 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.
The host 110 is configured to send the interaction data to the debugging module 122 and the reset module 123 through the reset interface 121; the debugging module 122 is configured to determine whether the interactive data is correct, and if so, execute a debugging operation according to the interactive data; the reset module 123 is configured to perform a reset operation according to the interactive data when the communication rate of the interactive data is less than the reset period of the device under test 120.
It should be understood that, when the host 110 and the device under test 120 perform the debugging operation, since the debugging interface of the device under test 120 is multiplexed with the reset interface 121, the debugging signal is prevented from falsely triggering the reset function of the device under test 120. If the interactive data sent by the host 110 is a debugging signal, the communication rate of the interactive 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. Since the reset module 123 is triggered only by the interactive data with the communication rate less 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.
Here, the reset period may be understood as a period of a reset signal.
In order to further prevent the debug signal from falsely triggering the device under test 120 to reset, the reset module 123 is further configured to execute a reset operation according to the interactive data when the communication rate of the interactive 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 interactive 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 10 Kbps.
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. Therefore, errors of the debug signal can be avoided, and the reset module 123 is triggered by mistake to execute the reset operation.
It should be understood that the debug signal and the reset signal are distinguished other than by setting the communication rate of the interactive data in accordance with the period of the reset signal; the mode of setting the level width of the interactive data according to the level width of the reset signal can be adopted to newly distinguish the debugging signal from the reset signal.
For example, the level width of the debug signal should be smaller than the level width of the reset signal, and 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, the reset function can be triggered; in order to avoid the debug signal from triggering the reset function by mistake, the low level width of the debug signal should be smaller than the low level width of the reset signal.
In this embodiment, both the debugging module 122 and the resetting module 123 receive the interactive data sent by the host 110, that is, when the interactive data is a resetting signal, both the debugging module 122 and the resetting module 123 receive the resetting signal, the debugging module 122 determines whether the resetting signal is correct, and since the resetting signal is not a debugging signal, the debugging module 122 determines that the resetting signal is incorrect, and does not perform a debugging operation; the reset module 123 is triggered to reset by the reset signal. When the interactive data is a debugging signal, the debugging module 122 and the resetting module 123 both receive the debugging signal, the debugging module 122 determines whether the debugging signal is correct, and executes debugging operation under the condition that the debugging signal is correct; in the event that the debug signal is incorrect, debug module 122 will not perform the debug operation; since the communication rate of the debug signal is greater than the reset period, the reset module 123 does not trigger the reset operation by the debug signal.
In this embodiment, the interactive data includes verification information and command information. In other words, when the interactive data is a debug signal, the debug signal includes check information and command information.
The debugging module 122 is further configured to determine whether the verification information and the command information are correct; if any one of the check information and the command information is incorrect, the debugging module 122 is further configured to send an error prompt message to the host 110; if the verification information and the command information are both correct, the debugging module 122 is further configured to execute a debugging operation according to the command information.
It should be understood that the debugging module 122 checks whether the check information is correct, and if not, sends an error prompt message to the host 110; if the verification information is correct, the debugging module 122 checks whether the command information is correct, and if not, sends an error prompt message to the host 110; if the command information is correct, the debugging module 122 executes the debugging operation according to the command information.
In this embodiment, the debugging module 122 is further configured to check a state of the debugging operation, and send the multiframe information back to the host 110 after the debugging operation is completed; the host 110 is also used to check 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 debugging 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 debugging state of the debugging module 122, so that the host 110 can know the debugging state of the device under test 120 in real time, determine whether a fault exists in the debugging process of the device under test 120, and respond in time if a fault exists.
The host 110 sends the repeat upload command to the debug module 122 again when the reply frame information is incorrect, and stops sending the repeat upload command to the debug module 122 when the reply frame information is correct or the number of times of sending the repeat upload command reaches a preset number of times.
It should be understood that the reply frame information includes the check information, after the host 110 receives the reply frame information, the host 110 checks whether the check information of the reply frame information is correct, if not, the host 110 sends a repeat upload command to the device under test 120, and the device under test 120 sends new reply frame information to the host 110 again according to the repeat upload command; the host 110 determines whether the check information of the new reply frame information is correct according to the new reply frame information sent again by the device under test 120, if not, the host 110 continues to send the repeat upload command to the device under test 120, and repeats the above operations until the number of times that the host 110 continuously sends the repeat upload command to the device under test 120 reaches the preset number of times, or the check information of the reply frame information received by the host 110 is correct.
It should be understood that if the command information is executed, the device under test 120 sends the multiframe information back to the host 110 in the following two ways. One of the methods is as follows: the reply frame information includes confirmation information, and if the command information is executed, 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 confirmation information to the host 110. The other mode is as follows: the reply frame information includes reply data, and if the command information is executed 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 debugging signal can adopt an encoding data format, namely the debugging signal format can comprise a 1 start bit, 8 data bits, a 1 odd check bit and a 1 stop bit, the command information is set in the data bits, and the check information is set in the odd check bits; if the bitwise XOR of the check information and the data is 1, the correct check information is shown, and if the bitwise XOR of the check information and the data is 0, the wrong check information is shown; the command information format may include a command word, the result of the bitwise negation of the command word, an optional data payload, and an accumulated checksum; the response data includes the command word in the command message and the data payload that needs to be returned to the host 110.
The command word contains the following contents: the method comprises the steps of controlling an instruction, setting the instruction, resetting a debugging signal, acquiring an information instruction, safety information and a communication rate setting instruction; the control instruction is used for controlling shutdown, break-point, memory writing, program running and the like of the control part of the device to be tested 120; the setting instruction includes reading and writing data such as a memory and a register value of the data portion of the device under test 120, so that the host 110 can perform functions such as programming and parameter setting on the device under test 120; the reset debugging signal is a reset debugging signal in a selectable reset domain range of the reset module 123 of the device to be tested 120, so that the device to be tested 120 which may work abnormally can be reset in a soft mode or a hard mode and return to a normal state; the acquired information instruction is an instruction sent by initialization setting between the host 110 and the device to be tested 120 in the handshake flow, and the host 110 can acquire the hardware model, the core model, the available revision and the like of the device to be tested 120 by acquiring the information instruction; the security information may include a password, and the host 110 and the device under test 120 may exchange respective preset passwords to realize an authentication function, that is, whether the host 110 has the right to access the device under test 120 may be verified, and the device under test 120 may also deny the authorized debugging access; the host 110 can set the communication rate of the device under test 120 according to the communication rate setting instruction, and can select different communication rates in different scenes to improve the stability and speed of communication; the data payload may be understood as specific data content stored on 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 an encoded data format, and the host 110 can be designed to multiplex serial transceivers of existing systems without requiring low levels of a particular length to occur with programs or special hardware, so that the host 110 can be implemented relatively simply using a common platform without requiring a complete redesign.
Before the host 110 and the device under test 120 perform normal communication, a handshake process needs to be performed between the host 110 and the device under test 120, and after the 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 process may be: 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 setup of the host 110 and the device under test 120 is successful, the handshake between the host 110 and the device under test 120 is successful.
It should be understood that the synchronous trigger signal may be a low level with a certain length, and may also 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, and in order to avoid the synchronization trigger signal from triggering the reset function by mistake, the level width of the synchronization trigger signal should be smaller than the level width of the reset signal. 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 a 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 dut 120 receives the synchronization trigger signal, the synchronization trigger signal is treated as an error frame, and the dut 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 obtained by frequency division according to the clock frequency, and the communication rate of the device under test 120 may be set according to an actual situation.
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 1 Mbps.
The host 110 measures the pulse width length of the synchronization 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, wherein the timer starts to count time when the host 110 detects a rising edge of the synchronization code, and stops counting time 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 counted by the timer between the adjacent rising edge and the falling edge of the synchronous code.
After obtaining the communication rate of the device under test 120, the host 110 may perform data transmission using the communication rate of the device under test 120, so as to achieve the communication rate consistency 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 the host 110 and the device under test 120 achieve communication synchronization, data interaction may be performed between the host 110 and the device under test 120 to achieve initialization setting. The principle of implementing the initialization setup 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 obtaining instruction; the host 110 performs initialization setting according to the feature information.
The initialization setting may be that the host 110 determines the functions supported by the device under test 120 according to the feature information of the device under test 120, and the host 110 sends the instruction according to the functions supported by the device under test 120. The feature information includes a chip model, a core model, and supported function information of the device under test 120.
It should be understood that the host 110 sends the information obtaining instruction to the device under test 120 based on the communication rate of the device under test 120, and because the host 110 sends the instructed communication rate and the communication rate of the device under test 120, the device under test 120 can correctly receive the information obtaining instruction and feed back the characteristic information to the host 110 according to the information obtaining instruction. The feature information includes a chip model, a core model, and function information of the device to be tested 120, the host 110 can determine a function supported by the device to be tested 120 based on the chip model, the core model, and the function information of the device to be tested 120, and the host 110 sends a corresponding instruction according to the function supported by the device to be tested 120.
In an alternative embodiment, the host 110 may also send feature information of the host 110 to the 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 a debugging specification followed by the host 110, supported function information, and the like.
The handshake flow includes communication rate synchronization and initialization setting, and before the initialization setting, 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 implemented by moving the host 110, so that the chip area of the device under test 120 can be reduced, the timing sequence can be improved, and the verification is simpler.
In an optional embodiment, since the clock frequency of the device under test 120 changes, the corresponding communication rate of the device under test 120 also changes, and since the host 110 further communicates with the device under test 120 based on the communication rate of the device under test 120 before the change, the communication rate between the host 110 and the device under test 120 is in an unsynchronized state. In the case of a change in the communication rate of the device under test 120, synchronization between the host 110 and the device under test 120 can be maintained. The application also provides a repeated handshake flow, and the working principle of the repeated handshake flow 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 master 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 will change accordingly. Under the condition that the communication rate of the device under test 120 changes, if the host 110 performs data interaction with the device under test 120 according to the corresponding communication rate before the clock frequency of the device under test 120 changes, the host 110 and the device under test 120 are not in a communication synchronization state due to the fact that the communication rate of the host 110 is not consistent with the communication rate of the device under test 120, and normal communication between the host 110 and the device under test 120 is not possible. Therefore, after the clock frequency of the dut 120 is changed, the dut 120 actively sends 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.
As can be seen, through the above re-handshake process, when the clock frequency of the device under test 120 changes, 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 updated correspondingly. It can be ensured that synchronization between the host 110 and the device under test 120 can be maintained in the case 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 also configured to stop communicating with the device under test 120 according to the frequency change signal.
It should be understood that the device under test 120 may generate the frequency change signal in response to a clock frequency change instruction, where the clock frequency change instruction is generated by the device under test 120 in response to an external operation, and the external operation may be understood as a clock frequency change operation performed 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 will change according to the clock frequency change instruction, so as to send the frequency change signal to the host 110 before the clock frequency of the device under test 120 changes.
Since the clock frequency of the device under test 120 will change, a 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 is avoided. Therefore, 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 and the device under test 120 are resynchronized, the host 110 continues to communicate with the device under test 120.
After the handshake flow or the re-handshake flow is finished, the host 110 sends the interactive 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 of the device under test 120 will change, that is, under the condition that the device under test 120 does not actively send the frequency change signal, the host 110 may actively go through the handshake flow again to avoid the unsynchronized communication between the host 110 and the device under test 120.
The principle of the host 110 actively walking once again through the handshake flow is as follows: if the device under test 120 feeds back the interaction data to the host 110 overtime or an error, 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 the 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 also changed correspondingly, and the host 110 further communicates with the device under test 120 based on the corresponding communication rate before the clock frequency of the device under test 120 is changed, and the communication rate of the host 110 is not consistent 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.
Under the condition that the host 110 and the device under test 120 are not in a communication synchronization state, the interaction data fed back to the host 110 by the device under test 120 may have a timeout or error phenomenon; 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 goes through the handshake process again to complete the synchronization between the host 110 and the device under test 120.
The device under test 120 sends the updated synchronization code to the device under test 120 again according to the synchronization trigger signal sent by the host 110, and the updated synchronization code is obtained according to the changed clock frequency of the device under test 120. 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, and the communication rate of the device under test 120 is correspondingly changed when the clock frequency of the device under test 120 is changed, the synchronization code sent by the device under test 120 to the host 110 at the changed communication rate is also correspondingly changed.
Since the device under test 120 sends 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 between the host 110 and the device under test 120 is completed again.
In the process of performing the handshake flow, the host 110 and the device under test 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 under test 120 needs to be set, that is, the synchronized communication rate of the host 110 and the device under test 120 needs to be set. If the reset operation is needed, the synchronous communication rate is smaller than the reset period; if debugging operation is needed, the communication speed after synchronization is larger than the reset period.
It should be understood that the host 110 may be a burner (e.g., a computer and a debugger) and an off-line programmer, and the slave may be a chip to be tested and a chip to be programmed.
Next, on the basis of the device to be tested 120 shown in fig. 1, an embodiment of the present application provides a debugging method, please refer to fig. 2, where fig. 2 is a schematic flowchart of the debugging method provided in the embodiment of the present application, and the debugging method may include the following steps:
s201, the debugging module and the resetting module receive interactive data sent by the host.
S202, the debugging module judges whether the interactive data is correct or not, and if the interactive data is correct, the debugging module executes debugging operation according to the interactive data.
S203, the reset module executes reset operation according to the interactive data under the condition that the communication rate of the interactive data is less 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 the step 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 an error prompt message to the host.
S202c, if the verification information and the command information are both correct, the debugging module executes the debugging operation according to the command information.
Referring to fig. 4, which is a flowchart illustrating another debugging method according to an embodiment of the present application, based on fig. 3, S202 further includes the following steps:
s202d, the debug module checks the status of the debug operation and sends the multiframe information back to the host after the completion of executing the debug operation.
S202e, the debug module receives the repeat upload command sent by the host.
S202f, the debug module sends new reply frame information to the host according to the repeat upload command.
It should be understood that the aforementioned dut 120 may implement the contents of steps S201-S203 and substeps S202a-S202 f.
In summary, the present application provides a development and debugging system, a device to be tested, and a debugging method, where the development and debugging system includes a host and a device to be tested, the device to be tested includes a reset interface, a debugging module, and a reset module, and the host is 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 resetting module through the resetting interface; the debugging module is used for judging whether the interactive data is correct or not, and if so, executing debugging operation according to the interactive 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 less than the reset period of the equipment to be tested. Therefore, the debugging signal and the reset signal can be distinguished by setting the communication rate of the interactive data, so that the multiplexing of the debugging interface and the reset interface can be realized, the debugging interface does not need to be set independently, and the problem that the PCB space and the IC pins occupy too much is solved.
As will be appreciated by one skilled in the art, 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 flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams 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 the 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. Therefore, it is intended that the appended claims be interpreted as including preferred embodiments and all alterations and modifications as fall within the scope of the application.
It will be apparent to those skilled in the art that various changes and modifications may be made in the present application without departing from the spirit and scope of the application. Thus, if such modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is intended to include such modifications and variations as well.
Claims (13)
1. A development and debugging system is characterized by comprising a host and a device to be tested, wherein 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 interactive data is correct or not, and if the interactive data is correct, executing debugging operation according to the interactive 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 less than the reset period of the equipment to be tested.
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 a communication rate of the interaction data is less than a preset multiple of the reset period.
3. The development 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 verification 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 the status of the debugging operation and send multiframe information back to the host after the debugging operation is completed;
the host is also used for checking whether the reply frame information is correct;
if not, the host is also used for sending a repeated uploading command to the debugging 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;
the host is further configured to stop sending the repeat upload command to the debugging module through the reset interface when the reply frame information is correct or the number of times of sending the repeat upload command reaches a preset number of times.
5. The development and debugging system of claim 1, wherein the host is further configured to send a synchronization trigger signal to the device under test;
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 codes;
The host is also used for carrying out initialization setting on the equipment to be tested based on the communication rate;
and 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.
6. The development and debugging system of claim 5, wherein if the clock frequency of the device under test changes, the device under test is further configured to send updated synchronization codes to the host;
and the host is also used for acquiring the updated communication rate of the equipment to be tested according to the updated synchronous code.
7. The development and debugging system of claim 6, wherein the device under test is further configured to send a frequency change signal to the host;
the host is further used for stopping communication with the equipment to be tested according to the frequency change signal.
8. 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 debugging module and the resetting module are both used for receiving interactive data sent by the host through the resetting interface;
The debugging module is used for judging whether the interactive data is correct or not, and if the interactive data is correct, executing debugging operation according to the interactive 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 less than the reset period of the equipment to be tested.
9. The device under test of claim 8, wherein the interaction data comprises verification information and command information;
the debugging module is also used for judging whether the verification 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.
10. The device under test of claim 8, wherein the debug module is further configured to check a status of the debug operation, and send multiframe information back to the host after the debug operation is performed;
the debugging module is also used for receiving a repeated uploading command sent by the host; wherein the repeat upload command is generated by the host if 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.
11. A debugging 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 debugging module and the resetting module receive interactive data sent by the host;
the debugging module judges whether the interactive data is correct or not, and if the interactive data is correct, debugging operation is executed according to the interactive data;
and the reset module executes reset operation according to the interactive data under the condition that the communication rate of the interactive data is less than the reset period of the equipment to be tested.
12. The method of claim 11, wherein the interactive data comprises check information and command information, and the step of the debug module determining whether the interactive data is correct comprises:
The debugging module judges whether the verification 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 both correct, the debugging module executes the debugging operation according to the command information.
13. The method of claim 12, wherein after the step of the debug module performing the debug operation according to the command information if the check information and the command information are both correct, the method further comprises:
the debugging module checks the state of the debugging operation and sends multiframe information back to the host after the debugging operation is executed;
the debugging module receives a repeated uploading command sent by the host; wherein the repeat upload command is generated by the host if 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 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.
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 true CN113626310A (en) | 2021-11-09 |
| CN113626310B 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) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114564414A (en) * | 2022-04-28 | 2022-05-31 | 武汉慧联无限科技有限公司 | Debugging method, device and storage medium |
Citations (5)
| 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 |
| US20120002752A1 (en) * | 2010-06-30 | 2012-01-05 | Qualcomm Incorporated | Predistortion of complex modulated waveform |
| 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 |
-
2021
- 2021-07-09 CN CN202110780359.5A patent/CN113626310B/en active Active
Patent Citations (5)
| 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 |
| US20120002752A1 (en) * | 2010-06-30 | 2012-01-05 | Qualcomm Incorporated | Predistortion of complex modulated waveform |
| 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 |
|---|
| 程明等: "《无人值班变电站监控技术》", vol. 1, 北京：中国电力出版社, pages: 219 - 234 * |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114564414A (en) * | 2022-04-28 | 2022-05-31 | 武汉慧联无限科技有限公司 | Debugging method, device and storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113626310B (en) | 2023-11-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6977960B2 (en) | Self test circuit for evaluating a high-speed serial interface | |
| CN1902596B (en) | Programmable measurement method, equipment and system for a serial point to point link | |
| US20050246475A1 (en) | Method and apparatus for constructing wired-and bus systems | |
| CN108600047B (en) | Serial transmission chip and SERDES circuit testing method | |
| CN113626310B (en) | Development and debugging system, equipment to be tested and debugging method | |
| CN115496018A (en) | Multi-version verification method, device and equipment for SoC (System on chip) | |
| CN112286750A (en) | GPIO (general purpose input/output) verification method and device, electronic equipment and medium | |
| WO2008011326A1 (en) | Detecting and differentiating sata loopback modes | |
| CN112015119B (en) | Debug control circuit and debug control method | |
| CN116340073B (en) | Test method, device and system | |
| CN113612565B (en) | Development and debugging system, handshake method and device | |
| CN113176966A (en) | System and method for checking validity of SPI (Serial peripheral interface) received data | |
| CN113645093B (en) | Equipment to be tested, development and debugging system and communication method | |
| CN116226008A (en) | Port address configurator, configuration method and terminal | |
| CN113986600B (en) | Test method and device for chip serial interface and chip | |
| US9495315B2 (en) | Information processing device and data communication method | |
| CN115599727A (en) | PCIE equipment bandwidth allocation method and related device | |
| RU170434U1 (en) | Programmable JTAG - Diagnostic Module | |
| US5590371A (en) | Serial communication circuit on an LSI chip and communicating with another microcomputer on the chip | |
| CN117933153B (en) | I3C bus verification system | |
| CN109101238B (en) | Intelligent deployment method for embedded simulation program of digital spacecraft | |
| CN112380119A (en) | Chip, programming debugger, system and method for locking programming debugging entry | |
| KR20160058709A (en) | Control device for i²c slave device | |
| JP2007036850A (en) | Character recognizing circuit | |
| Le | Porting and Optimization of Kvaser CANopen Stack for STM32 Microcontrollers |
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 |