Model compatible method, fault analysis device and intelligent fault diagnosis instrument

Abstract

The application provides a model compatible method, a fault analysis device and an intelligent fault diagnosis instrument, relates to the technical field of fault diagnosis, and the model compatible method comprises the following steps: obtaining target model parameters of a to-be-tested computing power board; configuring a first detection firmware corresponding to the target model parameters; in response to a power-on test operation on the to-be-tested computing power board, running the first detection firmware, and determining a connection state of the to-be-tested computing power board; if the connection state is failed, reconfiguring the first detection firmware, and performing the power-on test operation until the connection state is successful. The application realizes intelligent adaptation of computing power boards of different models by automatically obtaining target model parameters, configuring a detection firmware and testing a connection state, and can improve maintenance efficiency, reduce labor cost, reduce misjudgment risk and enhance cross-brand compatibility.

Description

Technical Field

[0001] This application relates to the field of fault diagnosis technology, and in particular to a model compatibility method, a fault analysis device, and an intelligent fault diagnosis instrument. Background Technology

[0002] Currently, the maintenance of blockchain servers primarily relies on a combination of manual operation and brand-specific tools. Different brands, such as Antminer, Whatsminer, and Avalon, each have their own dedicated maintenance equipment, such as power supply testers and computing board diagnostic tools. These tools are only compatible with hardware from a single brand and cannot be used across brands. Maintenance personnel must undergo specialized training for each brand or accumulate extensive experience to handle multi-brand equipment, leading to a significant increase in labor costs. In actual troubleshooting, personnel must manually test components such as the power supply, computing board, and the entire machine, relying entirely on personal experience to determine the cause of the fault, resulting in low efficiency and a high risk of misdiagnosis. The lack of tool compatibility forces maintenance organizations to purchase and maintain multiple sets of equipment, driving up procurement and maintenance costs, while also incurring additional time when switching brands. The high skill threshold for personnel, requiring memorization of fault logic for each brand, prolongs training cycles and increases the risk of errors. These problems severely restrict the efficiency and reliability of blockchain server maintenance. Summary of the Invention

[0003] The main objective of this invention is to provide a model compatibility method, which aims to improve maintenance efficiency, reduce labor costs, and reduce the risk of misjudgment.

[0004] To achieve the above objectives, the present invention provides a model compatibility method applied to an intelligent fault diagnostic instrument. The intelligent fault diagnostic instrument is provided with a connection interface for connecting to a computing board under test. The model compatibility method includes:

[0005] Obtain the target model parameters of the computing board to be tested;

[0006] Configure the first detection firmware corresponding to the target model parameters;

[0007] In response to the power-on test operation on the computing board under test, the first detection firmware is run to determine the connection status with the computing board under test;

[0008] If the connection status fails, reconfigure the first detection firmware and perform a power-on test until the connection status is successful.

[0009] Optionally, the first detection firmware configured to correspond to the target model parameters includes:

[0010] In response to the input of the target model parameters for the computing board under test, the firmware configuration rules and configuration parameters of the target model parameters are determined;

[0011] The first detection firmware is generated according to the firmware configuration rules and the configuration parameters.

[0012] Optionally, generating the first detection firmware according to the firmware configuration rules and the configuration parameters includes:

[0013] The communication protocol type is determined based on the communication line pin arrangement of the target model parameters;

[0014] Determine the control instruction code corresponding to the configuration parameters;

[0015] The corresponding communication data format is determined based on the communication protocol type and the control command code;

[0016] Configure the control instruction code according to the firmware configuration rules and communication data format to generate the corresponding first detection firmware.

[0017] Optionally, generating the first detection firmware according to the firmware configuration rules and the configuration parameters includes:

[0018] Determine the communication protocol matching strategy, communication line sequence, and instruction mapping relationship in the firmware configuration rules;

[0019] In response to the control command code entered by the user according to the communication protocol matching strategy, the communication line sequence and the instruction mapping relationship, the syntax structure and protocol compatibility of the control command code are parsed to generate the first detection firmware.

[0020] Optionally, the first detection firmware configured to correspond to the target model parameters includes:

[0021] Establish network communication links with external or internal databases;

[0022] Obtain the preset firmware configuration template matching the target model parameters, the communication line pin arrangement of the target model parameters, and the corresponding control instruction code stored in the external database or the internal database;

[0023] The communication protocol type is determined based on the pin arrangement of the communication lines;

[0024] The corresponding communication data format is determined based on the communication protocol type and the control command code;

[0025] The control instruction code is placed into the firmware configuration template according to the communication data format to generate the first detection firmware.

[0026] Optionally, the step of running the first detection firmware in response to a power-on test operation on the computing board under test to determine the connection status with the computing board under test includes:

[0027] In response to a power-on test operation on the computing board under test, the first detection firmware is run and the first detection data is sent through the connection interface;

[0028] The connection status signal returned by the connection interface is monitored, and the connection status is determined by parsing the connection status signal through the first detection firmware.

[0029] Optionally, the target model parameters include the communication wiring sequence and the data format corresponding to the communication wiring sequence;

[0030] The step of monitoring the connection status signal returned by the connection interface and parsing the connection status signal through the first detection firmware to determine the connection status includes:

[0031] The voltage level change status of the connection interface is acquired at preset intervals;

[0032] If the level change state has a level jump and conforms to the characteristics of a preset communication protocol, it is determined that the connection interface returns a connection status signal;

[0033] The first detection firmware parses the connection status signal according to the data format and extracts the model identifier and communication response timing.

[0034] Based on the model identifier and the communication response timing, it is determined that the target model parameters match the actual hardware configuration of the computing board under test, and the connection status is determined to be a valid communication establishment.

[0035] Optionally, obtaining the target model parameters of the computing board under test includes:

[0036] Determine the communication wiring sequence between the computing board under test and the connection interface;

[0037] The corresponding data format is determined based on the communication line sequence;

[0038] Obtain the datasheet corresponding to the computing board under test, and determine the corresponding control instruction code in the datasheet;

[0039] The control command code, the communication wiring sequence, and the data format are combined into the target model parameters.

[0040] In addition, to achieve the above objectives, the present invention also provides a fault analysis device, the fault analysis device comprising: a memory, a processor, and a model compatibility program stored in the memory and executable on the processor, the model compatibility program being configured to implement the model compatibility method as described above.

[0041] Furthermore, to achieve the above objectives, the present invention also provides an intelligent fault diagnosis instrument, comprising:

[0042] The display device is used for visual interaction of power-on test operations or to present the connection status of the computing board under test.

[0043] A connection interface, used to connect to the computing board under test, the connection interface having multiple channel pins for transmitting different communication line sequences; and

[0044] The fault analysis device described above is electrically connected to both the connection interface and the display device.

[0045] The fault analysis device is used to obtain the target model parameters of the computing board under test through the connection interface, configure the first detection firmware corresponding to the target model parameters, and in response to the power-on test operation of the display device for the computing board under test, run the first detection firmware, determine the connection status with the computing board under test, and determine whether the connection status is normal. If the connection status is failed, generate the corresponding fault prompt and control the display device to display it, reconfigure the first detection firmware, and perform the power-on test operation until the connection status is successful.

[0046] The device compatibility method of this invention is applied to an intelligent fault diagnostic instrument. This instrument has a connection interface for connecting to a computing board under test. The method obtains the target model parameters of the computing board under test, configures a first detection firmware corresponding to these parameters, and runs the first detection firmware in response to a power-on test operation on the board. It then determines the connection status with the board. If the connection fails, the first detection firmware is reconfigured, and a power-on test is performed again until the connection is successful. Thus, by automatically obtaining the target model parameters, configuring the detection firmware, and testing the connection status, intelligent adaptation to different computing board models is achieved, improving repair efficiency, reducing labor costs, minimizing the risk of misdiagnosis, and enhancing cross-brand compatibility. Attached Figure Description

[0047] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0048] Figure 1 This is a schematic flowchart of a model compatibility method according to an embodiment of the present invention;

[0049] Figure 2 for Figure 1 A flowchart illustrating step S200 in the diagram;

[0050] Figure 3for Figure 2 A flowchart illustrating step S220 in the diagram;

[0051] Figure 4 This is a schematic flowchart of a model compatibility method according to another embodiment of the present invention;

[0052] Figure 5 This is a schematic flowchart of a model compatibility method according to another embodiment of the present invention;

[0053] Figure 6 for Figure 1 A flowchart illustrating step S300 in the diagram;

[0054] Figure 7 for Figure 6 A flowchart illustrating step S320 in the diagram;

[0055] Figure 8 for Figure 1 A flowchart illustrating step S100 in the diagram.

[0056] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0057] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Well-known modules, units, and their connections, links, communications, or operations are not shown or described in detail. Furthermore, the described features, architectures, or functions can be combined in any way in one or more embodiments. Those skilled in the art should understand that the various embodiments described below are only for illustrative purposes and not for limiting the scope of protection of the present invention. It is also readily understood that the modules, units, or processing methods in the various embodiments described herein and shown in the accompanying drawings can be combined and designed in various different configurations. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0058] The definitions of various terms or methods used in the following embodiments are, except where logically impossible, generally defined as broad concepts that can be implemented under the premise of the content disclosed in the embodiments. Under this understanding, all specific subordinate limitations of the terms or methods should be considered as part of the invention and should not be narrowly interpreted or biased simply because the specification does not disclose such a specific limitation. Similarly, provided that it is logically feasible, the order of the steps in the method is flexible and varied, and all specific subordinate limitations in the broad concepts of various terms or methods fall within the scope of protection of this invention.

[0059] The maintenance of existing blockchain servers primarily relies on a combination of manual operation and brand-specific tools. Different brands, such as Antminer, Whatsminer, and Avalon, each have their own dedicated maintenance equipment, including power supply testers and computing board diagnostic tools. These tools are only compatible with hardware from a single brand and cannot be used across brands. Maintenance personnel must undergo specialized training or accumulate extensive experience to handle multi-brand equipment, significantly increasing labor costs. In actual troubleshooting, personnel must manually test components such as power supplies, computing boards, and the entire machine, relying entirely on personal experience to determine the cause of the fault, resulting in low efficiency and a high risk of misdiagnosis. The lack of tool compels maintenance organizations to purchase and maintain multiple sets of equipment, increasing procurement and maintenance costs and incurring additional time when switching brands. The high skill threshold for personnel, requiring memorization of fault logic for each brand, prolongs training cycles and increases the risk of errors. Weak cross-brand collaboration capabilities make it difficult to effectively diagnose multi-brand component combination faults, such as the interconnection problem between a brand A power supply and a brand B computing board, leading to frequent recurrences and a complex troubleshooting process. These problems severely restrict the efficiency and reliability of blockchain server maintenance, especially when facing scenarios involving multiple brands, where existing technologies lack an automatic adaptation mechanism to resolve compatibility issues caused by differences in model parameters.

[0060] The main solution of this application embodiment is: by obtaining the target model parameters of the computing board under test, configuring the first detection firmware corresponding to the target model parameters, and in response to the power-on test operation for the computing board under test, running the first detection firmware to determine the connection status with the computing board under test. If the connection status fails, the first detection firmware is reconfigured and the power-on test operation is performed until the connection status is successful.

[0061] In this embodiment, for ease of description, the fault analysis device will be used as the execution subject in the following description.

[0062] This application provides a solution that automatically acquires target model parameters, configures detection firmware, and tests connection status to achieve intelligent adaptation to different models of computing boards, thereby improving maintenance efficiency, reducing labor costs, reducing the risk of misjudgment, and enhancing cross-brand compatibility.

[0063] Therefore, this invention proposes a model-compatible method; it is understood that the intelligent fault diagnostic instrument is equipped with a fault analysis device for storing and executing the following method. The fault analysis device can be implemented using a main controller, such as an MCU (Micro Controller Unit), a DSP (Digital Signal Processor), an FPGA (Field Programmable Gate Array), or a SOC (System On Chip).

[0064] In the traditional blockchain server maintenance process, the dedicated diagnostic tools of various brands cannot interoperate due to the heterogeneity of communication protocol definitions and line sequence arrangements. Maintenance personnel need to manually configure tool parameters and analyze fault signals based on human experience, which increases the complexity of tool management and the risk of human misjudgment, thereby reducing the efficiency of fault diagnosis and prolonging system downtime. In particular, the collaborative maintenance capability in a multi-brand mixed deployment environment is significantly restricted.

[0065] For example, in data center operation and maintenance scenarios, when an anomaly occurs when the Antminer brand computing board and the Whatsminer brand power module are combined, the maintenance personnel first use the Antminer dedicated diagnostic tool to connect to the computing board, but the communication protocol conflict is caused by the incompatibility of the power module brands; then it is necessary to switch to the Whatsminer dedicated tool to retest the power supply. The process involves multiple physical adjustments of the connection interface pins and manual input of control command codes. The difference in the communication line sequence causes the data format parsing to fail, which in turn leads to the deviation in fault source location and repeated test operations.

[0066] If the above problems are not resolved, the maintenance process will become fragmented, and the interaction failures between components from different brands will be difficult to analyze systematically. This may lead to recurring failures and chain reactions of system interruptions, which will affect the stable operation of the blockchain network in the long term.

[0067] To solve the above problems, refer to Figure 1 In one embodiment of the present invention, the model compatibility method is applied to an intelligent fault diagnostic instrument. The intelligent fault diagnostic instrument is provided with a connection interface for connecting to the computing board under test. The model compatibility method includes steps S100-S400, wherein:

[0068] S100: Obtain the target model parameters of the computing board to be tested;

[0069] S200, Configure the first detection firmware corresponding to the target model parameters;

[0070] S300: In response to a power-on test operation on the computing board under test, the first detection firmware is run to determine the connection status with the computing board under test.

[0071] S400: If the connection status fails, reconfigure the first detection firmware and perform a power-on test until the connection status is successful.

[0072] The target model parameters include control command data, communication wiring sequence, and the corresponding data format. Configuring the first detection firmware can be done by writing code and exporting it as a hex or bin file, or by visually modifying configuration parameters.

[0073] Among them, an intelligent fault diagnostic instrument is a specialized device used to detect and diagnose faults in computing boards. This diagnostic instrument typically integrates a processor, memory, display device, and a connection interface for connecting the computing board under test (DUT). It can execute preset diagnostic programs and determine the operating status of the computing board based on the test results. The connection interface is the port on the intelligent fault diagnostic instrument used to physically connect to the DUT. This connection interface usually contains multiple pins, supporting different communication protocols and wiring sequences to achieve data transmission and signal interaction with different models of DUTs. The DUT refers to the computing unit board that needs to be fault-diagnosed or performance-tested. These DUTs may come from different manufacturers and have different hardware configurations, communication protocols, and control instruction sets.

[0074] The target model parameter refers to a set of key technical information describing a specific model of the computing board under test. This parameter typically includes control command data, communication wiring sequence, and the corresponding data format, forming the basis for the intelligent fault diagnostic instrument to correctly identify and diagnose the computing board under test. Control command data refers to the sequence of instructions used to control the computing board under test to perform specific operations or obtain its status information. Different computing board models may use different instruction sets and encoding methods. The communication wiring sequence refers to the arrangement of the data transmission lines between the connection interface and the computing board under test. A correct communication wiring sequence is a prerequisite for establishing an effective physical connection and data exchange.

[0075] The data format refers to the way data is encoded and organized during communication. This data format is closely related to the communication wiring sequence, ensuring that the intelligent fault diagnostic instrument can correctly parse the data received from the computing board under test (DUT) and send instructions in the correct format. The first detection firmware is a dedicated software program dynamically generated or configured based on the target model parameters of the DUT. This firmware is loaded into the processor of the intelligent fault diagnostic instrument and runs, responsible for communicating with the DUT, sending detection instructions, and parsing returned signals to determine the connection status. The power-on test operation refers to the process of supplying power to the DUT connected to the intelligent fault diagnostic instrument and starting the detection program. This operation aims to simulate the actual working environment of the computing board and verify its connection status and basic functions by running the first detection firmware. The connection status refers to the validity of the communication link between the intelligent fault diagnostic instrument and the DUT. This connection status can be successful (indicating that effective communication has been established) or failed (indicating that communication establishment is abnormal or cannot be established).

[0076] The model compatibility method in this embodiment first obtains the target model parameters of the computing board under test. The target model parameters can be obtained in various ways. For example, the user can manually consult the technical manual of the computing board under test, extract control command data, communication wiring sequence, and the data format corresponding to that communication wiring sequence, and then input this information into the intelligent fault diagnostic instrument. Alternatively, the intelligent fault diagnostic instrument can preset a model parameter library, and the user can retrieve the corresponding target model parameters from the library by inputting the model name of the computing board under test.

[0077] After obtaining the target model parameters, the first detection firmware corresponding to those parameters needs to be configured. The configuration of the first detection firmware can be done in several ways. For example, the intelligent fault diagnostic instrument can provide a universal firmware configuration interface. Users can manually select or input the corresponding communication protocol, wiring configuration, and control command codes based on the obtained target model parameters. The compilation or generation module inside the intelligent fault diagnostic instrument then converts this configuration information into executable firmware. Another method is that the intelligent fault diagnostic instrument presets multiple firmware templates. Users select the closest template based on the target model parameters and then manually modify key parameters in the template, such as communication rate, data bits, and checksum, to generate a compatible first detection firmware. Yet another method is to have the user input corresponding code commands, which are then compiled by compilation software to generate a corresponding hex or bin file format firmware program. This program is then imported into the intelligent fault diagnostic instrument and loaded into the processor through the management backend.

[0078] Subsequently, in response to a power-on test operation on the computing board under test, the intelligent fault diagnostic instrument runs the first detection firmware to determine the connection status with the computing board under test. The power-on test operation is typically triggered by the user through the diagnostic instrument's control interface. When running the first detection firmware, it sends a series of preset detection signals or commands to the computing board under test via the connection interface. For example, the firmware may send a simple handshake signal, a command requesting device identification, or a string of commands including address code, communication code, and control signals. The intelligent fault diagnostic instrument monitors the return signals from the connection interface, and the first detection firmware performs preliminary processing on these signals to determine whether the computing board under test is responding normally. The connection status can be determined based on the presence or absence of a simple signal; for example, if the connection interface does not receive any response after sending a signal, it may be considered a connection failure.

[0079] If the connection is determined to be failed, the first detection firmware needs to be reconfigured, and the power-on test performed again until the connection is successful. When the connection fails, the intelligent fault diagnostic instrument will prompt the user with a connection error message. At this time, the user can manually adjust the parameters of the previously configured first detection firmware according to the failure message. For example, the user may suspect that the communication wiring sequence is incorrect, so they manually modify the wiring sequence, regenerate the firmware, and test again. Or, the user may think that the control command data is incorrect, so they consult the documentation, modify the commands, reconfigure the firmware, and test again. This process will be repeated until a successful connection is established between the intelligent fault diagnostic instrument and the computing board under test.

[0080] In one embodiment of this example, assume that user A owns a computing board to be tested, model number "Computing Board X", but user A is unsure of its specific communication protocol and control commands. User A connects the computing board X to the connection interface of the intelligent fault diagnostic instrument.

[0081] First, the intelligent fault diagnostic instrument needs to obtain the target model parameters of computing board X. User A can manually consult the technical specifications of computing board X, from which they learn that it uses the UART communication protocol, with a baud rate of 115200, 8 data bits, no parity bit, 1 stop bit, and its control command data includes a "get temperature" command code 0xAA. User A inputs this information, namely the control command data 0xAA, the communication pin sequence (e.g., RX pin corresponds to the diagnostic instrument's TX, TX pin corresponds to the diagnostic instrument's RX, GND to GND), and the data format (UART, 115200, 8N1), into the intelligent fault diagnostic instrument as the target model parameters.

[0082] Next, the intelligent fault diagnostic instrument configures the first detection firmware based on the target model parameters input by user A. The firmware generation module inside the intelligent fault diagnostic instrument generates a firmware program capable of sending 0xAA commands and receiving responses via UART protocol at 115200 baud rate, based on these parameters. This firmware program is then loaded into the diagnostic instrument's processor.

[0083] Subsequently, User A triggered a power-on test on the display of the intelligent fault diagnostic instrument. The diagnostic instrument powered on the computing board X and ran the configured first detection firmware. This firmware sent the command 0xAA to the computing board X via the connection interface. If the computing board X is working normally and successfully receives the command, it will return a response signal, such as its current temperature data. The diagnostic instrument's firmware monitors the level changes of the connection interface and attempts to interpret the returned signal.

[0084] Suppose that during the initial test, the intelligent fault diagnostic instrument receives no response signal, or the received signal cannot be interpreted; in this case, the connection status is determined to be failed. The intelligent fault diagnostic instrument will display a connection failure message on the display device. User A, based on the message, recalls whether the wiring sequence is incorrect. After checking, User A discovers that the RX and TX pins may have been reversed. Therefore, User A modifies the communication wiring sequence configuration on the diagnostic instrument, for example, swapping the correspondence between the RX and TX pins. The diagnostic instrument regenerates and loads the first detection firmware based on the new configuration.

[0085] User A triggered the power-on test again. This time, the first detection firmware sent the command 0xAA with the corrected wiring sequence. If the computing board X responded normally, the diagnostic tool's firmware successfully received and parsed the returned temperature data. At this point, the connection status was confirmed as successful. The intelligent fault diagnostic tool displayed "Connection Successful" and the temperature data of the computing board X on the display device. Through this repeated configuration and testing process, the intelligent fault diagnostic tool finally successfully established communication with the computing board X and verified its basic functions.

[0086] In this system, when configuring the first detection firmware based on the target model parameters input by user A, the user can also write detection firmware code conforming to the target model parameters using software in the management backend, according to preset program code requirements, and then compile and download it to the intelligent fault diagnostic instrument. The compiled firmware is then written to the firmware storage area of ​​the intelligent fault diagnostic instrument through a secure transmission channel.

[0087] This embodiment achieves broad compatibility of the intelligent fault diagnostic tool with different models of computing boards by dynamically acquiring the target model parameters of the computing board under test and configuring the first detection firmware accordingly. Compared with the existing technology that requires purchasing dedicated tools for each brand or model, this method significantly reduces the cost of tool procurement and maintenance. For example, in the example above, user A does not need to purchase a dedicated diagnostic tool for "computing board X", but can adapt it to the computing board through the flexible configuration capability of the intelligent fault diagnostic tool.

[0088] Furthermore, when the connection fails, this method guides the user to reconfigure the initial detection firmware and retest until the connection is successful. This iterative configuration and verification mechanism effectively reduces reliance on the operator's professional experience. In existing technologies, when faced with connection failures, operators often need to manually troubleshoot various possibilities based on years of experience, which is time-consuming and prone to misjudgment. This method, by providing a clear configuration and testing process, allows even inexperienced operators to establish a valid connection with the computing board under test by adjusting parameters and repeatedly verifying. This not only shortens the training cycle but also improves the accuracy and efficiency of fault diagnosis. Overall, the technical solution of this embodiment provides a universal, efficient, and easy-to-operate computing board model compatible solution, effectively solving the core technical problems of non-universal tools, high personnel thresholds, and lack of cross-brand collaborative troubleshooting capabilities in existing technologies.

[0089] The device compatibility method in this embodiment is applied to an intelligent fault diagnostic instrument. This instrument has a connection interface for connecting to a computing board under test. The method obtains the target model parameters of the computing board under test, configures a first detection firmware corresponding to these parameters, and runs the first detection firmware in response to a power-on test operation on the board. It then determines the connection status with the board. If the connection fails, the first detection firmware is reconfigured, and a power-on test is performed again until the connection is successful. Thus, by automatically obtaining the target model parameters, configuring the detection firmware, and testing the connection status, intelligent adaptation to different computing board models is achieved, improving repair efficiency, reducing labor costs, minimizing the risk of misdiagnosis, and enhancing cross-brand compatibility.

[0090] It should be noted that the technology involved in this embodiment and subsequent embodiments mainly refers to the computing board, but the controllable power supply, cooling fan, server, control board, etc. that power the computing board can all be implemented by the method of this embodiment and subsequent embodiments. That is, the compatible method of this embodiment can be applied to the intelligent diagnosis scenario of the computing board and its peripheral devices. The intelligent diagnosis of faults in its peripheral scenarios is also within the protection scope of this embodiment and subsequent embodiments. All technical solutions that use this embodiment and subsequent embodiments to perform intelligent diagnosis of the computing board and its peripheral devices are within the protection scope of this invention.

[0091] In practice, when faced with a wide variety of computing boards to be tested with different parameters, how to efficiently and accurately generate suitable testing firmware based on their complex and diverse target model parameters is a technical problem that needs to be solved. If the configuration is not correct, it may lead to failure in connection status judgment, thereby affecting the efficiency and accuracy of fault diagnosis.

[0092] Therefore, referring to Figure 2 Another embodiment of the present invention provides a model compatibility method, based on the above. Figure 1 The embodiment shown configures a first detection firmware corresponding to the target model parameters, including steps S210-S220, wherein:

[0093] S210, In response to the input operation of the target model parameter of the computing board under test, determine the firmware configuration rules and configuration parameters of the target model parameter;

[0094] S220: Generate the first detection firmware according to the firmware configuration rules and configuration parameters.

[0095] The input of the target model parameters for the computing board under test (TBT) signifies the initiation of the firmware configuration process. This means the user or system starts the subsequent firmware generation process by inputting the specific model parameters of the TBT. This input can be done manually by the user through the display interface of the intelligent fault diagnostic instrument or a connected external device (e.g., a keyboard or touchscreen), where the target model parameters, such as model name, communication protocol type, and pin definitions, can be entered manually. Alternatively, the system can scan or recognize markings on the TBT (e.g., QR codes, barcodes, NFC tags) to automatically obtain the target model parameters and simulate the input operation.

[0096] Determining the firmware configuration rules and parameters for the target model refers to the internal logic of the fault analysis device identifying the guiding principles and specific values ​​used to build the firmware based on the input target model parameters. Firmware configuration rules define the firmware's structure, modules, protocol framework, etc., while configuration parameters are the specific data that populates these rules. This determination process can be achieved by using a pre-set rule and parameter library within the system. Based on the input target model parameters, the system retrieves the corresponding firmware configuration rules (e.g., firmware templates for specific communication protocols) and configuration parameters (e.g., specific control commands and timing parameters) from the library through querying, matching, or logical judgment. Alternatively, this determination process can be implemented by the system parsing the structure of the target model parameters and dynamically generating or combining firmware configuration rules (e.g., dynamically building a protocol stack based on the communication protocol type) and configuration parameters (e.g., parsing the binary code of control commands from the datasheet).

[0097] Generating the first detection firmware according to the firmware configuration rules and parameters refers to the process of converting the previously determined rules and parameters into an executable firmware file. This can be done automatically or manually after the user inputs data in the background. It concretizes abstract configuration information into actual program code or data structures. This generation process can be performed by the system using a firmware generator or compiler, combining firmware configuration rules (such as code templates or scripts) with configuration parameters (such as variables or constants) to compile or link and generate a programmable binary file (such as a hex file or a bin file). Alternatively, this generation process can be implemented by the system through a visual interface or scripting language, dynamically assembling or modifying specific parts of the firmware according to firmware configuration rules (such as modular components) and configuration parameters (such as attribute values), and exporting them as an executable firmware file. This process can also be achieved by the user manually writing firmware code based on configuration rules and parameters, and then having the system compile it to generate the first detection firmware, ensuring high flexibility and customization capabilities in special scenarios.

[0098] Through the above technical solution, after receiving input of the target model parameters for the computing board under test, the intelligent fault diagnostic instrument can intelligently identify and determine the firmware configuration rules and specific configuration parameters that match the target model parameters. Subsequently, the fault analysis device automatically generates the adapted first detection firmware based on these determined rules and parameters. This mechanism avoids the tediousness and error-proneness of modifying firmware, ensuring the accuracy of the generated firmware and its compatibility with the computing board under test. This enables the intelligent fault diagnostic instrument to quickly and accurately configure the detection firmware for different models of computing boards under test, thereby significantly improving configuration efficiency and providing a reliable foundation for subsequent power-on testing operations. It effectively solves the connection failure problem caused by improper firmware configuration, and thus optimizes the execution process of the entire model compatibility method.

[0099] In one specific implementation, when the intelligent fault diagnostic instrument needs to perform compatibility testing on a new model of computing board, the operator can select the name of the new model through the diagnostic instrument's touchscreen interface, or enter the target model parameters by scanning the model identification code on the computing board. Upon receiving the model parameters, the fault analysis device immediately retrieves the firmware configuration rules associated with that model from its internal database. These rules include, for example, the communication protocol type (such as SPI, I2C, or UART), data transmission rate, and specific control instruction set used by the computing board. The fault analysis device also extracts the configuration parameters corresponding to these rules, such as register addresses, data bit widths, and checksum algorithms. Subsequently, a firmware generation module / script automatically fills in a preset firmware template based on these rules and parameters and compiles it to generate a dedicated first-test firmware for the new model of computing board. For example, this firmware may contain code logic for initializing a specific communication interface, sending specific handshake commands, and receiving and parsing response data. This generated firmware is then loaded into the diagnostic instrument's processor for subsequent power-on testing. Alternatively, operators can manually write detection logic code suitable for the new model of computing board, input it into the integrated development environment of the intelligent fault diagnostic instrument for compilation to generate the first detection firmware, and then write it into the storage unit of the intelligent fault diagnostic instrument through a burning tool.

[0100] Through the above technical solutions, the intelligent fault diagnostic instrument can automatically, semi-automatically, or manually generate test firmware for different models of computing boards under test, greatly improving the efficiency and accuracy of firmware configuration. It ensures that the generated initial test firmware is highly compatible with the model parameters of the computing board under test. Therefore, during power-on testing, the connection status with the computing board under test can be determined more reliably, reducing connection failures caused by firmware incompatibility. This improves the overall compatibility and diagnostic efficiency of the intelligent fault diagnostic instrument, while lowering the technical threshold and workload for operators.

[0101] In practice, it is urgent to solve the problem of how to accurately derive the specific communication protocol, control command code and data format from these parameters and effectively integrate them into the firmware to ensure that the generated firmware can communicate accurately with the computing board under test.

[0102] Therefore, referring to Figure 3 Another embodiment of the present invention provides a model compatibility method, based on the above. Figure 2 The illustrated embodiment generates a first detection firmware according to firmware configuration rules and configuration parameters, including steps S221-S224, wherein:

[0103] S221. Determine the communication protocol type based on the communication line pin arrangement of the target model parameters;

[0104] S222. Determine the control instruction code corresponding to the configuration parameters;

[0105] S223. Determine the corresponding communication data format based on the communication protocol type and control command code;

[0106] S224. Configure control command codes according to firmware configuration rules and communication data format, and generate the corresponding first detection firmware.

[0107] Among them, determining the communication protocol type by the pin arrangement of the communication line aims to identify the communication standard adopted by the computing board under test from the physical connection characteristics.

[0108] Communication pinout refers to the functional definition and physical layout of each pin on the connection interface. Different pinouts often correspond to different communication protocols, such as SPI, I2C, UART, and PCIe. Intelligent fault diagnostic tools can internally store a mapping table between communication pinouts and communication protocol types. By consulting this table, the corresponding communication protocol type can be determined. Alternatively, intelligent fault diagnostic tools can perform pattern recognition or algorithm analysis based on the characteristics of the communication pinout to infer the most likely communication protocol type.

[0109] The purpose of determining control command codes through configuration parameters is to generate or select specific command sequences for controlling the computing board under test based on configuration parameters set by the user or system. Configuration parameters can include commands for operations such as initializing the computing board, reading its status, writing data, and executing specific functions. The intelligent fault diagnostic instrument can internally store an command library containing control command code templates corresponding to various commonly used operations, retrieving and selecting the appropriate control command code based on the input configuration parameters. Alternatively, the intelligent fault diagnostic instrument can provide a command generator. The user inputs high-level operation commands or parameters, and the generator automatically converts these commands into low-level control command codes conforming to specific protocol specifications according to preset rules and syntax.

[0110] Determining the communication data format ensures that control command codes can be transmitted with the correct structure and encoding method through the selected communication protocol. The communication data format defines the structure of the data packet, including start bits, stop bits, data bits, parity bits, address bits, command bits, and the data encoding method. The intelligent fault diagnostic instrument can maintain a rule base that associates communication protocol types with data formats. Once the communication protocol type and control command code are determined, the system automatically matches the most suitable data format based on this rule base. Alternatively, the determination of the data format can be closely integrated with the control command code generation process, taking into account the data format requirements of the target communication protocol during the generation of the control command code.

[0111] The process of configuring control command codes and generating the first detection firmware based on firmware configuration rules and communication data formats involves integrating and compiling the previously determined communication protocol type, control command codes, and communication data formats into an executable first detection firmware according to preset firmware configuration rules. Firmware configuration rules may include the overall firmware structure, module division, memory allocation, interrupt handling mechanisms, and how to embed control command codes into specific functional modules of the firmware. The intelligent fault diagnostic instrument can include a firmware generation engine that receives the communication protocol type, control command codes, communication data format, and firmware configuration rules as input. Based on these inputs, it automatically fills in firmware templates, compiles code, and links library files, ultimately generating the first detection firmware that can be burned into the diagnostic instrument. Alternatively, firmware generation can be automated through scripts; for example, a script can dynamically generate source code files based on input parameters, and then a cross-compiler can be called to compile the source code into the target firmware.

[0112] This embodiment ensures the accuracy and compatibility of the firmware by detailing the generation process of the first detection firmware into a series of logical steps. First, the intelligent fault diagnostic instrument identifies the communication protocol type used by the computing board under test based on the communication pin arrangement included in the target model parameters. This identification process is fundamental because it determines the rules for subsequent data transmission and parsing. Next, the fault analysis device determines the control command codes to be sent to the computing board under test based on preset configuration parameters. These commands are crucial for implementing the detection function. After clarifying the communication protocol type and control command codes, the fault analysis device further determines the communication data format that matches them, including the structure of the data packets and the encoding method, ensuring that the commands can be correctly received and understood by the computing board under test. Finally, the intelligent fault diagnostic instrument integrates and compiles these determined communication protocol types, control command codes, and communication data formats with the firmware configuration rules to generate the first detection firmware capable of effectively communicating with a specific model of computing board. This step-by-step, precise derivation and configuration process effectively solves the complexity of generating specific firmware under general rules, enabling the intelligent fault diagnostic instrument to automatically generate highly compatible detection firmware for different models of computing boards under test, thereby improving the efficiency and accuracy of model compatibility.

[0113] As a specific implementation method, suppose the intelligent fault diagnostic instrument needs to be compatible with a new model of computing board under test. First, the intelligent fault diagnostic instrument obtains the target model parameters of the computing board under test, which includes its communication pinout information. For example, the connection interface of the computing board defines SDA (data line) and SCL (clock line) pins. Based on this communication pinout, the intelligent fault diagnostic instrument can identify that the computing board uses the I2C communication protocol. Furthermore, the user or system sets configuration parameters, such as needing to read a certain register of the computing board to obtain its device ID. Based on these configuration parameters, the intelligent fault diagnostic instrument determines the corresponding control instruction code, for example, an I2C read register instruction sequence, including the device address, register address, and read operation command. After determining the I2C communication protocol type and the read register control instruction code, the intelligent fault diagnostic instrument further determines the corresponding communication data format, such as the I2C protocol start conditions, 7-bit device address, read / write bits, 8-bit data byte, acknowledge bit, stop condition, etc. Finally, the intelligent fault diagnostic tool combines this information with preset firmware configuration rules (e.g., the calling interface of the I2C driver module in the firmware, data buffer settings, etc.) to configure the control instruction code and generate the first detection firmware that can be used for this new model of computing board. This firmware will contain logic for sending read register commands via the I2C protocol and parsing the returned data.

[0114] Through the above technical solution, the intelligent fault diagnostic instrument can systematically extract key communication information from the target model parameters. This key communication information includes the communication protocol type, control command code, and communication data format. This refined parameter parsing and firmware configuration process significantly improves the matching accuracy and compatibility between the first detection firmware and the computing board under test. It reduces the reliance on operator expertise, thereby increasing the automation and efficiency of firmware generation. Ultimately, this enables the intelligent fault diagnostic instrument to quickly and accurately adapt to various different models of computing boards under test, effectively solving the technical challenge of achieving model compatibility in complex and diverse hardware environments.

[0115] In the process of generating the first test firmware according to the firmware configuration rules and parameters, relying solely on user-input configuration parameters and preset rules may be insufficient to handle the complex differences in communication protocols and instruction sets between different models of computing boards. This could result in the generated firmware failing to communicate accurately with the computing board under test, thus affecting the success rate of power-on testing and the accuracy of diagnosis.

[0116] Therefore, referring to Figure 4 In another embodiment of the present invention, a model compatibility method is provided, based on the above. Figure 2The embodiment shown generates the first detection firmware according to the firmware configuration rules and configuration parameters, including steps S225-S226, wherein:

[0117] S225. Determine the communication protocol matching strategy, communication line sequence, and instruction mapping relationship in the firmware configuration rules;

[0118] S226. In response to the control command code entered by the user according to the communication protocol matching strategy, communication line sequence and command mapping relationship, parse the syntax structure and protocol compatibility of the control command code, and generate the first detection firmware.

[0119] The determination of communication protocol matching strategies, communication pin sequences, and instruction mapping relationships in the firmware configuration rules aims to provide a clear guiding framework for firmware generation. The communication protocol matching strategy refers to a set of rules used to identify and select specific protocols (such as I2C, SPI, UART, PCIe, etc.) to be followed when communicating with the computing board under test. Its function is to ensure that the intelligent fault diagnostic instrument can establish the correct communication link with different models of computing boards. Implementation methods may include: pre-setting a protocol priority list and automatically matching it according to the model or characteristics of the computing board; or providing a user interface that allows users to manually select or configure the applicable communication protocol. The communication pin sequence refers to the arrangement and functional definition of the physical connection pins between the intelligent fault diagnostic instrument and the computing board under test. Its function is to ensure that data signals can be correctly transmitted between the diagnostic instrument and the computing board. Implementation methods may include: obtaining pin sequence information by consulting the hardware manual or specification sheet of the computing board under test; or automatically identifying the function of the connection pins through the pin sequence detection module inside the intelligent fault diagnostic instrument. Instruction mapping refers to the rules that translate user-inputted general control commands or high-level commands into corresponding low-level instruction sets or register operations that the computing board under test can understand and execute. Its purpose is to enable the diagnostic tool to send valid control commands to test the computing board's functionality. Implementation methods may include: establishing an instruction translation table to map general commands to the register addresses and data bits of a specific computing board model; or defining a scripting language that allows users to write custom instruction translation logic. In response to the control command code entered by the user according to the communication protocol matching strategy, communication line sequence, and instruction mapping, the syntax structure and protocol compatibility of the control command code are parsed, and the first detection firmware is generated.

[0120] The section on response to user-input control command codes, based on communication protocol matching strategies, communication line sequences, and command mapping relationships, describes the triggering conditions and basis for user-input control command codes. When entering control command codes, users refer to or follow pre-determined communication protocol matching strategies, communication line sequences, and command mapping relationships to ensure that the input commands are valid for a specific computing board model and conform to its communication specifications. Its function is to provide accurate input for subsequent parsing and firmware generation. Implementation methods may include: providing a graphical user interface (GUI) to guide users in inputting command codes conforming to a specific format; or allowing users to input predefined command scripts via a command-line interface (CLI). Parsing the syntax structure and protocol compatibility of control command codes refers to analyzing the user-input control command codes to verify whether they conform to expected syntax rules and whether they are compatible with the selected communication protocol and the characteristics of the computing board under test. Its function is to ensure that the generated firmware can send valid commands that can be correctly interpreted by the computing board, avoiding communication failures due to incorrect command formats or protocol mismatches. Implementation methods may include: using a parser / compiler to check whether the structure of the instruction code conforms to preset grammar rules; or comparing it with the communication protocol specification to verify whether the parameters, timing, etc., in the instruction meet the protocol requirements. Generating the first detection firmware refers to compiling or assembling the parsed and verified control instruction code, combined with other information in the firmware configuration rules, into an executable firmware program. Its function is to provide a program that can be directly run on the intelligent fault diagnostic instrument for communication and testing with the computing board under test. Implementation methods may include: embedding the parsed instruction code into a preset firmware template, then compiling and linking it to generate a binary file (such as .hex or .bin); or dynamically generating specific functional modules of the firmware through configuration parameters.

[0121] This embodiment, by first clearly defining the communication protocol matching strategy, communication line sequence, and instruction mapping relationship in the firmware configuration rules when generating the first detection firmware, provides a clear basis for users to input control command codes. When the user inputs the control command code according to these strategies, line sequences, and mapping relationships, the system performs syntax structure and protocol compatibility parsing. This parsing process not only ensures the correctness of the command code itself, but more importantly, it verifies the compatibility of the command code with the target computing board's communication protocol, thereby avoiding communication errors caused by incompatible command formats or protocols. In this way, the system can generate highly customized and reliable first detection firmware that can accurately communicate with the computing board under test, effectively solving the connection failure problem caused by instruction incompatibility or configuration errors, and significantly improving the firmware generation quality and test success rate.

[0122] As a specific implementation method, when configuring the first detection firmware, the intelligent fault diagnostic instrument can first display a configuration interface (such as STM32CubeMX software) to the user. In this configuration interface, the user can select a preset communication protocol matching strategy based on the model of the computing board under test, such as selecting "PCIe Gen4" or "DDR5 JEDEC standard". The user can also consult the computing board's specifications and input or select the corresponding communication pin sequence in the interface, such as specifying "pin 1 as CLK, pin 2 as DATA0, pin 3 as DATA1", etc. Furthermore, the system can provide an instruction mapping library, from which the user can select or customize mappings of general test instructions (such as "reading the temperature sensor") to the register addresses and read / write commands of a specific computing board (such as "sending read command 0x01 to address 0x100"). When the user enters specific control command codes, such as "READ_TEMP_SENSOR_0x100," into the input box based on this information, the system immediately performs a syntax check on the command code. This includes verifying whether "READ_TEMP_SENSOR" is a predefined operation and whether "0x100" is a valid address format. Simultaneously, the system checks whether the command conforms to the PCIe protocol's packet format and timing requirements, based on the previously selected "PCIe Gen4" protocol. For example, if the command attempts to send an I2C format packet via PCIe, the system will indicate protocol incompatibility. Only after the command code's syntax and protocol compatibility have been verified will the system combine the command code with other parameters in the firmware configuration rules (such as clock frequency and data transfer rate) and automatically compile it into an executable binary file—the first test firmware—using a firmware generator. This firmware is then loaded into the diagnostic tool for power-on testing with the computing board under test.

[0123] Through the above technical solution, the intelligent fault diagnostic instrument, when generating the first detection firmware, can provide users with clear configuration guidance through explicit communication protocol matching strategies, communication line sequences, and command mapping relationships. Based on this, it performs syntax structure and protocol compatibility parsing on the user-input control command codes, effectively avoiding firmware generation failures or test communication anomalies caused by incorrect command formats or protocol mismatches. This significantly improves the generation efficiency and accuracy of the first detection firmware, ensuring that the firmware can establish a stable and reliable communication connection with the computing board under test, thereby enhancing the intelligent fault diagnostic instrument's compatibility with different models of computing boards and improving the success rate of fault diagnosis.

[0124] During the configuration of the first detection firmware, for Figures 2 to 4In the implementation of the method, when manually acquiring and inputting parameters such as preset firmware configuration templates, communication line pin arrangements and corresponding control command codes for different models of computing boards under test, there are inefficiencies, errors are easy to make, and it is difficult to cope with the increasing number of computing board models, thus affecting the efficiency and accuracy of model compatibility.

[0125] Therefore, referring to Figure 5 The present invention also provides a model compatibility method based on the above. Figure 1 The embodiment shown configures a first detection firmware corresponding to the target model parameters, including steps S230-S270, wherein:

[0126] S230. Establish a network communication link with an external or internal database;

[0127] S240: Obtain the preset firmware configuration template matching the target model parameters, the communication line pin arrangement of the target model parameters, and the corresponding control instruction code stored in the external or internal database.

[0128] S250. Determine the communication protocol type based on the communication line pin arrangement;

[0129] S260. Determine the corresponding communication data format based on the communication protocol type and control command code;

[0130] S270. The control command code is placed into the firmware configuration template according to the communication data format to generate the first detection firmware.

[0131] Establishing a network communication link with an external or internal database is designed to ensure that the intelligent fault diagnostic instrument can access the database storing firmware configuration information. This link can be established in various ways. For example, the intelligent fault diagnostic instrument can connect via a wired Ethernet connection using the TCP / IP protocol to establish a connection with the database server; alternatively, it can connect via a wireless LAN (Wi-Fi) or cellular network (such as 4G / 5G) and access a cloud database or a database on a remote server via the HTTP / HTTPS protocol.

[0132] The system retrieves pre-configured firmware templates matching the target model parameters, communication pin arrangements, and corresponding control command codes stored in the external or internal database. Its function is to automatically retrieve and obtain the core data required to construct the first test firmware. Specifically, the intelligent fault diagnostic instrument can send a query request to the database, including the target model parameters of the computing board under test as query conditions. The database then returns matching pre-configured firmware templates, communication pin arrangements, and control command codes. Furthermore, the database can be pre-configured to automatically push relevant data based on the received target model parameters, or the intelligent fault diagnostic instrument can periodically synchronize the latest configuration information in the database and perform matching searches locally.

[0133] The communication protocol type is determined based on the communication line pin arrangement. The purpose is to infer the rules followed by data transmission from the physical connection information. This can be done by looking up a mapping table between communication line pin arrangements and communication protocol types stored internally in the intelligent fault diagnostic instrument. For example, a specific pin combination may correspond to protocols such as UART, SPI, I2C, or PCIe. Alternatively, the communication protocol type can be dynamically identified by analyzing the characteristics of the communication line pin arrangement (such as the number of differential signal pairs, clock lines, and data lines) and combining this with a preset protocol identification algorithm.

[0134] Based on the communication protocol type and the control command code, the corresponding communication data format is determined to ensure that control commands can be transmitted with the correct structure and encoding. The intelligent fault diagnostic instrument can have a built-in rule base for associating communication protocol types and data formats. Based on the determined communication protocol type and control command code, it matches the corresponding data frame structure, checksum, start / end characters, and other format information from the rule base. Alternatively, it can call a predefined communication protocol parsing module or library function, inputting the communication protocol type and control command code, and the module will automatically generate a data format definition conforming to the protocol specification.

[0135] The control instruction code is placed into the firmware configuration template according to the communication data format to generate the first detection firmware. Its function is to integrate the acquired instructions and format information into the firmware template to form an executable detection firmware. The firmware configuration template may contain placeholders. The intelligent fault diagnostic instrument fills these placeholders with the formatted control instruction code and performs compilation or linking operations to generate a programmable binary file (such as a hex or bin file). Alternatively, the firmware configuration template can also be a script or configuration file. The intelligent fault diagnostic instrument dynamically modifies the parameters in the script or generates a new configuration file according to the communication data format, and then packages it into the first detection firmware using a firmware generation tool.

[0136] This application's solution establishes a network communication link with an external or internal database, enabling the intelligent fault diagnostic instrument to automatically access a database containing rich configuration information. When configuring the first detection firmware, the intelligent fault diagnostic instrument can accurately retrieve the matching preset firmware configuration template, communication pin arrangement, and corresponding control command code from the database based on the target model parameters of the computing board under test. Subsequently, the fault analysis device intelligently determines the applicable communication protocol type based on the obtained communication pin arrangement and, combined with the control command code, derives the precise communication data format. Finally, the intelligent fault diagnostic instrument automatically inserts these formatted control command codes into the preset firmware configuration template according to the determined communication data format, thereby efficiently and accurately generating the first detection firmware. This series of automated steps avoids manual intervention, significantly improves the efficiency and accuracy of firmware configuration, and provides a reliable foundation for subsequent connection status determination. In this way, the intelligent fault diagnostic instrument can quickly adapt to different models of computing boards under test, achieving automated and intelligent model compatibility.

[0137] In one specific implementation, the intelligent fault diagnostic instrument can also have a built-in Ethernet interface, connecting to a server on the enterprise's internal LAN via a standard RJ45 network cable. Alternatively, it can establish a secure connection to a cloud database via an internal wireless network module such as Wi-Fi or Bluetooth, using lightweight communication protocols (such as MQTT or HTTP). An internal database is deployed on this server, storing configuration data for hundreds of different computing board models. This includes firmware configuration templates for specific models (e.g., a general C language firmware framework with reserved macro definition areas for protocols and instructions), the communication pinout for that model (e.g., "TXD-RXD-GND" corresponding to the UART protocol), and the corresponding control command codes (e.g., "0xAA 0xBB 0xCC" for requesting the device ID). When the user selects the model of the computing board to be tested, the intelligent fault diagnostic instrument sends the model parameters to the server via an HTTP request. The server queries the database and returns the matching firmware configuration template, communication pinout, and control command codes. After receiving data, the intelligent fault diagnostic instrument automatically identifies the communication protocol type as UART based on the pinout “TXD-RXD-GND”. Next, combining the UART protocol type and control command code “0xAA 0xBB 0xCC”, it determines the communication data format to be 8 data bits, no parity, 1 stop bit, and includes a start byte and an end byte. Finally, the intelligent fault diagnostic instrument fills the formatted control command code into the predefined UART transmit function body in the firmware configuration template, compiles it, and generates the first detection firmware that can be burned into the diagnostic instrument's microcontroller.

[0138] Through the above technical solutions, the intelligent fault diagnostic instrument can automate and intelligently configure the first detection firmware. Since the configuration parameters are automatically obtained and processed from a pre-set database, errors and omissions that may occur due to manual input are avoided, significantly improving configuration accuracy. Furthermore, this automated process greatly shortens the time required for compatibility configuration of new or different computing boards, improving the overall efficiency of the fault diagnostic instrument. In addition, centralized management of configuration information through a database facilitates unified maintenance and updates for different models of computing boards, ensuring the flexibility and scalability of the model compatibility method, thus effectively solving the technical problems of low efficiency, error-proneness, and difficulty in handling multiple models of computing boards during manual configuration.

[0139] In practice, ensuring that the first detection firmware can effectively initiate communication with the computing board under test and accurately determine whether the connection is successful from complex signal feedback is the key issue for achieving model compatibility.

[0140] Therefore, referring to Figure 6 Another embodiment of the present invention provides a model compatibility method, based on the above. Figure 1 The illustrated embodiment, in response to a power-on test operation on the computing power board under test, runs the first detection firmware to determine the connection status with the computing power board under test, including steps S310-S320, wherein:

[0141] S310, In response to a power-on test operation on the computing board under test, the first detection firmware is run and the first detection data is sent through the connection interface;

[0142] S320: Monitor the connection status signal returned by the connection interface, and parse the connection status signal through the first detection firmware to determine the connection status.

[0143] In this process, responding to a power-on test operation on the computing board under test, running the first detection firmware and sending the first detection data through the connection interface is the initial action to initiate communication with the computing board under test. The power-on test operation is an external event that triggers the entire testing process. Running the first detection firmware means loading and executing a pre-configured detection program specific to the model. Sending the first detection data is the firmware actively initiating communication to detect the presence of the computing board under test and respond accordingly.

[0144] As one implementation, after receiving the "power-on test" command from the user via the display device, the processor of the intelligent fault diagnostic instrument loads the pre-configured first detection firmware into its internal memory or external executable memory and starts the firmware execution. After the firmware is executed, the first detection data (e.g., a simple "handshake" command or device ID request) is sent to the computing board under test in the form of an electrical signal through the physical layer driver circuit of the connection interface, according to the communication protocol and data format defined in the firmware.

[0145] In another implementation, the intelligent fault diagnostic instrument can integrate a dedicated firmware execution module. This module, upon detecting a test board connected to the connection interface and receiving a power-on test signal, automatically reads and runs the first detection firmware from memory. This firmware then encapsulates the preset first detection data frame into an electrical signal conforming to a specific protocol (such as SPI, I2C, UART, etc.) via the communication controller of the connection interface, and sends it out through the pins of the connection interface.

[0146] Monitoring the connection status signal returned by the connection interface and parsing the connection status signal through the first detection firmware to determine the connection status is equivalent to receiving and understanding the feedback from the computing board under test, thereby determining whether communication has been established. Monitoring the connection status signal refers to continuously or periodically checking changes in the electrical signals on the connection interface. Parsing the signal through the first detection firmware means that the firmware contains logic to identify and interpret these signals in order to extract meaningful information.

[0147] As one implementation, the processor of the intelligent fault diagnostic instrument continuously monitors electrical signals from the computing board under test via the receiving circuit of the connection interface. When a signal is received, the processor transmits this raw electrical signal data to the running first detection firmware. The firmware decodes and verifies the received signal according to its internally preset communication protocol and data format, such as checking the frame header, frame trailer, checksum, and identifying whether it contains the expected response data or device identifier. If the parsing is successful and matches the expected response pattern, the connection status is determined to be successful; otherwise, it is considered a failure.

[0148] The solution proposed in this application initiates communication with the computing board under test (DUT) by running a pre-configured first detection firmware in response to a power-on test operation. This first detection firmware actively sends first detection data through the connection interface. Subsequently, the fault analysis device monitors the connection status signal returned by the connection interface, and the first detection firmware analyzes the received signal to determine the connection status. This approach ensures that the connection status determination is not merely a simple physical connection detection, but rather involves proactive communication and intelligent analysis through model-specific firmware, thereby accurately identifying whether the DUT is responding according to its specific protocol. This makes the determination of the connection status more reliable and accurate, effectively solving the technical problem of accurately determining the communication connection status when dealing with various types of computing boards.

[0149] In one implementation of this embodiment, it is assumed that the computing board under test (DUT) uses the SPI (Serial Peripheral Interface) communication protocol. When the user selects the DUT model on the display device of the intelligent fault diagnostic instrument and triggers the "Power-On Test" operation, the processor of the intelligent fault diagnostic instrument loads and runs the first detection firmware configured for that SPI model. This firmware is programmed to send a specific "Device ID Read" command through the SPI pins (e.g., SCK, MOSI, MISO, CS) of the connection interface. This command is converted into an electrical signal and sent to the DUT through the MOSI pin of the connection interface. The connection interface of the intelligent fault diagnostic instrument continuously listens to its MISO pin. Once an electrical signal is received from the DUT, it is sent to the first detection firmware. The firmware decodes the received data stream according to a preset SPI protocol (e.g., clock polarity, clock phase, data bit width). The firmware searches for a specific response pattern; for example, if the DUT successfully receives the "Device ID Read" command, it may return its own model identification data through the MISO pin. The first firmware test parses the returned data and compares it with the expected model identifier. If the comparison is successful and a response is received within a preset time window, the firmware determines the connection status as "successful"; otherwise, if no response is received, an error response is received, or the response times out, the connection status is determined to be "failed".

[0150] Through the above technical solution, the intelligent fault diagnostic instrument can accurately determine the connection status of different models of computing boards under test by actively sending test data and having the returned signals intelligently parsed by the model-specific firmware. This significantly improves the accuracy and reliability of connection testing, avoids misjudgments caused by incompatible communication protocols or data formats, and thus makes the model compatibility process more efficient and stable.

[0151] When intelligent fault diagnostic instruments perform power-on tests on different models of computing boards under test, it is necessary to accurately determine the connection status with the board. However, simply monitoring the connection status signal returned by the connection interface and performing preliminary analysis may not be sufficient to fully confirm the validity of the connection or whether the computing board under test fully matches the expected target model parameters. This may lead to false positives for successful connection, thereby affecting the accuracy of subsequent diagnostics, or failing to detect problems in a timely manner when the actual hardware configuration does not match the target model parameters, thus reducing the reliability of model compatibility and diagnostic efficiency.

[0152] Therefore, referring to Figure 7 Another embodiment of the present invention provides a model compatibility method, based on the above. Figure 6 The embodiment shown includes target model parameters such as communication wiring sequence and corresponding data format; monitoring the connection status signal returned by the connection interface and parsing the connection status signal through the first detection firmware to determine the connection status, including steps S321-S324, wherein:

[0153] S321. Acquire the level change status of the connection interface at preset intervals;

[0154] S322. When there is a level transition in the level change state and it conforms to the characteristics of the preset communication protocol, determine that the connection interface returns a connection status signal;

[0155] S323. The first detection firmware parses the connection status signal according to the data format and extracts the model identifier and communication response timing.

[0156] S324. Based on the model identifier and communication response timing, determine that the target model parameters match the actual hardware configuration of the computing board under test, and determine that the connection status is a valid communication establishment.

[0157] The system acquires the voltage level changes of the connection interface at preset intervals, aiming to periodically sample the electrical signals of the connection interface to capture its dynamic changes. The preset interval can be a fixed time interval, such as a microsecond or millisecond period, implemented through a timer interrupt or software loop. Its function is to continuously monitor the activity of the connection interface, providing basic data for subsequent determination of the presence of communication signals. For example, by configuring the microcontroller's general-purpose input / output pins to input mode and combining this with a timer interrupt service routine, the voltage level of the pins can be read at the end of each preset interval.

[0158] Another implementation method utilizes a dedicated level detection circuit. This circuit triggers an interrupt upon detecting a level change, thereby avoiding continuous polling and improving efficiency. When a level change occurs and conforms to the preset communication protocol characteristics, the connection interface returns a connection status signal, which is used to identify valid communication signals from continuous level changes.

[0159] Level transitions refer to the instantaneous change of a signal from a high level to a low level or vice versa, which is a fundamental characteristic of digital communication signals. Preset communication protocol characteristics refer to the signal timing, baud rate, start bit, stop bit, and data bit characteristics specified by a particular communication protocol (such as UART, SPI, I2C, etc.). By comparing the detected level transition patterns with the preset protocol characteristics, noise or non-communication signals can be filtered out, thereby accurately determining whether the connection interface is returning a valid connection status signal.

[0160] The process of parsing the connection status signal according to its data format using the first detection firmware involves decoding the determined connection status signal based on the data format contained in the target model parameters. The data format defines the meaning, length, and order of each field in the signal; for example, it can be a specific byte order, data packet structure, checksum, etc. The first detection firmware contains logic for parsing these data formats, such as converting the original level signal into meaningful data through shifting, masking, and bit manipulation. Extracting the model identifier and communication response timing is the specific output of the parsing process, aiming to identify two key pieces of information from the connection status signal: the model identifier and the communication response timing.

[0161] The model identifier is the model information reported by the computing board under test (TBT) itself, used to confirm its identity. The communication response timing refers to the time difference between the time the TBT sends its response signal and the time the command is sent after receiving the instruction, or the timestamp information within the response signal. Determining whether the target model parameters match the actual hardware configuration of the TBT based on the model identifier and communication response timing is the core matching judgment step. It compares the actual information obtained from the TBT (model identifier, communication response timing) with the target model parameters preset by the intelligent fault diagnostic instrument. The target model parameters include the expected model identifier and the expected range of communication response timing. Determining the connection status as valid communication establishment is the final connection status judgment result. The connection status is confirmed as "valid communication establishment" only when all the above matching conditions (model identifier matching, communication response timing meeting expectations) are met.

[0162] When the intelligent fault diagnostic instrument monitors the connection status between the connection interface and the computing board under test, this embodiment improves the reliability of the judgment by using a refined signal analysis and data parsing mechanism to ensure the validity of the connection and the accurate matching of the computing board model under test. First, the intelligent fault diagnostic instrument continuously acquires the level change status of the connection interface at preset intervals, allowing the fault analysis device to continuously capture any signal activity that the computing board under test may emit. When a level transition conforming to the characteristics of a preset communication protocol is detected in the level change status, the fault analysis device can accurately identify this as a valid connection status signal returned by the computing board under test, thus avoiding misjudgment of noise or irrelevant signals. Subsequently, the first detection firmware performs in-depth analysis of the connection status signal according to the preset data format in the target model parameters, accurately extracting the model identifier of the computing board under test and its communication response timing. This extracted key information is then compared with the target model parameters stored internally by the intelligent fault diagnostic instrument. Only when the model identifier reported by the computing board under test is completely consistent with the expected model identifier in the target model parameters, and its communication response timing also falls within the preset reasonable range, does the fault analysis device finally determine the connection status as "valid communication establishment". This multi-layered verification mechanism, from signal detection at the physical layer to data parsing at the protocol layer, and then to model matching at the application layer, ensures that the established connection is not only physically connected, but also logically matched and valid. This greatly improves the accuracy of model compatibility and the reliability of diagnosis, and effectively solves the problem that the validity of the connection cannot be confirmed by simple signal monitoring alone.

[0163] As a specific implementation, when the intelligent fault diagnostic instrument performs power-on testing, its processor can configure the general-purpose input / output pins of the connection interface to input mode and start a timer, for example, triggering an interrupt every 100 microseconds. In each interrupt service routine, the processor reads the level state of the general-purpose input / output pins and stores it in a circular buffer. When the level sequence in the buffer shows characteristics such as consecutive falling edges, continuous low levels, and rising edges, and these characteristics match the preset start bit, data bit, and stop bit timing of the UART protocol, the processor determines that a UART communication frame has been received. At this time, the first detection firmware will parse the received UART data frame according to the UART data format defined in the target model parameters (for example, the data packet consists of a one-byte start flag, a two-byte model identifier, a one-byte response timing value, and a two-byte CRC checksum). The firmware will extract the model identifier from a specific position in the data frame, such as "ABC-123", and extract the communication response timing, such as "15ms". Subsequently, the processor compares the extracted "ABC-123" with the expected model identifier in the target model parameters, and compares "15ms" with the preset response timing range (e.g., 10ms to 20ms) in the target model parameters. If the model identifier matches perfectly and the response timing is within the allowable range, the processor updates its internal state, marks the connection status as "valid communication established," and notifies the display device to display accordingly.

[0164] Through the aforementioned technical solution, the intelligent fault diagnostic instrument, when determining the connection status of the computing board under test, can move from detecting level changes at the physical level, to identifying signal characteristics at the protocol level, and then to accurately analyzing and matching model identification and communication response timing at the data level. This multi-dimensional and refined verification process effectively avoids connection misjudgments caused by communication protocol incompatibility, data format errors, or hardware model incompatibility, ensuring that the established connection is a truly "valid communication establishment." This not only significantly improves the accuracy and reliability of model compatibility but also provides a solid foundation for subsequent fault diagnosis, thereby enhancing the overall performance and user experience of the intelligent fault diagnostic instrument.

[0165] In actual operation, how to accurately and systematically obtain these key parameters, especially when the models of the computing boards to be tested are diverse and the information is scattered, may lead to problems of low efficiency and inconsistent data.

[0166] Therefore, referring to Figure 8 In another embodiment of the present invention, a model compatibility method is provided, based on the above. Figure 1 The embodiment shown obtains the target model parameters of the computing board under test, including steps S110-S140, wherein:

[0167] S110. Determine the communication wiring sequence between the computing board to be tested and the connection interface;

[0168] S120. Determine the corresponding data format according to the communication line sequence;

[0169] S130. Obtain the datasheet corresponding to the computing board under test and determine the corresponding control instruction code in the datasheet.

[0170] S140: Combine control command codes, communication wiring sequences, and data formats into target model parameters.

[0171] Determining the communication pin sequence between the computing board under test (DUT) and the connection interface refers to identifying the physical connection order and functional definition of each pin between the connection interface and the DUT. An accurate communication pin sequence is fundamental to establishing effective communication. This pin sequence can be determined manually by consulting the hardware design documents or specifications of the DUT, identifying and recording the functional definitions and arrangement order of each pin. Alternatively, it can be automatically identified and inferred using the pin sequence detection module within an intelligent fault diagnostic instrument, for example, by sending specific test signals and monitoring the responses of each pin.

[0172] Determining the corresponding data format based on the communication pin sequence refers to the encoding rules, frame structure, byte order, etc., followed during data transmission under a specific communication pin sequence. Different communication protocols (such as SPI, I2C, UART, PCIe, etc.) correspond to different data formats. After determining the communication pin sequence, the corresponding data format can be matched from a preset protocol library based on known communication protocol standards and the functional definition of the pin sequence (for example, identifying SDA and SCL pins may correspond to the I2C protocol). Alternatively, the user interface can allow operators to manually select or input the corresponding data format based on the identified pin sequence characteristics, such as selecting "SPI mode 0" or "UART 8N1".

[0173] Obtaining the datasheet corresponding to the computing board under test and determining the corresponding control command code in the datasheet refers to retrieving the official technical documentation of the hardware device and parsing out the specific command sequence used to operate, query status, or configure the computing board. This can be done by connecting to an external database via a network, such as the chip manufacturer's official website or technical support platform, and retrieving and downloading its datasheet based on the model information of the computing board under test (e.g., by scanning a barcode or manually entering it). Alternatively, a datasheet library can be pre-installed in the internal storage of the intelligent fault diagnostic instrument, and a local query can be performed using the model identifier of the computing board under test to obtain the corresponding datasheet content and parse out the control command code.

[0174] The process of compiling the control command codes, communication line sequences, and data formats into the target model parameters refers to integrating the independently acquired key information into a structured data set, forming a complete "target model parameter" for subsequent unified management and use. This information can be stored in a structure, object, or dictionary; for example, defining a data structure containing "control_commands," "line_sequence," and "data_format" fields. Alternatively, this information can be serialized into a file of a specific format (such as JSON, XML, or a custom text format) and saved to local storage or uploaded to the cloud for subsequent use by the firmware configuration module.

[0175] This embodiment systematically acquires the communication wiring sequence, data format, and control command codes of the computing board under test, and compiles this information into target model parameters, providing accurate and comprehensive basic data for subsequent configuration of the first testing firmware. This structured parameter acquisition process ensures that the generated testing firmware can accurately match the hardware characteristics and communication protocols of the computing board under test, thereby significantly improving the compatibility and diagnostic success rate of the intelligent fault diagnostic instrument when dealing with diverse computing boards. In this way, the intelligent fault diagnostic instrument can overcome connection failures caused by parameter mismatches, improving overall reliability and efficiency.

[0176] In one specific implementation of this embodiment, it is assumed that the intelligent fault diagnostic instrument is connected to a new type of AI computing board. First, the diagnostic instrument automatically identifies the communication interface of the AI ​​computing board as PCIe x16 through multiple channel pins of its connection interface, for example, by sending a low-voltage pulse signal and detecting the response. It then determines the specific pin arrangement of its Tx / Rx differential pairs, clock signal, power supply, and ground, thereby determining the communication pinout. Based on the identified PCIe x16 communication pinout, the diagnostic instrument automatically matches the PCIe Gen4 protocol and determines its corresponding data frame structure, encoding method (e.g., 128b / 130b encoding), and transmission rate, thus determining the data format. Subsequently, the diagnostic instrument connects to the manufacturer's online database via a network, inputs the model number of the AI ​​computing board (e.g., "NVIDIA A100"), and downloads its official datasheet. From the datasheet, it parses a series of control instruction codes used for initializing the PCIe link, querying the device ID, reading the temperature sensor, and performing memory self-tests. Finally, the PCIe x16 line sequence information, PCIe Gen4 data format, and control command codes extracted from the datasheet (such as "0x0100" for device ID lookup and "0x0200" for memory self-test) are integrated into a structured target model parameter and stored in the diagnostic tool's memory for use by the subsequent firmware generation module.

[0177] Through the above technical solution, the intelligent fault diagnostic instrument can systematically and accurately acquire the key model parameters of the computing board under test. This structured parameter acquisition method avoids errors and omissions that may be caused by manual input, ensuring that the subsequently generated testing firmware can accurately match the hardware characteristics of the computing board under test. Therefore, it significantly improves the accuracy and efficiency of model compatibility, reduces the connection failure rate caused by parameter mismatch, and thus enhances the overall reliability and user experience of the intelligent fault diagnostic instrument.

[0178] The present invention also proposes a fault analysis device, which includes: a memory, a processor, and a model compatibility program stored in the memory and capable of running on the processor, wherein the model compatibility program is configured to implement the above-described model compatibility method.

[0179] The core innovation of this embodiment lies in combining the memory, processor, and machine-compatible program through a dynamic adaptation mechanism. This enables automatic identification and communication configuration for multi-brand computing boards such as Antminer, Whatsminer, and Avalon, solving the problems of incompatible tools, high personnel barriers, and lack of cross-brand collaborative troubleshooting capabilities. This achieves the effects of reducing tool procurement and maintenance costs, shortening personnel training cycles, and improving the accuracy of cross-brand fault diagnosis. Specifically, the control device, by running the machine-compatible program, can obtain the target model parameters of the computing board under test, including control command data, communication wiring sequence, and the data format corresponding to the communication wiring sequence. Based on this, it configures the first detection firmware corresponding to the target model parameters. Upon power-on test operation, the first detection firmware sends detection data through the connection interface and parses the returned connection status signal. If the connection status fails, the firmware is automatically reconfigured and retried until effective communication is successfully established.

[0180] It is worth noting that since the fault analysis device of the present invention is based on the above-mentioned model compatibility method, the embodiments of the fault analysis device of the present invention include all the technical solutions of all embodiments of the above-mentioned model compatibility method, and the technical effects achieved are exactly the same, so they will not be repeated here.

[0181] This invention also proposes an intelligent fault diagnosis instrument comprising a display device, a connection interface, and a fault analysis device as described in all the embodiments above, wherein:

[0182] The display device is used for visual interaction during power-on testing or to present the connection status of the computing board under test; the connection interface is used to connect to the computing board under test, and the connection interface has multiple channel pins for transmitting different communication line sequences; the fault analysis device is electrically connected to the connection interface and the display device respectively; the fault analysis device is used to obtain the target model parameters of the computing board under test through the connection interface, configure the first detection firmware corresponding to the target model parameters, and in response to the power-on testing operation of the display device for the computing board under test, run the first detection firmware, determine the connection status with the computing board under test, and determine whether the connection status is normal. If the connection status is failed, the corresponding fault prompt is generated and the display device is controlled to display it, and the first detection firmware is reconfigured and the power-on testing operation is performed until the connection status is successful.

[0183] The core innovation of this embodiment lies in combining the dynamic acquisition of target model parameters with the automatic configuration of the first detection firmware to verify the connection status. This solves the problems of incompatibility of repair tools for different brands of computing boards and reliance on personnel experience, achieving the effects of reducing tool costs and simplifying operation processes. Specifically, this solution allows a single diagnostic instrument to be adapted to multiple brands of computing boards, such as Antminer, Whatsminer, and Avalon, eliminating the need to purchase dedicated tools for each brand, significantly reducing tool procurement and maintenance costs. Simultaneously, through the iterative process of connection status verification, operators do not need to memorize the fault logic of different brands; they only need to adjust the configuration parameters according to the prompts on the display device to complete fault diagnosis of cross-brand components, effectively reducing personnel training time and the risk of misjudgment. For example, when troubleshooting the linkage fault between a brand A power supply and a brand B computing board, the diagnostic instrument can quickly locate communication line sequence or instruction code matching problems by reconfiguring the first detection firmware and repeatedly testing, avoiding the tedious process of traditional manual troubleshooting.

[0184] It is worth noting that since the intelligent fault diagnostic instrument of the present invention is based on the above-mentioned fault analysis device, the embodiments of the intelligent fault diagnostic instrument of the present invention include all the technical solutions of all the embodiments of the above-mentioned fault analysis device, and the technical effects achieved are exactly the same, so they will not be repeated here.

[0185] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. A model compatibility method applied to an intelligent fault diagnostic instrument, wherein the intelligent fault diagnostic instrument is provided with a connection interface for connecting to a computing board under test, characterized in that, The model compatibility method includes: Obtain the target model parameters of the computing board to be tested; Configure the first detection firmware corresponding to the target model parameters; In response to a power-on test operation on the computing board under test, the first detection firmware is run to determine the connection status with the computing board under test; If the connection status fails, reconfigure the first detection firmware and perform a power-on test until the connection status is successful. The first detection firmware configured to correspond to the target model parameters includes: In response to the input of the target model parameters for the computing board under test, the firmware configuration rules and configuration parameters of the target model parameters are determined; The first detection firmware is generated according to the firmware configuration rules and the configuration parameters. The step of generating the first detection firmware according to the firmware configuration rules and the configuration parameters includes: The communication protocol type is determined based on the communication line pin arrangement of the target model parameters; Determine the control instruction code corresponding to the configuration parameters; The corresponding communication data format is determined based on the communication protocol type and the control command code; Configure the control instruction code according to the firmware configuration rules and communication data format to generate the corresponding first detection firmware.

2. The model compatibility method as described in claim 1, characterized in that, The step of generating the first detection firmware according to the firmware configuration rules and the configuration parameters includes: Determine the communication protocol matching strategy, communication line sequence, and instruction mapping relationship in the firmware configuration rules; In response to the control command code entered by the user according to the communication protocol matching strategy, the communication line sequence and the instruction mapping relationship, the syntax structure and protocol compatibility of the control command code are parsed to generate the first detection firmware.

3. The model compatibility method as described in claim 1, characterized in that, The first detection firmware configured to correspond to the target model parameters includes: Establish network communication links with external or internal databases; Obtain the preset firmware configuration template matching the target model parameters, the communication line pin arrangement of the target model parameters, and the corresponding control instruction code stored in the external database or the internal database; The communication protocol type is determined based on the pin arrangement of the communication lines; The corresponding communication data format is determined based on the communication protocol type and the control command code; The control instruction code is placed into the firmware configuration template according to the communication data format to generate the first detection firmware.

4. The model compatibility method as described in claim 1, characterized in that, The step of responding to a power-on test operation on the computing board under test, running the first detection firmware, and determining the connection status with the computing board under test includes: In response to a power-on test operation on the computing board under test, the first detection firmware is run and the first detection data is sent through the connection interface; The connection status signal returned by the connection interface is monitored, and the connection status is determined by parsing the connection status signal through the first detection firmware.

5. The model compatibility method as described in claim 4, characterized in that, The target model parameters include the communication wiring sequence and the data format corresponding to the communication wiring sequence; The process of monitoring the connection status signal returned by the connection interface and parsing the connection status signal through the first detection firmware to determine the connection status includes: The voltage level change status of the connection interface is acquired at preset intervals; If the level change state has a level jump and conforms to the characteristics of a preset communication protocol, it is determined that the connection interface returns a connection status signal; The first detection firmware parses the connection status signal according to the data format and extracts the model identifier and communication response timing. Based on the model identifier and the communication response timing, it is determined that the target model parameters match the actual hardware configuration of the computing board under test, and the connection status is determined to be a valid communication establishment.

6. The model compatibility method as described in claim 1, characterized in that, The process of obtaining the target model parameters of the computing board under test includes: Determine the communication wiring sequence between the computing board under test and the connection interface; The corresponding data format is determined based on the communication line sequence; Obtain the datasheet corresponding to the computing board under test, and determine the corresponding control instruction code in the datasheet; The control command code, the communication wiring sequence, and the data format are combined into the target model parameters.

7. A fault analysis device, characterized in that, The fault analysis device includes: a memory, a processor, and a model compatibility program stored in the memory and executable on the processor, the model compatibility program being configured to implement the model compatibility method as described in any one of claims 1 to 6.

8. An intelligent fault diagnosis instrument, characterized in that, include: The display device is used for visual interaction of power-on test operations or to present the connection status of the computing board under test. A connection interface is provided for connecting to the computing board under test. The connection interface has multiple channel pins for transmitting different communication line sequences. as well as The fault analysis device as described in claim 7 is electrically connected to both the connection interface and the display device. The fault analysis device is used to obtain the target model parameters of the computing board under test through the connection interface, configure the first detection firmware corresponding to the target model parameters, and in response to the power-on test operation of the display device for the computing board under test, run the first detection firmware, determine the connection status with the computing board under test, and determine whether the connection status is normal. If the connection status is failed, generate the corresponding fault prompt and control the display device to display it, reconfigure the first detection firmware, and perform the power-on test operation until the connection status is successful.

Images