Communication debugging method and device, electronic equipment and storage medium

Abstract

The invention relates to the technical field of communication, and discloses a communication debugging method and device, electronic equipment and a storage medium, the method is applied to tested equipment, the method comprises the following steps: receiving a debugging instruction sent by a debugging client, the debugging instruction comprising original protocol data and a check code; verifying the original protocol data by using the verification code, and if the verification of the original protocol data fails, detecting an error position in the original protocol data; updating the original data corresponding to the error position in the original protocol data to obtain target protocol data; and executing a corresponding debugging command based on the target protocol data. According to the invention, the problems that the existing scheme only relieves from the external interference level, the defect that the JTAG protocol has no verification function is not solved, and communication errors caused by wrong data transmission cannot be avoided fundamentally are solved.

Description

Technical Field

[0001] The present invention relates to the field of communication technology, and in particular to a communication debugging method, device, electronic equipment and storage medium. Background Art

[0002] With the rapid development of semiconductor technology, IC chips are increasingly used in various electronic devices. Chips are also becoming increasingly miniaturized and complex in function, making it difficult for the chips themselves to complete debugging work independently. They must rely on external debugging clients to perform functional debugging and fault diagnosis.

[0003] Currently, the JTAG protocol, a widely used communication protocol between debugging clients and chips, lacks a parity bit function. When data is lost or erroneous due to interference, it cannot be verified. The erroneous data will continue to be transmitted to the chip or debugging client, causing communication errors and severely restricting chip debugging efficiency. Existing technologies primarily reduce the impact of interference by reducing the JTAG communication frequency and increasing signal shielding. However, these methods only mitigate external interference and cannot fundamentally eliminate the adverse effects of erroneous data on chip debugging. Summary of the Invention

[0004] In view of this, an embodiment of the present invention provides a communication debugging method, device, electronic device and storage medium to solve the problem that the existing solution only alleviates the external interference level, does not solve the defect that the JTAG protocol itself has no verification function, and cannot fundamentally avoid the problem of communication errors caused by erroneous data transmission.

[0005] In a first aspect, an embodiment of the present invention provides a communication debugging method, which is applied to a device under test and includes:

[0006] Receiving a debugging instruction sent by a debugging client, wherein the debugging instruction includes original protocol data and a check code;

[0007] Verifying the original protocol data using the verification code, and if the verification of the original protocol data fails, detecting an error position in the original protocol data;

[0008] Updating the original data corresponding to the error position in the original protocol data to obtain target protocol data;

[0009] Execute corresponding debugging commands based on the target protocol data.

[0010] Furthermore, the verifying the original protocol data using the verification code includes:

[0011] Performing a division operation based on the original protocol data to obtain a first remainder;

[0012] The first remainder is compared with the check code to obtain a comparison result, wherein if the comparison result is that the first remainder is consistent with the check code, the verification is successful; or if the comparison result is that the first remainder is inconsistent with the check code, the verification fails.

[0013] Furthermore, the detecting of the error position in the original protocol data includes:

[0014] Summing the first remainder and the check code to obtain a binary code;

[0015] A long division operation is performed on the binary code to obtain a second remainder, and a position corresponding to the second remainder is used as the error position.

[0016] Furthermore, the detecting of the error position in the original protocol data includes:

[0017] Obtaining a pre-established time series, wherein the time series stores historical protocol data and corresponding timestamps;

[0018] Use a sliding window to select a window of preset length on the time series data and calculate the statistical characteristics of the data in the window;

[0019] Compare the statistical characteristics of the data in the window with the preset threshold to determine whether there are abnormal fluctuations;

[0020] If an abnormal fluctuation is detected, the error position is detected within the window range where the abnormal fluctuation is located.

[0021] Furthermore, the updating of the original data corresponding to the error position in the original protocol data to obtain the target protocol data includes:

[0022] Obtaining original data corresponding to an error position in the original protocol data;

[0023] Inverting the original data to obtain updated data, and replacing the original data at the error position with the updated data to obtain updated original protocol data;

[0024] Verifying the updated original protocol data using the verification code;

[0025] If the updated original protocol data is successfully verified, the updated original protocol data is used as the target protocol data.

[0026] Furthermore, the method further comprises:

[0027] If no error location in the original protocol data is detected, discarding the original protocol data and sending error information to the debugging client, wherein the debugging client determines whether to resend the debugging instruction based on the error information;

[0028] If the debugging instruction resent by the debugging client is received within a preset time period, the corresponding debugging command is executed based on the protocol data in the debugging instruction.

[0029] Furthermore, the method further comprises:

[0030] If no resent debugging instruction is received within a preset time period, detecting the network connection between the device under test and the debugging client;

[0031] If the network connection status is connection failure, releasing the resources occupied by the debugging instruction;

[0032] Periodically monitor the network connection status between the debugging client and the debugging client, and if the network connection status is successful, actively send task prompt information to the debugging client, wherein the task prompt information is used to request the debugging client to resend the debugging instruction.

[0033] In a second aspect, an embodiment of the present invention provides a communication debugging device, the device comprising:

[0034] A receiving module, configured to receive a debugging instruction sent by a debugging client, wherein the debugging instruction includes original protocol data and a check code;

[0035] a verification module, configured to verify the original protocol data using the verification code, and if the verification of the original protocol data fails, detect an error position in the original protocol data;

[0036] An updating module, configured to update the original data corresponding to the error position in the original protocol data to obtain target protocol data;

[0037] An execution module is used to execute corresponding debugging commands based on the target protocol data.

[0038] In a third aspect, an embodiment of the present invention provides an electronic device comprising: a memory and a processor, the memory and the processor being communicatively connected to each other, computer instructions being stored in the memory, and the processor executing the method of the first aspect or any corresponding embodiment thereof by executing the computer instructions.

[0039] In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium having computer instructions stored thereon, the computer instructions being used to enable a computer to execute the method of the first aspect or any corresponding embodiment thereof.

[0040] The method provided in the embodiment of the present application dynamically embeds the check code into the timing idle signal of the JTAG protocol (such as the TMS low-level period) through this embodiment, thereby realizing the synchronous separation and verification of data and the check code at the receiving end, thereby solving the problem of reduced transmission efficiency due to the check bit occupying additional bandwidth in traditional debugging communications. Combining the error correction mechanism (such as single-bit inversion) with the error location algorithm (such as the remainder location method), it is possible to complete error detection and repair within a single transmission cycle, reduce the probability of data retransmission, and significantly improve the debugging efficiency in high-interference environments. For example, in the CRC-16 check scenario, this method can cover most of the single-bit error correction requirements while maintaining the native timing compatibility of the JTAG protocol. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the specific embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0042] Figure 1 is a flow chart of a communication debugging method according to some embodiments of the present invention;

[0043] Figure 2 is a flow chart of another communication debugging method according to some embodiments of the present invention;

[0044] Figure 3 is a flow chart of another communication debugging method according to some embodiments of the present invention;

[0045] Figure 4 is a structural block diagram of a communication debugging method and apparatus according to an embodiment of the present invention;

[0046] Figure 5 FIG. 4 is a schematic diagram of the hardware structure of an electronic device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0047] To make the purpose, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without making creative efforts shall fall within the scope of protection of the present invention.

[0048] According to an embodiment of the present invention, an embodiment of a communication debugging method is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0049] In this embodiment, a communication debugging method is provided. Figure 1 : is a flow chart of a communication debugging method according to an embodiment of the present invention. Figure 1 As shown, the process includes the following steps:

[0050] Step S101: receiving a debugging instruction sent by a debugging client, wherein the debugging instruction includes original protocol data and a check code.

[0051] In an embodiment of the present application, the chip side receives debugging instructions through the TDI (Test Data Input) and TMS (Test Mode Select) signal lines of the JTAG interface. In specific implementation, the debugging client merges the original protocol data and the check code into the JTAG protocol frame according to the preset check mode (such as CRC, parity check, etc.). When the chip detects that the JTAG state machine enters the Shift DR (Shift Data Register) state, the TMS signal line transmits the check data by dynamically inserting the check bit during the continuous period of maintaining the low level, while the TDI signal line transmits the original data according to the protocol specification. During the receiving process, the chip side first samples the TDI and TMS signals through the clock synchronization module (such as TCK signal edge trigger) to ensure data timing alignment; then, according to the check rules (such as check bit length, insertion position) negotiated in advance with the debugging client, the check code is extracted from the TMS signal, and the original protocol data is separated from the TDI signal. For example, if CRC-8 checksum is used with an 8-bit checksum, in the Shift DR state, the first eight clock cycles of the TMS carry the checksum, while the subsequent cycles remain low. During this phase, the TDI transmits only the original data. The chip separates the data from the checksum through hardware logic or a firmware parsing module, temporarily storing both in a buffer to provide input for subsequent verification processes. This process fully utilizes the timing characteristics of the JTAG protocol, enabling efficient embedding and reception of checksum data without increasing transmission cycles.

[0052] Step S102: Verify the original protocol data using the verification code. If the verification of the original protocol data fails, detect the error position in the original protocol data.

[0053] In an embodiment of the present application, the verification process is implemented based on a preset error correction algorithm (such as CRC). Specifically, after the chip side receives the debugging instruction, it first performs an operation that matches the verification algorithm on the original protocol data. Taking CRC as an example, the chip regards the original data as a polynomial, performs modulo 2 division with the generating polynomial, and obtains the first remainder. Subsequently, the first remainder is compared bit by bit with the check code attached to the debugging instruction: if the two are consistent, the verification is successful; if they are inconsistent, it is determined that there is a transmission error in the data. When the verification fails, the error position is further detected by the "remainder positioning method": the first remainder is binary summed with the received check code to generate an error pattern code; the long division operation of the generating polynomial is performed on the code again, and the value of the second remainder obtained directly corresponds to the erroneous bit in the data stream. For example, if the second remainder is a decimal value of 5, it indicates that there is a bit flip in the 5th bit of data. This method accurately locates errors through mathematical operations without relying on redundant data or historical information, significantly improving the error correction efficiency.

[0054] Step S103: updating the original data corresponding to the error position in the original protocol data to obtain target protocol data.

[0055] After determining the error location, the chip side starts the data repair process. First, the original bit data corresponding to the error location is extracted, and a single-bit inversion operation is performed (such as "0" becomes "1" or vice versa). The updated data is reorganized into a protocol data frame, and the same verification algorithm is used again for secondary verification: the remainder of the updated data is calculated and compared with the original verification code. If the secondary verification is successful, the corrected data is marked as the target protocol data; if it still fails, it indicates that there are multiple bit errors or the verification algorithm does not match. At this time, steps S102-S103 can be iteratively executed to complete the error correction through multiple remainder positioning and correction attempts. For example, under the CRC-8 algorithm, the error correction success rate of single-bit errors can reach 100%, while double-bit errors can improve fault tolerance through extended algorithms (such as CRC-16).

[0056] Step S104: executing corresponding debugging commands based on the target protocol data.

[0057] After the target protocol data passes verification, the chip side parses its content and maps it into specific debugging operation instructions. The execution process is divided into three stages: 1) Instruction decoding: The protocol data is disassembled into state machine control signals (TMS, TCK) and data input signals (TDI) according to the JTAG standard to ensure compatibility with the chip's internal debugging interface; 2) Authority verification: Check the access rights of the debugging instructions to prevent unauthorized operations (such as writing to security registers); 3) Instruction execution: Drive the internal logic unit of the chip to complete debugging actions (such as register reading and writing, breakpoint setting), and return the execution results to the debugging client according to the verified JTAG protocol. If a hardware abnormality occurs during execution (such as voltage fluctuation), the chip automatically triggers a safe rollback mechanism to restore to the state before the instruction execution, avoiding system instability caused by partial execution.

[0058] The method provided in the embodiment of the present application dynamically embeds the check code into the timing idle signal of the JTAG protocol (such as the TMS low-level period) through this embodiment, thereby realizing the synchronous separation and verification of data and the check code at the receiving end, thereby solving the problem of reduced transmission efficiency due to the check bit occupying additional bandwidth in traditional debugging communications. Combining the error correction mechanism (such as single-bit inversion) with the error location algorithm (such as the remainder location method), it is possible to complete error detection and repair within a single transmission cycle, reduce the probability of data retransmission, and significantly improve the debugging efficiency in high-interference environments. For example, in the CRC-16 check scenario, this method can cover most of the single-bit error correction requirements while maintaining the native timing compatibility of the JTAG protocol.

[0059] In an embodiment of the present application, the original protocol data is verified using a check code, including: performing a division operation based on the original protocol data to obtain a first remainder; comparing the first remainder with the check code to obtain a comparison result, wherein if the comparison result is that the first remainder is consistent with the check code, the verification is successful; or, if the comparison result is that the first remainder is inconsistent with the check code, the verification fails.

[0060] Specifically, first, based on the selected verification algorithm (such as CRC), the corresponding generator polynomial is determined. This generator polynomial is used to define the division operation rules. Next, the original protocol data is treated as a binary sequence, followed by a check code (i.e., the check code sent by the debug client). Modulo-2 division (carry-free addition and subtraction) is performed on this binary sequence to obtain the first remainder. The modulo-2 division here follows the polynomial division rules, aligning the highest bit in each operation and performing subtraction through an exclusive-OR operation. Subsequently, the calculated first remainder is compared bit by bit with the check code sent by the debug client. If the two are completely consistent, it indicates that no errors occurred during the transmission of the original protocol data, the verification is successful, and the instruction execution process can proceed. If there is any inconsistency, the verification is considered to have failed, triggering the error location and correction mechanism. This process strictly verifies data integrity through mathematical operations, ensuring that debug instructions are executed only when the data is accurate, effectively avoiding erroneous execution problems caused by signal interference.

[0061] The method provided in the embodiment of the present application converts data verification into a polynomial division operation (such as modulo 2 division) and directly implements the remainder calculation using a hardware logic circuit, thereby avoiding the delay problem of software verification. For example, when the CRC check module is integrated into the FPGA, only a small number of clock cycles are required to complete the remainder calculation of more data, thereby improving the operation speed. At the same time, the remainder comparison mechanism can accurately distinguish between random interference and systematic errors. For example, in the electromagnetic interference scenario, this method can effectively filter out occasional verification failures caused by transient noise and reduce the false positive rate.

[0062] In an embodiment of the present application, detecting the error location in the original protocol data includes the following steps A1-A2:

[0063] Step A1: performing summation based on the first remainder and the check code to obtain a binary code.

[0064] Specifically, during the data transmission verification phase, after the receiver (e.g., the chip) receives the protocol data with checksum sent by the debug client, it performs a division operation based on the selected checksum type (e.g., CRC checksum). For example, in the case of CRC checksum, the receiver divides the received data by a specific generator polynomial to obtain a remainder, which is the "first remainder." Furthermore, when the debug client sends data, it appends a checksum (again, in the case of CRC checksum, this checksum is obtained by performing the same CRC calculation on the original data). The receiver then sums the obtained first remainder with the checksum appended by the debug client. Since both numbers are stored and transmitted in binary form, the summation is also performed at the binary level, ultimately resulting in a new binary code. For example, if the first remainder is "0101" in binary and the checksum is "1010" in binary, the resulting binary code is "1111."

[0065] Step A2: performing a long division operation on the binary code to obtain a second remainder, and taking the position corresponding to the second remainder as the error position.

[0066] Specifically, after obtaining the binary code, the receiver will perform long division on it again. This long division operation is also performed according to the rules corresponding to the selected checksum type. For example, in a CRC check, the same generator polynomial used in the remainder calculation is used as the divisor.

[0067] After the long division operation, a new remainder is obtained. This remainder is called the "second remainder." The position of this second remainder in the binary sequence represents the position of the error in the original protocol data. For example, if the second remainder corresponds to the third bit in the binary code, then it means that there is an error in the third bit of the original protocol data.

[0068] The method provided by the embodiment of the present application enables the receiver to accurately detect the location of errors in the original protocol data through this process, providing a key basis for subsequent data error correction. During the subsequent error correction process, the receiver can correct the data based on the detected error location and then recalculate the checksum to ensure the accuracy and integrity of the data, effectively reducing the problems caused by data transmission errors and improving the reliability and security of the entire debugging communication system.

[0069] In an embodiment of the present application, detecting the error location in the original protocol data includes the following steps B1-B4:

[0070] Step B1: Obtain a pre-established time series, which stores historical protocol data and corresponding timestamps.

[0071] Specifically, first, during the communication process between the debugging client and the chip, the system will collect and record all transmitted protocol data (including TDI / TDO signal data, check bits, control signals, etc.) in real time, and generate an accurate timestamp (for example, based on the JTAG clock cycle count or the system global clock) for each data unit (such as the bit transmitted in each clock cycle or each data frame). These historical data and timestamps form a time series in the order of reception or transmission, and are stored in the cache or memory on the debugging client or chip side. The establishment of the time series provides a data basis for subsequent anomaly detection. For example, for the JTAG protocol, the timing relationship and corresponding time point between the TDI data bit and the TMS check bit in each ShiftDR state can be recorded.

[0072] Step B2: Use a sliding window to select a window of preset length on the time series data and calculate the statistical characteristics of the data in the window.

[0073] Specifically, the time series is processed in blocks through the sliding window technology: the window size is set according to the communication characteristics of the JTAG protocol (such as the number of bits in each data frame and the duration of the ShiftDR state), for example, the transmission time of a single data frame or N consecutive clock cycles is used as the window length; the window slides bit by bit at a fixed step size (such as 1 clock cycle or 1 data bit) to cover the entire time series; and various statistical features are calculated for the data units in each window (such as binary bit streams and check bit sequences), such as mean, variance, frequency distribution, and timing correlation.

[0074] Step B3: Compare the statistical characteristics of the data in the window with the preset threshold to determine whether there is abnormal fluctuation.

[0075] Specifically, the statistical characteristics of each window are compared with a pre-set normal communication threshold. Based on historical communication data in interference-free scenarios, a normal range is determined through machine learning or statistical analysis (for example, the proportion of "0" bits in the JTAG TMS signal in the ShiftDR state should be close to 100%, and the variance should be close to 0). If the statistical characteristics of a window (such as the frequency of "1" bits in the TMS signal exceeding 5%, or the variance exceeding three standard deviations of the normal range) exceed the threshold, it is determined that there are abnormal fluctuations within the window, indicating that data transmission errors may be caused by signal interference. For example, when the TMS signal experiences high-frequency flips (unexpected "1" bits) in the ShiftDR state, it may mean that the check bit insertion is abnormal or the data bits are interfered with.

[0076] Step B4: If an abnormal fluctuation is detected, the error position is detected within the window range where the abnormal fluctuation is located.

[0077] Specifically, after determining that a window has an anomaly, the specific error location is further located within the window's timeframe. Using the timestamp, the JTAG state machine stage corresponding to the abnormal fluctuation is identified (e.g., the specific clock cycle within the ShiftDR state). Each data bit within the window (including the TDI data bit and the TMS check bit) is checked bit by bit. For example, if CRC is used, the CRC value of the data within the window is recalculated and compared with the attached checksum to determine the range of the erroneous bits. Based on JTAG protocol rules (e.g., TMS should be low in the ShiftDR state), bits that violate the protocol specification are marked (e.g., TMS appears as "1" during the non-check bit insertion phase). For key locations with statistical anomalies (e.g., the clock cycle corresponding to the variance peak), the system prioritizes checking for data bit flips (e.g., "0" to "1" or vice versa). The specific location of the detected erroneous bit in the protocol data (e.g., the nth bit of TDI, the mth check bit of TMS) is identified as the error location for subsequent error correction (e.g., flipping the erroneous bit or triggering a retransmission).

[0078] Through the above steps, we can achieve accurate positioning of errors caused by signal interference in the original protocol data based on time series analysis and sliding window technology, combined with protocol rules and statistical characteristics, providing a clear basis for subsequent error correction or retransmission, thereby improving the anti-interference ability and reliability of debugging communications.

[0079] In an embodiment of the present application, historical abnormality data is collected and sorted, including information such as the time, type, severity, etc. of the abnormality, and the current state of the chip is monitored in real time, such as communication load, signal strength, and environmental parameters (temperature, humidity, electromagnetic interference intensity, etc.). Then, the historical abnormality data and the current state data are comprehensively processed to analyze the changing trend of the data. For example, by performing trend analysis on the data of signal interference intensity changes over time over a period of time, it is determined whether there is a trend of increasing interference intensity. If the analysis results show that interference may increase in a certain period of time in the future, preventive measures are taken in advance. Specifically, in terms of hardware, the effectiveness of the signal shielding device is automatically enhanced, such as adjusting the parameters of the shielding cover or enabling additional shielding components; in terms of software, the communication parameters are adjusted, such as reducing the JTAG communication frequency, optimizing the data encoding method to improve anti-interference ability, etc., thereby reducing the probability of future abnormalities.

[0080] In an embodiment of the present application, updating the original data corresponding to the error position in the original protocol data to obtain the target protocol data includes the following steps C1-C4:

[0081] Step C1, obtaining original data corresponding to the error position in the original protocol data.

[0082] Specifically, the error location in the original protocol data (e.g., the nth bit in a binary sequence) is first determined through a preliminary verification process (such as long division in a CRC check). Taking TDI data transmitted via the JTAG protocol as an example, the data is transmitted bit by bit and stored as a binary sequence (e.g., 101010...). The error location can be pinpointed to a specific bit using a verification algorithm (e.g., remainder calculation). Based on this location index, the original data at the corresponding location in the original protocol data (i.e., a single binary bit with a value of 0 or 1) is extracted.

[0083] Step C2: invert the original data to obtain updated data, and use the updated data to replace the original data at the error position to obtain updated original protocol data.

[0084] Specifically, because data transmission errors typically manifest as a single bit flip (e.g., a 0 mistakenly becoming a 1 or vice versa), a binary inversion operation is performed on the original data at the error location: if the original data is 0, the inversion produces the updated data 1; if the original data is 1, the inversion produces the updated data 0. The updated data then replaces the error bit in the original protocol data to generate updated original protocol data. For example, if the original data is 1010, and the second bit (counting from 0) is an error and the original value is 0, but the inversion produces 1, the updated data becomes 1110.

[0085] Step C3: Use the verification code to verify the updated original protocol data.

[0086] Specifically, according to the pre-agreed check type (such as CRC check, XOR check, etc.), the check code of the updated original protocol data is recalculated and compared with the original check code sent by the debugging client (or the expected check code generated according to the protocol rules): Taking CRC check as an example: the updated data is divided using the same generating polynomial as the sender to obtain a new remainder R'. If the check code attached by the sender is C, it is determined whether R' is consistent with C (or whether the remainder is 0, depending on the check rule). Other check types: such as XOR check, calculate the XOR value of the updated data and compare it with the original check code; parity check checks whether the parity of the updated data meets the check rule.

[0087] Step C4: If the updated original protocol data is successfully verified, the updated original protocol data is used as the target protocol data.

[0088] Specifically, if the verification result is successful (i.e., the newly calculated check code is consistent with the original check code, or meets the verification conditions specified in the protocol), the error correction is confirmed to be valid, and the updated original protocol data is formally defined as the target protocol data for subsequent instruction execution or data feedback. If the verification fails (such as there is still a remainder or the check code does not match), it means that there may be multiple error bits or error correction failed. At this time, according to the system configuration, re-correction (such as re-locating other error bits) or triggering the retransmission mechanism (refer to the feedback process of step 7 in the invention content) is selected.

[0089] The method provided in the embodiment of the present application ensures that the error correction operation does not introduce new errors through closed-loop verification of single-bit inversion and secondary verification. For example, after correcting the Nth bit of data, the remainder is immediately recalculated and compared with the original check code. If the secondary verification fails, the multi-bit error handling process (such as requesting retransmission) is triggered. This design reduces the error correction rate of the error correction process compared to traditional methods; at the same time, through hardware parallel computing (such as a multi-way XOR gate array), the zero-delay execution of the inversion operation is achieved, meeting the real-time requirements.

[0090] In the embodiment of the present application, the method further includes the following steps D1-D2:

[0091] Step D1: If no error location in the original protocol data is detected, the original protocol data is discarded, and error information is sent to the debugging client, wherein the debugging client determines whether to resend the debugging instruction based on the error information.

[0092] Specifically, when the chip or debug client verifies the received raw protocol data, it uses a selected checksum type (such as parity or CRC) to detect the location of errors. If, after a series of verification operations (such as calculating remainders and comparing checksums), the location of the error in the raw protocol data remains unclear, this may indicate that the data is subject to complex interference or that the verification algorithm is unable to accurately identify the error under the current circumstances.

[0093] At this point, to ensure system reliability and security, the receiver discards the original protocol data to avoid unpredictable consequences caused by the execution of erroneous data. Simultaneously, the receiver sends an error message to the debugging client. This error message may include verification information, such as the verification type used and the verification result. Upon receiving the error message, the debugging client decides whether to resend the debugging command based on its own configuration and policies. For example, if the debugging client is configured to allow retransmission after a certain number of errors, it will determine whether the retransmission conditions are met based on previous error records. If so, it will resend the debugging command.

[0094] Step D2: If the debugging instruction resent by the debugging client is received within the preset time period, the corresponding debugging command is executed based on the protocol data in the debugging instruction.

[0095] Specifically, after the debugging client decides to resend the debugging instruction, the receiver will set a preset time period to wait for the instruction. This preset time period is to ensure that the retransmitted data is received within a reasonable time range to avoid long waiting times that affect debugging efficiency. If the receiver successfully receives the debugging instruction resent by the debugging client within the preset time period, the receiver will verify the protocol data in the instruction again. If the verification is correct, the receiver will execute the corresponding debugging command based on these protocol data. For example, if the debugging instruction requires the chip to perform a specific operation (such as reading the value of a register, modifying configuration parameters, etc.), the chip will perform the corresponding operation according to the requirements of the instruction; if the debugging client receives the data resent by the chip and the verification passes, the debugging client will feed the data back to the host computer software for the debugging personnel to view the internal information of the chip.

[0096] The method provided in this embodiment achieves adaptive management of communication resources through error feedback and intelligent retransmission mechanisms. When an uncorrectable error is detected, the buffer is immediately released and a NACK signal is sent, forcing the debugging client to initiate a retransmission within a specified time period (preset timeout threshold), thus avoiding system freezes caused by waiting timeouts.

[0097] In an embodiment of the present application, the method further includes steps E1-E3:

[0098] Step E1: If no resent debugging instruction is received within a preset time period, the network connection between the device under test and the debugging client is detected.

[0099] Specifically, if no debug command is resent from the debug client within a preset time period (e.g., 500ms), the following operations will be performed: The level changes of signals such as TMS, TDI, and TDO will be monitored through the TAP controller state machine of the JTAG protocol. For example, in the Run-Test-Idle state, if no valid transition of the TMS signal (e.g., from low to high) is detected for five consecutive TCK cycles, the physical connection will be determined to be abnormal. If the communication is based on a network (e.g., USB to JTAG or remote connection), the chip will send a heartbeat packet (e.g., TDI data in a specific format). If an ACK response is not received from the debug client within a preset time, a connection failure detection will be triggered. The device ID or status register of the debug client will be read through JTAG instructions. If the returned data fails to be verified (e.g., CRC mismatch), the logical connection will be determined to be interrupted.

[0100] Step E2: If the network connection status is connection failure, release the resources occupied by the debugging instruction.

[0101] Specifically, if a connection failure is detected, the following resource release operations will be performed: by sending 5 consecutive TMS high-level signals, the TAP controller state machine will be forced to reset to the Test-Logic-Reset state, clearing the current instruction queue and shift register contents; clearing the temporary buffer allocated on the chip side for debug instructions (such as the FIFO queue for storing instructions to be executed), and restoring the relevant registers (such as debug command registers and data registers) to their initial values; if the chip supports low-power mode, the JTAG interface will be switched to standby mode, retaining only the minimum circuits required for periodic monitoring (such as timers and interrupt controllers).

[0102] Step E3: periodically monitor the network connection status with the debugging client. If the network connection status is successful, actively send a task prompt message to the debugging client. The task prompt message is used to request the debugging client to resend the debugging instruction.

[0103] Specifically, after a connection failure, the following loop begins: a periodic timer (e.g., every 1 second) is started to trigger connection status detection. During each timer cycle, the connection detection logic in step E1 is executed. If the physical connection is restored (e.g., the TMS signal returns to normal) or the network port is connected (e.g., the JTAG server port 19020 responds), the active retransmission request phase begins.

[0104] Task prompt information transmission: In the ShiftDR state, a custom task prompt sequence is inserted via the TMS signal. For example, during the low TMS period, a specific parity bit pattern (such as "1010") is inserted to request retransmission of the current instruction. The task prompt information includes the instruction ID, error code (such as the type of parity failure), and the retransmission limit. For example, the first four bits of the TDI data are the instruction ID, the last four bits are the error code, and the remaining bits are reserved fields. After receiving the task prompt, the debug client must return an ACK confirmation signal (such as specific TDO data). If the chip does not receive an ACK within the preset time, the task prompt is resent until the maximum number of retries is reached.

[0105] The method provided in the embodiment of the present application actively releases resources when a physical layer anomaly (such as a disconnection) occurs by introducing network status awareness and periodic connection monitoring, and reestablishes the session through task prompt information (such as a heartbeat packet) after the connection is restored. For example, when it is detected that the TMS signal is continuously at a high level for more than 1ms, it is determined that the connection is interrupted, and the current debugging task is immediately terminated and the occupied JTAG chain resources are released. After the connection is restored, the client is notified to resynchronize by sending a specific reset sequence (such as a high pulse of 5 TCK cycles), which compresses the disconnection recovery time from seconds to milliseconds, ensuring the continuity of the debugging process.

[0106] As an example, Figure 2 As shown, when the device under test is a chip, the communication debugging process is as follows: First, the debugging client side selects the verification type and synchronizes the verification type with the chip side. Next, the debugging client sends a protocol with verification, and after the chip side receives the data, it verifies the data. If the verification is correct, the chip side executes the instructions sent by the debugging client, and the process ends; if the verification is wrong, it determines whether to perform error correction. If error correction is selected, the error correction program is executed to correct the received data. After the error correction is completed, the debugging client instructions are executed, and the process ends; if error correction is not selected, the feedback data is discarded to the debugging client side, and then it is determined whether to resend the data. If resending is selected, the process returns to the debugging client to send the protocol with verification step and start again; if resending is not selected, the process ends.

[0107] As an example, Figure 3 As shown in the figure, when the device under test is the device where the debugging client resides, the communication debugging process is as follows: the chip sends protocol data with verification, and the debugging client receives the data. The debugging client then verifies the data. If the verification is correct, the data is fed back to the host, and the process ends. If the verification is incorrect, a determination is made as to whether error correction should be performed. If error correction is selected, the error correction program is executed to correct the received data. After correction, a determination is made as to whether to resend the data. If not, the process ends. If so, the process returns to the chip and starts over again by sending protocol data with verification. If not, the data is discarded and fed back to the chip. A determination is then made as to whether to resend the data. If not, the process ends. If so, the process returns to the chip and starts over again by sending protocol data with verification.

[0108] This embodiment also provides a communication debugging device for implementing the above-mentioned embodiments and preferred implementations. Details already described will not be repeated here. As used below, the term "module" may refer to a combination of software and / or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation using hardware, or a combination of software and hardware, is also possible and contemplated.

[0109] This embodiment provides a communication debugging device, such as Figure 4 Shown, including:

[0110] The receiving module 401 is configured to receive a debugging instruction sent by a debugging client, wherein the debugging instruction includes original protocol data and a check code;

[0111] The verification module 402 is used to verify the original protocol data using the verification code, and if the verification of the original protocol data fails, detect the error position in the original protocol data;

[0112] An updating module 403 is used to update the original data corresponding to the error position in the original protocol data to obtain the target protocol data;

[0113] The execution module 404 is configured to execute corresponding debugging commands based on the target protocol data.

[0114] In the embodiment of the present application, the verification module includes a first processing submodule, a second processing submodule and a third processing submodule;

[0115] The first processing submodule is used to perform a division operation based on the original protocol data to obtain a first remainder; compare the first remainder with the check code to obtain a comparison result, wherein if the comparison result is that the first remainder and the check code are consistent, the verification is successful; or if the comparison result is that the first remainder and the check code are inconsistent, the verification fails.

[0116] The second processing submodule is configured to perform a summation based on the first remainder and the check code to obtain a binary code; perform a long division operation on the binary code to obtain a second remainder, and use a position corresponding to the second remainder as an error position.

[0117] The third processing submodule is used to obtain a pre-established time series, which stores historical protocol data and corresponding timestamps; use a sliding window to select a window of preset length on the time series data, and calculate the statistical characteristics of the data in the window; compare the statistical characteristics of the data in the window with a preset threshold to determine whether there is an abnormal fluctuation; if an abnormal fluctuation is detected, detect the error location within the window range where the abnormal fluctuation is located.

[0118] In an embodiment of the present application, the update module is used to obtain the original data corresponding to the error position in the original protocol data; invert the original data to obtain the updated data, and use the updated data to replace the original data at the error position to obtain the updated original protocol data; use the check code to check the updated original protocol data; if the updated original protocol data is successfully checked, the updated original protocol data is used as the target protocol data.

[0119] In an embodiment of the present application, the device also includes: a debugging module, which is used to discard the original protocol data if the error location in the original protocol data is not detected, and send an error message to the debugging client, wherein the debugging client determines whether to resend the debugging instruction based on the error information; if the debugging instruction resent by the debugging client is received within a preset time period, the corresponding debugging command is executed based on the protocol data in the debugging instruction.

[0120] In an embodiment of the present application, the device also includes: a detection module, which is used to detect the network connection status between the device under test and the debugging client if no resent debugging instruction is received within a preset time period; if the network connection status is a connection failure, release the resources occupied by the debugging instruction; periodically monitor the network connection status between the device and the debugging client, and if the network connection status is a connection success, actively send a task prompt information to the debugging client, wherein the task prompt information is used to request the debugging client to resend the debugging instruction.

[0121] See also Figure 5 , Figure 5 is a structural diagram of an electronic device provided by an optional embodiment of the present invention, such as Figure 5 As shown, the electronic device includes: one or more processors 10, a memory 20, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. The various components utilize different buses to communicate with each other and can be installed on a common mainboard or installed in other ways as needed. The processor can process instructions executed in the electronic device, including instructions stored in or on the memory to display graphical information of a GUI on an external input / output device (such as a display device coupled to the interface). In some optional embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple electronic devices can be connected, and each device provides some necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system).

[0122] The processor 10 may be a central processing unit, a network processor, or a combination thereof. The processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit, a programmable logic device, or a combination thereof. The programmable logic device may be a complex programmable logic device, a field programmable gate array, a general purpose array logic, or any combination thereof.

[0123] The memory 20 stores instructions that can be executed by at least one processor 10, so as to enable at least one processor 10 to execute the method shown in the above embodiment.

[0124] The memory 20 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created based on the use of an electronic device presented by a small program landing page, etc. In addition, the memory 20 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some optional embodiments, the memory 20 may optionally include a memory remotely located relative to the processor 10, and these remote memories may be connected to the electronic device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and a combination thereof.

[0125] The memory 20 may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as a flash memory, a hard disk or a solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0126] The electronic device further includes a communication interface 30 for the electronic device to communicate with other devices or a communication network.

[0127] The embodiment of the present invention also provides a computer-readable storage medium. The above-mentioned method according to the embodiment of the present invention can be implemented in hardware, firmware, or implemented as a computer code that can be recorded in a storage medium, or implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and downloaded through a network and will be stored in a local storage medium, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only storage memory, a random access memory, a flash memory, a hard disk or a solid-state drive, etc.; further, the storage medium can also include a combination of the above-mentioned types of memory. It can be understood that a computer, a processor, a microprocessor controller or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor or hardware, the method shown in the above embodiment is implemented.

[0128] Although the embodiments of the present invention have been described with reference to the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the present invention. Such modifications and variations are all within the scope defined by the appended claims.

Claims

1. A communication debugging method, characterized in that: The method is applied to a device under test, and the method includes: Receiving a debugging instruction sent by a debugging client, wherein the debugging instruction includes original protocol data and a check code; Verifying the original protocol data using the verification code, and if the verification of the original protocol data fails, detecting an error position in the original protocol data; Updating the original data corresponding to the error position in the original protocol data to obtain target protocol data; Execute corresponding debugging commands based on the target protocol data.

2. The method according to claim 1, characterized in that The verifying the original protocol data by using the verification code includes: Performing a division operation based on the original protocol data to obtain a first remainder; The first remainder is compared with the check code to obtain a comparison result, wherein if the comparison result is that the first remainder is consistent with the check code, the verification is successful; or if the comparison result is that the first remainder is inconsistent with the check code, the verification fails.

3. The method according to claim 2, characterized in that The detecting an error location in the original protocol data includes: Summing the first remainder and the check code to obtain a binary code; A long division operation is performed on the binary code to obtain a second remainder, and a position corresponding to the second remainder is used as the error position.

4. The method according to claim 1, wherein The detecting an error location in the original protocol data includes: Obtaining a pre-established time series, wherein the time series stores historical protocol data and corresponding timestamps; Use a sliding window to select a window of preset length on the time series data and calculate the statistical characteristics of the data in the window; Compare the statistical characteristics of the data in the window with the preset threshold to determine whether there are abnormal fluctuations; If an abnormal fluctuation is detected, the error position is detected within the window range where the abnormal fluctuation is located.

5. The method according to claim 1, wherein The updating of the original data corresponding to the error position in the original protocol data to obtain the target protocol data includes: Obtaining original data corresponding to an error position in the original protocol data; Inverting the original data to obtain updated data, and replacing the original data at the error position with the updated data to obtain updated original protocol data; Verifying the updated original protocol data using the verification code; If the updated original protocol data is successfully verified, the updated original protocol data is used as the target protocol data.

6. The method according to claim 1, characterized in that The method further comprises: If no error location in the original protocol data is detected, discarding the original protocol data and sending error information to the debugging client, wherein the debugging client determines whether to resend the debugging instruction based on the error information; If the debugging instruction resent by the debugging client is received within a preset time period, the corresponding debugging command is executed based on the protocol data in the debugging instruction.

7. The method according to claim 6, characterized in that The method further comprises: If no resent debugging instruction is received within a preset time period, detecting the network connection between the device under test and the debugging client; If the network connection status is connection failure, releasing the resources occupied by the debugging instruction; Periodically monitor the network connection status between the debugging client and the debugging client, and if the network connection status is successful, actively send task prompt information to the debugging client, wherein the task prompt information is used to request the debugging client to resend the debugging instruction.

8. A communication debugging device, characterized in that: The device comprises: A receiving module, configured to receive a debugging instruction sent by a debugging client, wherein the debugging instruction includes original protocol data and a check code; a verification module, configured to verify the original protocol data using the verification code, and if the verification of the original protocol data fails, detect an error position in the original protocol data; An updating module, configured to update the original data corresponding to the error position in the original protocol data to obtain target protocol data; An execution module is used to execute corresponding debugging commands based on the target protocol data.

9. A computer device, characterized in that: include: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the method according to any one of claims 1 to 7 by executing the computer instructions.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a computer to execute the method according to any one of claims 1 to 7.

Images