Method for upgrading a fault diagnostic device, control device and fault diagnostic device

Abstract

The application provides an upgrading method of a fault diagnosis device, a control device and the fault diagnosis device, relates to the technical field of remote upgrading, and the fault diagnosis device is provided with a first storage area and a second storage area. The upgrading method of the fault diagnosis device comprises the following steps: setting the first storage area as a current firmware storage area and setting the second storage area as a backup firmware storage area; acquiring current firmware data and target firmware data which is different from the current firmware data in a remote management background; backing up the current firmware data from the first storage area to the second storage area; after the backup is completed, downloading the target firmware data, and updating the current firmware data in the first storage area into the target firmware data. The application can effectively improve the reliability of firmware upgrading of the fault diagnosis device, avoid the failure of the fault diagnosis device caused by upgrading abnormity, and reduce operation and maintenance costs.

Description

Technical Field

[0001] This application relates to the field of remote upgrade technology, and in particular to an upgrade method, control device and fault diagnosis equipment for a fault diagnosis device. Background Technology

[0002] Blockchain server systems encompass various types, including large-scale computing servers, distributed storage servers, and cryptocurrency servers. During continuous high-load operation, these servers frequently experience various operational failures due to factors such as environmental temperature fluctuations, humidity changes, and natural hardware aging. After a failure occurs, maintenance personnel typically rely on specialized diagnostic tools for detection and repair. However, traditional diagnostic tools only support single-brand or specific model devices, severely limiting their versatility in multi-brand mixed deployment environments and making it impossible to achieve unified diagnostics for server components from different manufacturers. To address this issue, a fault diagnosis device compatible with multiple brands and models has been developed. This device can adapt to diverse tested devices such as complete machines, power modules, and computing boards, enabling a standardized diagnostic process.

[0003] However, as manufacturers of the devices under test (DUTs) continuously optimize their product firmware and update communication protocols, diagnostic equipment must undergo simultaneous software upgrades to ensure that the diagnostic logic remains consistent with the latest version of the DUT. During the upgrade process, especially in areas with unstable power supply (such as the high temperature and humidity of tropical countries where it is difficult to configure backup batteries for diagnostic equipment) and in scenarios with poor network conditions, remote firmware update operations are highly susceptible to unexpected interruptions such as communication link outages, abnormal power supply fluctuations, or storage media write failures. Such interruptions cause the upgrade process to terminate abruptly, leaving the diagnostic equipment's firmware in an incomplete or corrupted state. This can lead to serious problems such as the device failing to boot, diagnostic functions malfunctioning, and even requiring return to the factory for repair, resulting in service interruptions and increased maintenance costs. Summary of the Invention

[0004] The main objective of this invention is to provide an upgrade method for fault diagnosis equipment, which aims to avoid firmware damage caused by abnormal interruption during the upgrade process, improve upgrade reliability, and adapt to upgrade requirements under harsh power supply and network environments.

[0005] To achieve the above objectives, the present invention provides an upgrade method for a fault diagnosis device, wherein the fault diagnosis device has a first storage area and a second storage area, and the upgrade method for the fault diagnosis device includes: Set the first storage area as the current firmware storage area, and set the second storage area as the backup firmware storage area; Obtain the current firmware data and the target firmware data in the remote management backend that differs from the current firmware data; Back up the current firmware data from the first storage area to the second storage area; After the backup is complete, the target firmware data is downloaded, and the current firmware data in the first storage area is updated to the target firmware data.

[0006] Optionally, obtaining the current firmware data and the target firmware data in the remote management backend that differs from the current firmware data includes: Obtain the firmware identifier from the current firmware data to determine the model and firmware version number of the device under test currently connected to the fault diagnosis device. Send the device under test model and the device under test firmware version number to the remote management backend; The remote management backend receives a difference data block determined by version matching based on the device under test model and the firmware version number of the device under test. The difference data block contains only code segments and configuration parameters that are different from the current firmware data. If the difference data block is empty, the current firmware data is determined to be the latest version; If the difference data block is not empty, it is determined that the target firmware data exists.

[0007] Optionally, downloading the target firmware data and updating the current firmware data in the first storage area to the target firmware data includes: After the backup is complete, a download request is automatically sent to the remote management backend, and the target firmware data returned by the remote management backend is received. During the download process, the target firmware data is divided into multiple sequentially arranged target data blocks according to a preset data length; The target data blocks are written sequentially into the free area of ​​the first storage area, and after each target data block is written, the sequence number of the target data block and its corresponding storage address are recorded. If a communication interruption or power interruption is detected during the download or writing process, the download is paused and the sequence number and storage address of the target data block that was written at the time of the interruption are recorded. After communication or power is restored, starting from the next target data block with the sequence number of the target data block already written, the system continues to request the target firmware data that has not been downloaded from the remote management backend, and continues to write to the first storage area based on the recorded storage address, until all target data blocks are written.

[0008] Optionally, downloading the target firmware data and updating the current firmware data in the first storage area to the target firmware data includes: In response to a firmware upgrade instruction request, a download request is sent to the remote management backend, and the target firmware data is received from the remote management backend; During the process of receiving the target firmware data, the power supply voltage and network signal strength of the fault diagnosis device are monitored in real time. If the power supply voltage is detected to be lower than a preset voltage threshold, or the network signal strength is lower than a preset signal strength threshold, the first storage area is controlled to pause receiving target firmware data, and the data length of the target firmware data to be downloaded is determined, and a corresponding data identifier of the received portion of the target firmware data is generated. After the power supply voltage recovers to above the voltage threshold and the network signal strength recovers to above the signal strength threshold, a resume request is sent to the remote management backend. The resume request includes a data identifier of the partially received target firmware data, in order to receive the remaining target firmware data. The partial target firmware data is concatenated with the remaining target firmware data to form complete target firmware data, thereby replacing the current firmware data in the first storage area.

[0009] Optionally, backing up the current firmware data from the first storage area to the second storage area includes: Detect the storage status of multiple storage cells in the second storage area; When determining the writable storage unit among the multiple storage units based on the storage situation, the address of the writable storage unit is written to the mapped address in the address mapping table, and the address of the first storage area storing the current firmware data is written to the mapped address in the address mapping table, so that when performing a backup operation, data copying is performed based on the writable storage unit and the address mapping table.

[0010] Optionally, the fault diagnosis device further includes a third storage area for downloading and storing the target firmware data; The upgrade method for the fault diagnosis equipment also includes: If the target firmware data is found to exist, download the target firmware data to the third storage area; After the current firmware data is backed up from the first storage area to the second storage area, the running status of the first storage area is obtained; When the operating state is idle, the target firmware data in the third storage area is written to the first storage area.

[0011] Optionally, when the operating state is idle, writing the target firmware data from the third storage area to the first storage area includes: Query the task scheduling queue of the first storage area to determine that the first storage area is in a stable idle state with no task execution and no interruption response; In the stable idle state, the target firmware data in the third storage area is copied to the first storage area in a block write manner; If a power outage is detected during the writing process, the data writing from the third storage area to the first storage area is paused, and the write breakpoint location is determined. After power is restored, the remaining data of the target firmware data is written to the first storage area according to the breakpoint location; If an error occurs in the address mapped to the first storage area during the writing process, obtain a backup location in the first storage area; Write the remaining data to the backup location and update the mapping relationship of the corresponding entry in the address mapping table.

[0012] Optionally, setting the first storage area as the current firmware storage area and setting the second storage area as the backup firmware storage area includes: Obtain the stored configuration information of the fault diagnosis device at startup; Based on the storage configuration information, the starting address of the first storage area is mapped to the firmware running entry point, and the starting address of the second storage area is mapped to the firmware backup entry point; Establish a mapping table between the first storage area and the second storage area. The mapping table records the mapping relationship between the address of each storage block in the first storage area and the address of the corresponding backup storage block in the second storage area.

[0013] Furthermore, to achieve the above objectives, the present invention also provides a control device, the control device comprising: a memory, a processor, and an upgrade program for a fault diagnosis device stored in the memory and executable on the processor, the upgrade program for the fault diagnosis device being configured to implement the upgrade method for the fault diagnosis device as described above.

[0014] In addition, to achieve the above objectives, the present invention also provides a fault diagnosis device, including the control device described above.

[0015] The fault diagnosis device of this invention has a first storage area and a second storage area. Its upgrade method involves setting the first storage area as the current firmware storage area and the second storage area as the backup firmware storage area. It then acquires the current firmware data and target firmware data (which differs from the current firmware data) from the remote management backend. The current firmware data is backed up from the first storage area to the second storage area. Finally, after the backup is complete, the target firmware data is downloaded, and the current firmware data in the first storage area is updated to the target firmware data. Thus, by forcibly backing up the current firmware to the backup storage area before performing the upgrade operation, the device can be restored to operation using the backed-up firmware if an anomaly occurs during the upgrade process. This solves the technical problem in the prior art where upgrade anomalies lead to firmware corruption and device boot failure. It effectively improves the reliability of firmware upgrades for fault diagnosis devices, avoids device failure caused by upgrade anomalies, and reduces maintenance costs. Attached Figure Description

[0016] 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.

[0017] Figure 1 This is a schematic diagram of an upgrade method for a fault diagnosis device according to an embodiment of the present invention; Figure 2 This is a schematic diagram of an upgrade method for a fault diagnosis device according to another embodiment of the present invention; Figure 3 This is a schematic diagram of an upgrade method for a fault diagnosis device according to another embodiment of the present invention; Figure 4 This is a schematic diagram of the upgrade method for a fault diagnosis device according to another embodiment of the present invention; Figure 5 This is a schematic diagram of an upgrade method for a fault diagnosis device according to another embodiment of the present invention; Figure 6 This is a schematic diagram of an upgrade method for a fault diagnosis device according to another embodiment of the present invention; Figure 7 This is a schematic diagram of an upgrade method for a fault diagnosis device according to another embodiment of the present invention; Figure 8 This is a schematic diagram of the upgrade method for a fault diagnosis device according to another embodiment of the present invention.

[0018] 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

[0019] 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.

[0020] Blockchain server systems encompass various equipment types, including large-scale computing servers, distributed storage servers, and cryptocurrency servers. During continuous high-load operation, these servers frequently experience various operational failures due to factors such as environmental temperature fluctuations, humidity changes, and natural hardware aging. After a failure occurs, maintenance personnel typically rely on specialized diagnostic tools for detection and repair. However, traditional diagnostic tools only support single-brand or specific model devices, severely limiting their versatility in multi-brand mixed deployment environments and making it impossible to achieve unified diagnostics for server components from different manufacturers. To address this issue, a fault diagnosis device compatible with multiple brands and models has been developed. This device can adapt to diverse tested devices such as complete machines, power modules, and computing boards, enabling a standardized diagnostic process.

[0021] However, as manufacturers of the devices under test (DUTs) continuously optimize their product firmware and update communication protocols, diagnostic equipment must undergo simultaneous software upgrades to ensure that the diagnostic logic remains consistent with the latest version of the DUT. During the upgrade process, especially in areas with unstable power supply (such as the high temperature and humidity of tropical countries where it is difficult to configure backup batteries for diagnostic equipment) and in scenarios with poor network conditions, remote firmware update operations are highly susceptible to unexpected interruptions such as communication link outages, abnormal power supply fluctuations, or storage media write failures. Such interruptions cause the upgrade process to terminate abruptly, leaving the diagnostic equipment's firmware in an incomplete or corrupted state. This can lead to serious problems such as the device failing to boot, diagnostic functions malfunctioning, and even requiring return to the factory for repair, resulting in service interruptions and increased maintenance costs.

[0022] It's important to note that in the current blockchain server repair industry, firmware upgrades for fault diagnosis equipment are generally handled using official jigs. These jigs typically employ wired or card-based upgrade methods. While some companies that have developed their own jigs have attempted wireless upgrade solutions, they are still limited by the weak power and network infrastructure in many third-world countries or overseas regions, resulting in unstable wireless signals and frequent power outages, leading to an upgrade success rate of less than 40%. To address this issue, many repair companies often dispatch engineers with specialized jigs to manually upgrade on-site when wireless upgrades are not immediately possible. However, this method often results in delayed firmware updates, causing diagnostic logic to lag behind the new device firmware version, increasing false alarm rates, decreasing compatibility, and continuously declining diagnostic accuracy, ultimately affecting the delivery quality and timeliness of the entire repair production line. Another approach is to use built-in batteries for backup power to ensure upgrade completion. However, due to the miniaturized design of the devices and battery degradation issues in harsh environments such as high temperature and humidity, built-in battery solutions have an average lifespan of less than 6 months in tropical regions, leading to frequent battery replacements that exacerbate the maintenance burden and costs. In areas with weak network infrastructure, many attempts to improve connectivity by adding signal enhancement modules, satellite communication modules, or edge computing nodes to fault diagnosis equipment have been hampered by a sharp increase in power consumption and power supply pressure. Furthermore, these modules age rapidly in high-temperature and high-humidity environments, resulting in a failure rate exceeding 35% in actual deployments, thus becoming new points of failure. More importantly, these modules are costly, with a single unit costing 18% more than the price of the entire device, significantly increasing the already low-profit margins of repair services. Moreover, the problem of consistency recovery after firmware upgrade interruptions remains unresolved.

[0023] The main solution of this application embodiment is as follows: by setting the first storage area as the current firmware storage area and the second storage area as the backup firmware storage area, the current firmware data and the target firmware data that differs from the current firmware data in the remote management background are obtained, and the current firmware data is backed up from the first storage area to the second storage area. Finally, after the backup is completed, the target firmware data is downloaded, and the current firmware data in the first storage area is updated to the target firmware data.

[0024] In this embodiment, for ease of description, the following description will focus on the control device as the executing entity.

[0025] This application provides a solution that pre-backs up the current firmware to a backup storage area before performing the upgrade operation. If an abnormality occurs during the upgrade process, the device can be restored to operation using the backed-up firmware. This solves the technical problem in the prior art where an abnormal upgrade leads to firmware corruption and the device failing to boot. It can effectively improve the reliability of firmware upgrades for fault diagnosis devices, avoid fault diagnosis device failures caused by abnormal upgrades, and reduce operation and maintenance costs.

[0026] Therefore, the present invention proposes an upgrade method for fault diagnosis equipment; it is understood that the fault diagnosis equipment is equipped with a control device for storing and executing the following method. The control device can be implemented using a main controller, such as MCU (Micro Controller Unit), DSP (Digital Signal Processor), FPGA (Field Programmable Gate Array), SOC (System On Chip), etc.

[0027] Traditional fault diagnosis equipment has limited versatility when dealing with devices from multiple brands and models. Furthermore, in practical applications, due to continuous firmware optimization and communication protocol upgrades of the devices under test, fault diagnosis equipment requires corresponding firmware updates to maintain compatibility. However, in areas with unstable power and network environments, unexpected interruptions such as communication outages, power supply anomalies, or memory write failures frequently occur during remote upgrades. These events may cause abnormal termination of the upgrade, leading to device malfunctions or firmware corruption, severely impacting the reliability and security of the upgrade process.

[0028] Therefore, referring to Figure 1 In one embodiment of the present invention, the fault diagnosis device is provided with a first storage area and a second storage area, and the upgrade method of the fault diagnosis device includes steps S100-S400, wherein: S100: Set the first storage area as the current firmware storage area and set the second storage area as the backup firmware storage area; S200: Obtain current firmware data and target firmware data in the remote management backend that differs from current firmware data; S300: Back up the current firmware data from the first storage area to the second storage area; S400: After backup is complete, download the target firmware data and update the current firmware data in the first storage area to the target firmware data.

[0029] Fault diagnosis equipment refers to specialized devices used to detect, locate, and analyze hardware or software faults in various types of servers (such as blockchain servers, large-scale computing power servers, distributed storage servers, cryptocurrency servers, etc.). This fault diagnosis equipment typically has the ability to communicate and interact with various brands and models of the devices under test to achieve standardized diagnosis. The first and second storage areas refer to the physical or logical storage spaces within the fault diagnosis equipment used to store firmware programs and related data. These storage areas can be flash memory, EEPROM, or other non-volatile storage media.

[0030] The current firmware storage area is designated for storing the firmware program currently running on the diagnostic device. During normal operation, the device's processor reads and executes firmware instructions from this area. The backup firmware storage area is designated for storing a copy of the current firmware program. Its main function is to provide a recoverable firmware version in case the data in the current firmware storage area is corrupted or an upgrade fails, ensuring the device's normal startup and operation. Current firmware data refers to the collection of software programs and configuration parameters currently used by the diagnostic device to control its various functions and logic. The remote management backend is a management system located on a remote server, responsible for storing and managing the latest firmware version, historical firmware versions, and firmware update policies of the diagnostic device. This backend system can communicate with the diagnostic device to provide firmware update services, version matching, and data transfer. Target firmware data refers to the latest or specified version of firmware stored in the remote management backend that differs from the current firmware data of the diagnostic device. This target firmware data typically includes optimizations, feature enhancements, bug fixes, or adaptations to new protocols for existing firmware.

[0031] This embodiment configures the internal storage area of ​​the fault diagnosis device. The internal storage space of the fault diagnosis device is divided into at least two independent storage areas: a first storage area and a second storage area. The first storage area is designated as the current firmware storage area, used to store the firmware program currently running on the device. The second storage area is designated as the backup firmware storage area, used to store a copy of the current firmware program for future use. For example, the storage area configuration can be completed by loading a preset configuration file when the fault diagnosis device starts up. This configuration file explicitly defines the functional roles corresponding to different physical address ranges in the memory.

[0032] After the storage area is set up, it is necessary to obtain the current firmware data and the target firmware data that differs from the current firmware data in the remote management backend. The fault diagnosis device can periodically or proactively connect to the remote management backend when triggered by specific events (such as device power-on or user manual activation). The fault diagnosis device sends its current firmware version information to the remote management backend, which compares this information with the latest firmware version it maintains. If an updated version is found, it is identified as the target firmware data. For example, the fault diagnosis device can send a simple version query request to the backend. After comparison, if a new version is found, the backend directly marks the complete latest firmware package as the target firmware data, awaiting device download.

[0033] After acquiring the target firmware data, to ensure the security of the upgrade process, the current firmware data needs to be backed up from the first storage area to the second storage area. This backup operation aims to create a rollbackable firmware copy. Specifically, the control device initiates a data copying process, copying all current firmware data stored in the first storage area byte-by-byte or block-by-block to the second storage area. For example, a simple memory copy instruction can be used to completely copy the data from the first storage area to a reserved storage space in the second storage area. Furthermore, in this embodiment, regardless of whether there is already backed-up data in the second storage area, a forced backup is performed during the upgrade to ensure data accuracy and integrity.

[0034] After a successful backup operation, the fault diagnosis device will begin downloading the target firmware data and updating the current firmware data in the first storage area to that target firmware data. Specifically, the fault diagnosis device will send a download request to the remote management backend and receive the target firmware data transmitted from the backend. Once the target firmware data has been completely downloaded to the device's internal temporary storage area, the control unit will initiate the firmware update program. This program will write the downloaded target firmware data completely to the first storage area, overwriting the existing current firmware data. For example, after the download is complete, the fault diagnosis device can write the entire target firmware file to the first storage area at once, completing the firmware replacement.

[0035] The fault diagnosis device upgrade method in this embodiment effectively addresses the risk of upgrade interruption in environments with unstable power or network by forcibly backing up the current firmware data to an independent backup storage area before the upgrade. Even if an anomaly occurs during the download or writing of new firmware, the fault diagnosis device can avoid functional abnormalities or firmware corruption by restoring the backup firmware, significantly improving the reliability and security of firmware upgrades for the fault diagnosis device and ensuring stable operation and continuous adaptability of the fault diagnosis device in complex environments.

[0036] The fault diagnosis device in this embodiment has a first storage area and a second storage area. Its upgrade method involves setting the first storage area as the current firmware storage area and the second storage area as the backup firmware storage area. It then acquires the current firmware data and target firmware data (which differs from the current firmware data) from the remote management backend. The current firmware data is backed up from the first storage area to the second storage area. Finally, after the backup is complete, the target firmware data is downloaded, and the current firmware data in the first storage area is updated to the target firmware data. Thus, by forcibly backing up the current firmware to the backup storage area before performing the upgrade operation, the device can be restored to operation using the backed-up firmware if an anomaly occurs during the upgrade process. This solves the technical problem in the prior art where upgrade anomalies lead to firmware corruption and device boot failure. It effectively improves the reliability of firmware upgrades for fault diagnosis devices, avoids upgrade anomalies causing device failure, and reduces maintenance costs.

[0037] When upgrading firmware on a fault diagnosis device, simply acquiring the current firmware data and comparing it with data in the remote management backend may result in the inability to accurately identify the latest firmware version applicable to the current device and its connected devices under test. Especially when the fault diagnosis device needs to be compatible with multiple models of devices under test, blindly downloading or comparing the full firmware data is not only inefficient but may also lead to downloading incorrect firmware, thereby affecting the normal operation of the device and the accuracy of the diagnosis.

[0038] Therefore, referring to Figure 2 Another embodiment of the present invention provides an upgrade method for a fault diagnosis device, based on the above. Figure 1 The illustrated embodiment obtains current firmware data and target firmware data in the remote management backend that differs from the current firmware data, including steps S210-S250, wherein: S210. Obtain the firmware identifier of the current firmware data and determine the model and firmware version number of the device under test currently connected to the fault diagnosis device. S220. Send the device under test model and firmware version number to the remote management backend. S230: Receive the difference data block determined by the remote management backend after version matching based on the device under test model and firmware version number. The difference data block only contains code segments and configuration parameters that are different from the current firmware data. S240. If the difference data block is empty, determine that the current firmware data is the latest version; S250. If the difference data block is not empty, it is determined that the target firmware data exists.

[0039] When performing a firmware upgrade check, the fault diagnosis device first reads the unique identifier of its currently running firmware, such as the version number, checksum, or product serial number. Furthermore, to ensure upgrade compatibility and accuracy, the fault diagnosis device also actively queries and obtains the specific model information and current firmware version number of the connected device under test (DUT) by communicating with it, for example, through diagnostic interfaces (such as OBD-II, CAN, LIN, etc.) or dedicated communication protocols. It's crucial to first identify the DUT to avoid errors occurring with products from different brands and models; for example, a power supply from Company A and a computing board from Company B would have different firmware updates. Subsequently, the fault diagnosis device, through its built-in network communication module, encapsulates the obtained DUT model and firmware version number into a request data packet and sends it to the remote management backend via the communication channel. This aims to provide sufficient information to the backend for accurate firmware version matching. Upon receiving the DUT model and firmware version number from the fault diagnosis device, the remote management backend performs a refined version matching based on this information and the latest firmware version stored in its firmware library. The matching process identifies code segments and configuration parameters that need updating compared to the current firmware data of the diagnostic device (and the firmware data of the device under test). The remote management backend then generates a difference data block containing only these differences, not the complete firmware package. The diagnostic device receives this difference data block, laying the foundation for subsequent incremental updates. Upon receiving the difference data block from the remote management backend, the diagnostic device examines its contents. If the difference data block is empty (e.g., zero data size or containing a specific empty identifier), it indicates that the remote management backend has not found any code segments or configuration parameters that need updating, meaning that the firmware currently running on both the diagnostic device and its connected device under test is already the latest version. In this case, the device will stop the upgrade process to avoid unnecessary resource consumption. Conversely, if the diagnostic device detects that the received difference data block contains actual data content (i.e., it is not empty), it explicitly indicates the existence of available target firmware data. This means that the diagnostic device needs to perform a firmware update and can initiate subsequent download and write operations to apply the updates in these difference data blocks.

[0040] Through the above technical solution, the fault diagnosis device can obtain its own firmware identifier, as well as the model and firmware version number of the currently connected device under test (DUT), and send them to the remote management backend for precise matching. This ensures that the acquired target firmware data is the latest and compatible version for the specific device and the DUT. The remote management backend only returns difference data blocks containing the differing code segments and configuration parameters, rather than the complete firmware package. This significantly reduces data transmission volume, shortens upgrade time, and reduces network bandwidth usage. When the difference data block is empty, the fault diagnosis device can intelligently determine that the current firmware is already up-to-date, avoiding unnecessary downloads and upgrade operations. This improves the efficiency and accuracy of upgrades, effectively solving the problems of version mismatch, downloading redundant data, or upgrade errors that may occur in traditional upgrade methods.

[0041] In real-world applications, download or write operations are prone to interruption due to the instability of communication links or the unpredictability of device power supply. Failure to properly handle such interruptions may result in incomplete firmware data downloads or write failures, leading to firmware corruption or even preventing the device from booting up normally, severely impacting the reliability and availability of fault diagnosis equipment.

[0042] Therefore, referring to Figure 3 Another embodiment of the present invention provides an upgrade method for a fault diagnosis device, based on the above. Figure 1 The illustrated embodiment downloads the target firmware data and updates the current firmware data in the first storage area to the target firmware data, including steps S4010-S4050, wherein: S4010: After backup is complete, it automatically sends a download request to the remote management backend and receives the target firmware data returned by the remote management backend. S4020. During the download process, the target firmware data is divided into multiple target data blocks arranged in sequence according to the preset data length. S4030. Write multiple target data blocks sequentially into the free area of ​​the first storage area, and after each target data block is written, record the sequence number of the target data block that has been written and its corresponding storage address. S4040. If a communication interruption or power interruption is detected during the download or writing process, the download is paused and the sequence number and storage address of the target data block that has been written at the time of the interruption are recorded. S4050: After communication or power is restored, starting from the next target data block with the sequence number of the target data block that has been written, continue to request the target firmware data that has not been downloaded from the remote management backend, and continue to write to the first storage area based on the recorded storage address, until all target data blocks are written.

[0043] In this embodiment, after the current firmware data has been securely backed up to the second storage area, the fault diagnosis device can automatically initiate the download process of the target firmware data without manual intervention. This is typically achieved by the device's internal firmware upgrade management module or operating system initiating a download request to a preset remote management backend after detecting a backup completion signal. Upon receiving the request, the remote management backend verifies the validity of the request based on information such as the device's identity, model, and current firmware version, and returns the corresponding target firmware data stream. This automated download method is particularly suitable for scenarios involving initial device use, power-on self-test, or firmware updates within a preset maintenance window, improving upgrade efficiency and user experience.

[0044] During the download process, the target firmware data is divided into multiple sequentially arranged target data blocks according to a preset data length. To improve data transmission reliability and management efficiency, the target firmware data is not transmitted as a whole during download, but is logically or physically divided into several data blocks of equal size or preset length. For example, the target firmware data can be divided into data blocks of 1KB, 4KB, 64KB, or larger. This block-based processing method allows data transmission to proceed block by block, facilitating verification, retransmission, and progress management during transmission. Each data block typically has a unique sequence number to ensure that it can be reassembled into complete firmware data in the correct order at the receiving end.

[0045] Subsequently, multiple target data blocks are written sequentially to the free area of ​​the first storage region. After each target data block is written, its sequence number and corresponding storage address are recorded. Received target data blocks are written sequentially to the first storage region of the fault diagnosis device. The first storage region is the running area of ​​the current firmware. During the update process, it is necessary to ensure that the write operation does not interfere with the running system, or that the new firmware can only be activated after a system reboot. The write operation is usually performed by the storage controller, writing data blocks to the reserved free area in the first storage region that is not occupied by the currently running firmware. To support breakpoint resumption and fault recovery, after each successful write of a target data block, the control device immediately records the sequence number of the data block and its starting storage address in the first storage region in a persistent storage medium (such as non-volatile memory). This recorded information is crucial for subsequent judgment of download and write progress.

[0046] If a communication or power interruption is detected during download or writing, the download is paused and the sequence number and storage address of the target data block already written at the time of the interruption are recorded. The fault diagnosis device continuously monitors its communication status (e.g., whether the network connection is normal, whether the packet loss rate is too high) and power supply status (e.g., whether the power supply voltage is stable, whether it is below the safety threshold). Once a communication link disconnection, network signal loss, or abnormal power supply to the device is detected (e.g., voltage drop, power input failure, etc.), the control device will immediately stop the currently ongoing download or write operation. In addition, the control device will accurately record the sequence number and corresponding storage address of the last target data block that has been successfully downloaded and written to the first storage area at the time of the interruption. This information is stored in reliable non-volatile memory to ensure that this progress information is not lost even if the device is completely powered off.

[0047] After communication or power is restored, the system continues to request undownloaded target firmware data from the remote management backend, starting from the next target data block with the next written target data block sequence number. It then continues writing to the first storage area based on the recorded storage addresses until all target data blocks are written. When the fault diagnosis device detects that the communication link has been re-established or power has been restored, it does not restart the entire download and write process from the beginning. Instead, the control device reads the previously recorded target data block sequence numbers and storage addresses from the time of the interruption. It then sends a resume request to the remote management backend, specifying which data block to start downloading from. Upon receiving the resume request, the remote management backend sends the remaining target firmware data starting from the specified data block. After receiving this data, the fault diagnosis device continues writing data blocks to the first storage area based on the previously recorded storage addresses, ensuring seamless data continuation until all target firmware data has been completely downloaded and written to the first storage area.

[0048] This embodiment is an automatic download, generally used when booting up or when opening the firmware for the first time. For example, when turning on the X model power supply of Company A for the first time to test, it will trigger the automatic firmware upgrade process. However, if the Y model computing board of Company B has already been upgraded once, it will not be upgraded automatically.

[0049] Through the above technical solution, the fault diagnosis equipment can automatically start the download and update of the target firmware after completing the current firmware backup. During the download and writing process, the target firmware data is divided into multiple data blocks and written block by block, while the sequence number and storage address of the written data blocks are recorded in real time. When a communication or power interruption occurs, the control device can promptly pause the operation and accurately record the interruption point. After communication or power is restored, the fault diagnosis equipment can intelligently resume the download and writing from the interruption point, avoiding repetitive work from the beginning. This significantly improves the robustness and efficiency of the firmware upgrade process, effectively avoids firmware damage or upgrade failure caused by unexpected interruptions, and ensures that the fault diagnosis equipment can reliably complete firmware updates even in complex and changing working environments, thereby guaranteeing the long-term stable operation of the equipment and data integrity.

[0050] In real-world applications, fault diagnosis equipment may face unstable power supply environments or weak network signals, which could lead to firmware data download interruptions or data transmission errors. An unexpected interruption in the download process can result in incomplete firmware data, affecting the normal operation of the device and even preventing it from booting, causing inconvenience to users and potential device damage.

[0051] Therefore, referring to Figure 4 Another embodiment of the present invention provides an upgrade method for a fault diagnosis device, based on the above. Figure 1 The illustrated embodiment downloads the target firmware data and updates the current firmware data in the first storage area to the target firmware data, including steps S4060-S4100, wherein: S4060, in response to a firmware upgrade instruction request, sends a download request to the remote management backend and receives the target firmware data returned by the remote management backend; S4070: During the process of receiving target firmware data, monitor the power supply voltage and network signal strength of the fault diagnosis device in real time. S4080 If the power supply voltage is detected to be lower than the preset voltage threshold, or the network signal strength is lower than the preset signal strength threshold, control the first storage area to suspend receiving target firmware data, determine the data length of the target firmware data to be downloaded, and generate the corresponding data identifier of the received part of the target firmware data. S4090: After the power supply voltage is restored to above the voltage threshold and the network signal strength is restored to above the signal strength threshold, a resume request is sent to the remote management backend. The resume request includes the data identifier of the partially received target firmware data in order to receive the remaining target firmware data. S4100: Combine part of the target firmware data with the remaining target firmware data to form complete target firmware data, so as to replace the current firmware data in the first storage area.

[0052] This embodiment and Figure 3 Unlike the automatic download in the illustrated embodiment, this implementation uses manual triggering. The fault diagnosis device only initiates a download request to the remote management backend after receiving a clear upgrade command from the user or system. This on-demand download method gives users greater control, allowing them to choose an appropriate time to download firmware based on the device's current status, usage scenario, or network conditions. This avoids forced downloads under unsuitable conditions, thereby improving the flexibility and security of the upgrade process. For example, users can issue upgrade commands through the device interface or a connected host computer when the device is idle, power supply is stable, and network is good. Manual download, achieving on-demand acquisition, is generally performed after power-on or after a period of firmware upgrade.

[0053] During the process of receiving target firmware data, the fault diagnosis device monitors its own power supply voltage and network signal strength in real time. Real-time monitoring of power supply voltage and network signal strength is a key measure to ensure the stability of firmware download. Fault diagnosis devices typically integrate voltage detection and network communication modules, enabling them to continuously acquire current power supply voltage and network signal strength values. Monitoring the power supply voltage prevents data write errors or unexpected device shutdowns caused by voltage fluctuations or insufficient voltage. Monitoring the network signal strength assesses the reliability of the data transmission link, avoiding data downloads under poor signal quality conditions, thereby reducing the risk of data packet loss or transmission interruption. This monitoring data serves as the basis for subsequent download control decisions.

[0054] If the power supply voltage is detected to be lower than a preset voltage threshold, or the network signal strength is detected to be lower than a preset signal strength threshold, the fault diagnosis device will control the first storage area to suspend receiving target firmware data, determine the length of the downloaded target firmware data, and generate a corresponding data identifier for the received portion of the target firmware data. When the detected power supply voltage or network signal strength is lower than a preset safety threshold, the control device will immediately take measures to suspend firmware data reception. Suspending reception is to avoid data corruption that may occur if downloading continues in an unstable environment. In addition, the control device will accurately record the length of the target firmware data that has been successfully downloaded and generate a unique data identifier. This data identifier can be a checksum, a file offset, a data block sequence number, or a timestamp, used to uniquely identify the received data portion, ensuring the robustness of the download process.

[0055] Once the power supply voltage and network signal strength recover to above the voltage threshold and signal strength threshold, the fault diagnosis device sends a resume request to the remote management backend. This request includes data identifiers of the partially received target firmware data to receive the remaining data. Once both the power supply voltage and network signal strength have returned to above the preset stable threshold, the fault diagnosis device proactively sends a resume request to the remote management backend. This request includes data identifiers of the previously generated and recorded partially received target firmware data. Upon receiving this request, the remote management backend identifies the starting position of the data to be resumed based on the data identifiers and begins sending the remaining target firmware data to the fault diagnosis device from that position. This mechanism effectively avoids re-downloading from the beginning, saving time and network bandwidth, and improving upgrade efficiency.

[0056] Finally, the fault diagnosis device concatenates a portion of the target firmware data with the remaining target firmware data to form a complete target firmware data set, replacing the current firmware data in the first storage area. After receiving all the remaining target firmware data, the fault diagnosis device seamlessly concatenates the previously received portion of the target firmware data with the remaining target firmware data received in this resumed download. The concatenation operation is typically performed in the device's memory to ensure data integrity and continuity. After concatenation, a complete and usable target firmware data package is formed. Subsequently, the control device writes this complete target firmware data to the first storage area, replacing the original current firmware data, thereby completing the firmware upgrade. This process ensures that even if the download is interrupted, a complete and correct firmware version will ultimately be obtained.

[0057] Through the above technical solution, the fault diagnosis device can monitor the power supply voltage and network signal strength in real time when receiving target firmware data. When unstable power supply or network environment is detected, the control device can promptly pause data reception and record the download progress, effectively avoiding data corruption or download failure caused by environmental fluctuations. Once the environment stabilizes, the fault diagnosis device can intelligently send a resume request to continue downloading the remaining data from the interruption point, avoiding repeated downloads and significantly improving the success rate and efficiency of firmware upgrades. This mechanism ensures that even in harsh or unstable working environments, the fault diagnosis device can reliably complete firmware upgrades, reducing the risk of device failure and improving user experience and device availability. Figure 1 Compared with the solutions shown in the embodiments, this solution greatly enhances the robustness and reliability of the firmware download process by introducing intelligent monitoring and breakpoint resume mechanisms, making it particularly suitable for scenarios where devices are upgraded in on-site or mobile environments.

[0058] During its implementation, if a storage unit in the second storage area is damaged, directly backing up the data may result in incomplete or unusable backup data, thereby affecting the recovery capability of the fault diagnosis equipment after an upgrade failure.

[0059] Therefore, referring to Figure 5 The present invention also provides an embodiment of an upgrade method for a fault diagnosis device, based on the above. Figure 1 The illustrated embodiment backs up the current firmware data from the first storage area to the second storage area, including steps S310-S320, wherein: S310. Detect the storage status of multiple storage units in the second storage area; S320. When determining the writable storage unit among multiple storage units based on the storage situation, the address of the writable storage unit is written to the mapped address in the address mapping table, and the address of the first storage area storing the current firmware data is written to the mapped address in the address mapping table, so that when performing backup operation, data copying is performed according to the writable storage unit and the address mapping table. The writable storage unit is the valid sector after bad block marking and removal.

[0060] This embodiment first detects the storage status of multiple storage units in the second storage area. The storage status refers to the health status and availability of each storage unit (e.g., sector, block, or page) in the second storage area. This can be detected by performing read / write tests on the storage units, checking the error correction code (ECC) status, or querying the bad block table and health report provided by the storage controller to identify any potential storage problems.

[0061] When determining writable storage cells from multiple storage units based on storage conditions, the control unit filters out those healthy cells that can reliably store data. Any storage cell identified as faulty, unstable, or having reached its erase / write lifespan threshold is marked as unusable, while the remaining healthy storage cells are identified as writable. Writable storage cells are the valid sectors after bad block marking and removal, ensuring the reliability of subsequent data writes.

[0062] Subsequently, the address of the writable storage unit is written to the mapped address in the address mapping table, and the address in the first storage area that stores the current firmware data is written to the mapped address in the address mapping table. The address mapping table is a data structure used to establish the correspondence between logical addresses and physical addresses. Here, the mapped address refers to the physical address in the second storage area actually used to store backup data, while the mapped address refers to the logical address of the original firmware data in the first storage area. In this way, a flexible and fault-tolerant mapping relationship is established for backup data, allowing the control device to utilize healthy physical locations for storage even if bad blocks exist in the second storage area.

[0063] Finally, during the backup operation, the control device will perform data copying based on the writable storage unit and the address mapping table. Specifically, for each segment of current firmware data in the first storage area, the system will query the address mapping table to obtain the physical address of the corresponding writable storage unit in the second storage area, and then copy the data precisely to that physical address.

[0064] Through the above technical solution, during firmware backup, the fault diagnosis device can pre-identify and avoid damaged storage units in the second storage area, ensuring that backup data is written to a reliable storage region. The introduction of an address mapping table further provides flexible address remapping capabilities, allowing the backup process to proceed smoothly even if bad blocks exist in the second storage area, guaranteeing the integrity and availability of the backup data. This significantly improves the reliability of the fault diagnosis device in recovering from firmware upgrade failures using backup data, avoiding the risk of device unrecoverability due to corrupted backup data, thereby enhancing the robustness of the entire upgrade process.

[0065] In some implementations of this application, after completing the backup of the current firmware data, the fault diagnosis device immediately downloads the target firmware data and updates the current firmware data in the first storage area. However, this immediate update strategy may affect the normal operation of the device or the user experience when the device is running heavily or when it requires a long time to download and write firmware, and it cannot achieve firmware pre-download and opportunistic updates.

[0066] Therefore, referring to Figure 6 Another embodiment of the present invention provides an upgrade method for a fault diagnosis device, based on the above. Figure 1 In the embodiment shown, the fault diagnosis device further includes a third storage area for downloading and storing target firmware data; The upgrade method for fault diagnosis equipment also includes steps S500-S700, wherein: S500: If the target firmware data is found to exist, (regardless of whether the current firmware data has been backed up to the second storage area) download the target firmware data to the third storage area. S600, and after the current firmware data is backed up from the first storage area to the second storage area, obtains the running status of the first storage area; When the S700 is in an idle state, the target firmware data in the third storage area is written to the first storage area.

[0067] The third storage area is an independent storage medium, either internal or external to the fault diagnosis device. Its main function is to serve as a temporary download and storage area for target firmware data. This third storage area can be a separate flash memory chip, an SD card, or a logical partition within the device's main memory. Its capacity should be sufficient to hold one or more complete target firmware data packages. By downloading the target firmware data to this area, firmware pre-downloading can be achieved without immediate firmware update operations, thus decoupling the download process from the actual firmware writing process.

[0068] If the target firmware data is found to exist, it is downloaded to the third storage area. When the fault diagnosis device interacts with the remote management backend and determines that target firmware data different from the current firmware data exists, the system initiates the download process for the target firmware data, regardless of whether the device is idle or whether the current firmware data has been backed up. The download process can be performed via protocols such as HTTP, FTP, and OTA, and the received data is directly written to the third storage area. This process can be independent of the normal operation of the device, for example, it can be performed silently in the background, or it can be automatically triggered when the network connection is stable.

[0069] After the current firmware data is successfully backed up to the second storage area, the control device queries the operating status of the first storage area (the current firmware storage area). This can be achieved through operating system or firmware-level API interfaces, such as checking CPU load, memory usage, I / O operation queue, task scheduler status, etc. The obtained operating status can be a comprehensive indicator reflecting whether the first storage area is currently executing critical tasks, whether there are high-priority interrupt responses, or whether it is in a relatively idle and stable state.

[0070] When the device is idle, the target firmware data in the third storage area is written to the first storage area. When the control device determines that the first storage area is idle, it considers that performing the firmware write operation at this time will have minimal impact on the normal functioning of the device. At this point, the control device will initiate the data writing process from the third storage area to the first storage area. The write operation can use block write, sector write, or other methods to completely copy the target firmware data, which has been pre-downloaded and stored in the third storage area, to the first storage area, thereby completing the firmware update. This method avoids the risk of control device instability or data corruption that may result from forced updates when the fault diagnosis device is busy.

[0071] In this embodiment, the update data is downloaded upon acquisition, but the update is not necessarily required immediately after downloading; instead, it is done manually. This method of downloading first and then writing when the device is idle is quite common in mobile phone system applications, and it often requires the user to actively trigger confirmation before execution. However, in special equipment such as fault diagnosis equipment (used in harsh environments such as high temperature and high humidity), if it waits for manual confirmation from the user like a mobile phone, it may lead to firmware version lag due to limited storage resources and long-term lack of updates, thus failing to perform normal fault diagnosis functions. Why can't existing technicians directly migrate this method from mobile phones? On the one hand, the fault diagnosis equipment in this embodiment is used in specific industrial environments with high temperature and humidity, and the communication protocols with various server and component manufacturers are highly customized. Firmware updates need to strictly match hardware timing and environmental tolerance thresholds. Mobile phone system updates rely on user interaction, and the mobile phone's operating environment is relatively stable, with continuous power supply and controllable network conditions. On the other hand, the fault diagnosis equipment needs to be updated in a timely manner to correctly identify new fault characteristics and update and iterate the data of some known faults to ensure data stability and test accuracy. Even if the mobile phone is not updated, it can still run its basic functions normally. However, once the firmware of the fault diagnosis equipment lags behind, its diagnostic accuracy and response speed may drop precipitously. Therefore, it is difficult to directly copy this update method of the mobile phone.

[0072] By introducing a third storage area through the above technical solution for pre-downloading and storing target firmware data, the download process is decoupled from the actual firmware update process. Upon obtaining the target firmware data, it can be immediately downloaded to the third storage area without waiting for backup completion or device idleness, thus effectively utilizing network resources and time, and improving the efficiency and flexibility of firmware download. Subsequently, after the current firmware data is backed up from the first storage area to the second storage area, the control device intelligently obtains the operating status of the first storage area. Only when the first storage area is detected to be idle will the target firmware data downloaded in the third storage area be written to the first storage area. This mechanism avoids firmware writing operations when the device is busy or performing critical tasks, significantly reducing the interference of firmware updates on the normal operation of the device, and improving system stability and user experience. Furthermore, this "online download, opportunistic update" strategy enables fault diagnosis equipment to complete firmware upgrades more smoothly and safely, ensuring the reliability of the device during the upgrade process.

[0073] During actual firmware writing, sudden power outages may occur, interrupting data writing and potentially causing firmware corruption or system boot failure. Furthermore, after prolonged use, the first storage area may experience address mapping anomalies in its storage units. If not properly addressed, this will severely impact the reliability of firmware updates and the normal operation of the device.

[0074] Therefore, referring to Figure 7 Another embodiment of the present invention provides an upgrade method for a fault diagnosis device, based on the above. Figure 6 In the illustrated embodiment, when the operating state is idle, the target firmware data in the third storage area is written to the first storage area, including steps S710-S760, wherein: S710. Query the task scheduling queue of the first storage area to determine that the first storage area is in a stable idle state with no task execution and no interrupt response; S720: In a stable idle state, copy the target firmware data in the third storage area to the first storage area in a block write manner; S730: If a power failure is detected during the writing process, pause the data writing from the third storage area to the first storage area and determine the write breakpoint location. S740: After power is restored, write the remaining data of the target firmware data to the first storage area according to the breakpoint location; S750: If an abnormality occurs in the address mapped to the first storage area during the writing process, obtain the backup location in the first storage area; S760. Write the remaining data to the spare location and update the mapping relationship of the corresponding entry in the address mapping table.

[0075] Before writing the target firmware data from the third storage area to the first storage area, the fault diagnosis device first queries the task scheduling queue of the first storage area. This task scheduling queue records all pending and currently executing tasks, as well as pending interrupt requests. By querying this queue, it can be determined whether any user applications, system services, or hardware interrupts are currently occupying CPU or storage resources. When the queue is empty and there are no pending interrupt requests, it can be determined that the first storage area is in a stable idle state with no tasks executing and no interrupt responses. This state ensures that the firmware writing operation is performed in the most stable system environment, avoiding write conflicts caused by resource contention or interrupt handling, thereby guaranteeing the atomicity and data consistency of the writing process.

[0076] After confirming that the first storage area is in a stable, idle state, the fault diagnosis device will initiate the target firmware data writing process. The target firmware data is typically divided into fixed-size data blocks, such as 512 bytes, 4KB, or 64KB. The control unit reads a data block from the third storage area and writes it to the corresponding location in the first storage area, repeating this process until all data blocks have been written. This block-based writing method effectively utilizes the underlying characteristics of the storage device, such as the erase block and page write mechanisms of flash memory, thereby optimizing write performance and extending the lifespan of the storage device.

[0077] To address potential unforeseen circumstances during firmware writing, this embodiment also incorporates power-off protection and abnormal address handling mechanisms. If a power outage is detected during the writing process, the fault diagnosis device immediately suspends the data writing operation from the third storage area to the first storage area. This is typically achieved by real-time monitoring of the supply voltage via a power management unit (PMU) or voltage monitoring circuit. When the supply voltage falls below a preset safety threshold, the control device triggers an interrupt and quickly records the current writing progress, thus determining the write breakpoint location. This breakpoint location information, such as the sequence number of the currently being written data block, the number of bytes already written, or the starting address of the next data block to be written, is stored in non-volatile memory. After power is restored, the fault diagnosis device first checks if the breakpoint location information exists in the non-volatile memory. If it does, it reads the information and, based on the breakpoint location, continues writing the remaining data to the first storage area, starting from the target firmware data block corresponding to that breakpoint location in the third storage area.

[0078] Furthermore, if an anomaly occurs at the address mapped to the first storage area during the write process—for example, if the underlying storage controller reports a write failure, a verification error, or an inaccessible address—it indicates that the storage unit currently being written to may have a physical defect or logical error. In this case, the fault diagnosis device triggers an anomaly handling mechanism, obtaining an available backup location from the reserved backup storage area in the first storage area. Once a backup location is obtained, the system writes the remaining data originally planned for the anomaly address to this new backup location. Simultaneously, to ensure the firmware can correctly access this data during runtime, the system updates an internal address mapping table. This address mapping table records the correspondence between logical addresses and physical addresses. When the physical address corresponding to a logical address becomes abnormal and is replaced by a backup location, the corresponding entry in this table is modified, mapping the original logical address to the new backup physical address.

[0079] Through the above technical solution, when the fault diagnosis device performs firmware updates, this application can first ensure that the first storage area is in a stable, idle state with no task execution and no interruption response by querying the task scheduling queue. This provides a safe and reliable environment for writing firmware blocks and avoids data writing errors caused by resource conflicts. When a sudden power outage occurs during the writing process, the system can promptly pause the writing and record the breakpoint position. After power is restored, the writing can be resumed based on the breakpoint position, greatly improving the success rate and efficiency of firmware updates and avoiding the waste of resources from repeated downloads and writing from scratch. In addition, in response to possible address mapping anomalies in the first storage area, this application can intelligently obtain backup locations for data writing and ensure the integrity and accessibility of the firmware by updating the address mapping table. This effectively addresses potential defects in the storage medium, thereby significantly improving the robustness and reliability of firmware updates for the fault diagnosis device and ensuring the long-term stable operation of the device.

[0080] Without a fine-grained management and address mapping mechanism for these storage areas, the system may have difficulty efficiently and accurately locating and manipulating firmware data during startup, firmware loading, data backup, or recovery, thus affecting the reliability and efficiency of the upgrade process.

[0081] Therefore, referring to Figure 8 Another embodiment of the present invention provides an upgrade method for a fault diagnosis device, based on the above. Figure 1 The embodiment shown sets the first storage area as the current firmware storage area and the second storage area as the backup firmware storage area, including steps S110-S130, wherein: S110. Obtain the stored configuration information when the fault diagnosis device starts up; S120. Based on the storage configuration information, map the starting address of the first storage area to the firmware running entry point, and map the starting address of the second storage area to the firmware backup entry point. S130. Establish a correspondence table between the first storage area and the second storage area. The correspondence table records the mapping relationship between the address of each storage block in the first storage area and the address of the corresponding backup storage block in the second storage area.

[0082] When the fault diagnosis device starts up, the control unit first needs to obtain its internal storage configuration information. This storage configuration information is typically pre-stored in the device's non-volatile memory (e.g., a specific area of ​​EEPROM or Flash memory) or obtained by reading specific hardware registers. The storage configuration information may include the physical address range, capacity, storage medium type (e.g., NOR Flash, NAND Flash), and logical partition layout of each storage area. After the fault diagnosis device is powered on or reset, the bootloader will first execute this step to initialize the storage controller and identify available storage resources.

[0083] After obtaining the storage configuration information, the control device performs address mapping based on this information. Specifically, the starting address of the first storage area is designated as the firmware execution entry point. This means that the processor will begin executing firmware code from this address during startup, thus initiating normal device operation. Furthermore, the starting address of the second storage area is designated as the firmware backup entry point, which indicates the storage starting point for backup firmware data. This mapping can be a conversion from physical address to logical address, or it can directly designate a physical address as a specific function entry point. For example, in an embedded system, the bootloader loads a specific physical address from the first storage area into the program counter (PC) based on the configuration information, thereby starting firmware execution; additionally, it records the starting address of the second storage area for subsequent backup operations.

[0084] To achieve better storage management and data operations, the control device establishes a mapping table between a first storage area and a second storage area. This mapping table is a data structure that can be stored in the device's non-volatile memory or RAM. The table records the addresses of each storage block (e.g., sector, page, or smaller logical unit) in the first storage area, and the addresses of their corresponding backup storage blocks in the second storage area. For example, the mapping table can contain multiple entries, each recording the correspondence between "the address of sector X in the first storage area" and "the address of sector Y in the second storage area." Using this mapping table, the control device can quickly and accurately locate the corresponding target backup address in the second storage area based on the address of the data block to be operated on in the first storage area when performing data backup, recovery, or verification operations, thereby achieving efficient and accurate data transfer. This mapping relationship can be linear or non-linear to adapt to different storage management strategies, such as skipping bad blocks or optimizing storage layout.

[0085] Through the above technical solution, the fault diagnosis equipment can obtain its storage configuration information upon startup and, based on this, explicitly map the starting address of the first storage area as the firmware execution entry point and the starting address of the second storage area as the firmware backup entry point. This solves the problems of inaccurate firmware location and low loading efficiency caused by the lack of clear storage area management during firmware upgrades, ensuring that the fault diagnosis equipment can quickly and reliably start and identify the currently running firmware and backup firmware. By establishing a correspondence table between the first and second storage areas, the address mapping relationship of each storage block is recorded, enabling the control device to perform data transfer accurate to the storage block level during data backup or recovery operations. This not only significantly improves the efficiency and accuracy of data backup and recovery, avoiding unnecessary full-disk data copying, but also provides a solid foundation for subsequent incremental updates, bad block management, and rapid rollback operations, thereby comprehensively improving the reliability, flexibility, and maintainability of the firmware upgrade process of the fault diagnosis equipment.

[0086] When traditional fault diagnosis equipment performs remote upgrades in areas with unstable power and network environments (such as high-temperature and high-humidity environments in third-world countries), the upgrade process is often terminated abruptly due to unexpected interruption events such as communication interruptions, power supply abnormalities, or memory write failures. This can lead to abnormal equipment functions or firmware damage, seriously affecting the reliability and security of the upgrade process. It is difficult to meet the continuous adaptation needs of fault diagnosis equipment for multiple brands and models of servers in complex environments.

[0087] The present invention also proposes a control device, which includes: a memory, a processor, and an upgrade program for a fault diagnosis device stored in the memory and executable on the processor. The upgrade program for the fault diagnosis device is configured to implement the above-described upgrade method for the fault diagnosis device.

[0088] The core innovation of this embodiment lies in combining the upgrade program of the fault diagnosis device with upgrade logic that includes a forced backup mechanism, breakpoint resume function, and intelligent storage area management. This allows for the safe pause and resumption of the upgrade process during power outages or network fluctuations. Specifically, before executing the upgrade, the upgrade program backs up the current firmware data from the first storage area to the second storage area. During the download and writing of the target firmware data, it monitors the power supply voltage, network signal strength, and memory status in real time. If an anomaly is detected, the operation is paused and the breakpoint location is recorded. Upon resumption, the program automatically resumes the transfer of incomplete data. Simultaneously, it utilizes an address mapping table to manage the writable state of the storage units, effectively avoiding the risk of firmware corruption due to unexpected interruptions.

[0089] The above technical solutions significantly improve the upgrade reliability of fault diagnosis equipment in harsh environments, ensuring that the equipment can safely complete firmware updates even under unstable power or network conditions. This provides a solid technical guarantee for the standardized diagnosis of multi-brand and multi-model server components, while also solving compatibility issues caused by protocol upgrades and extending the service life and applicability of the equipment.

[0090] It is worth noting that since the control device of the present invention is based on the above-described upgrade method for fault diagnosis equipment, the embodiments of the control device of the present invention include all the technical solutions of all embodiments of the above-described upgrade method for fault diagnosis equipment, and the technical effects achieved are exactly the same, so they will not be repeated here.

[0091] The present invention also proposes a fault diagnosis device, which includes a control device as described in the above embodiments.

[0092] A fault diagnosis device is a specialized apparatus for detecting, analyzing, and locating faults in a system or equipment. It typically integrates necessary hardware components, such as sensors, data acquisition modules, processing units, storage units, and communication interfaces, designed to run specific diagnostic programs to monitor the status of the target equipment, provide early warnings of faults, and locate faults. As the physical carrier of the upgrade method and the aforementioned control devices, this fault diagnosis device provides the hardware environment required to perform firmware upgrades, ensuring the stability and reliability of the upgrade process. For example, the device can be a standalone portable diagnostic instrument or a module integrated into an industrial control system. Internally, it typically includes a main control unit (such as a microcontroller or embedded processor), a memory for storing firmware and diagnostic data, and input / output interfaces for connecting the device under test (DUT) and the user interface. It is also equipped with a communication module for data interaction with a remote management backend.

[0093] The fault diagnosis device includes the control unit described in the above embodiment. The control unit is the core intelligent component of the fault diagnosis device, and its primary responsibility is to execute the upgrade method of the fault diagnosis device. This control unit typically consists of a memory, a processor, and an upgrade program for the fault diagnosis device stored in the memory and executable on the processor. The processor is responsible for parsing and executing the instructions in the upgrade program, coordinating all upgrade steps such as data backup, download, writing, error handling, and recovery. The memory stores the operating system, firmware, and the upgrade program itself, and provides the data storage space required for runtime. For example, the processor can be a high-performance embedded microprocessor, such as the ARM Cortex series, while the memory can include RAM for fast read / write operations and Flash memory for persistent firmware storage. The upgrade program is a pre-written set of instructions executed by the processor to automate the firmware update of the fault diagnosis device.

[0094] Through the above technical solution, this embodiment provides a complete fault diagnosis device that organically integrates the aforementioned upgrade method and control device into an operable physical entity. As a platform, this fault diagnosis device integrates all the hardware resources required to execute the upgrade program, including a processor, memory, and communication interface, thereby ensuring the stability and reliability of the firmware upgrade process. This enables the fault diagnosis device to perform firmware updates autonomously without manual intervention or external programming equipment, greatly improving the maintenance efficiency and availability of the device. Furthermore, by embedding the control device within the fault diagnosis device, better hardware-software collaboration can be achieved, the upgrade process can be optimized, and abnormal situations that may occur during the upgrade process, such as power outages or communication interruptions, can be effectively handled, thereby ensuring the integrity of the device firmware and the stability of the system, ensuring that the fault diagnosis device always operates in the latest and optimal state.

[0095] It is worth noting that since the fault diagnosis device of the present invention is based on the above-mentioned control device, the embodiments of the fault diagnosis device of the present invention include all the technical solutions of all the embodiments of the above-mentioned control device, and the technical effects achieved are exactly the same, which will not be repeated here.

[0096] The principle of the solution in this application will now be explained through a feasible implementation method, in conjunction with all the above embodiments: The diagnostic device connects to a power module from Manufacturer X, which is the device under test. To ensure compatibility with the latest protocol, the device needs to check for firmware updates. The device automatically obtains the firmware identifier from the current firmware data. The device determines the model of the currently connected power module (e.g., "Manufacturer X Power Module P100") and its firmware version number (e.g., "V2.1"). This information (device model and firmware version number) is sent to a remote management backend. The remote management backend performs version matching based on the received information. The backend identifies that the current firmware version 1.0 of the diagnostic device is outdated and cannot diagnose the Manufacturer X Power Module P100, which requires support for the new protocol. The remote management backend determines a difference data block, which contains only code segments and configuration parameters that differ from the current firmware data of the diagnostic device. In this example, the difference data block is not empty, indicating the existence of target firmware data (version 1.1) that includes support for the new protocol.

[0097] Before performing an update, the diagnostic device initiates a forced backup operation. The diagnostic device examines the storage status of multiple storage units in the second storage area. It identifies writable storage units by removing marked bad blocks. The addresses of these writable storage units are written to the mapped address field of an address mapping table, and the addresses storing the current firmware data in the first storage area are written to the mapped address field of the address mapping table. During the backup operation, the current firmware data in the first storage area is copied to the identified writable storage units in the second storage area according to this address mapping table. Compared to systems that directly overwrite the backup area without prior verification or bad block management, this method reduces the risk of data loss.

[0098] The fault diagnosis device may also include a third storage area dedicated to downloading and temporarily storing target firmware data. Upon confirming the existence of the target firmware data, the fault diagnosis device immediately begins downloading the target firmware data (version 1.1) to the third storage area. This download process is independent of the completion status of the backup operation. During the download, the target firmware data is divided into multiple sequentially arranged target data blocks according to a preset data length. These target data blocks are written to the third storage area sequentially. During the download, the fault diagnosis device monitors its network connectivity. If a communication interruption is detected (e.g., due to network instability at location A), the download is paused. The fault diagnosis device records the sequence number of the last successfully written target data block and its corresponding storage address in the third storage area. When the network connection is restored, the fault diagnosis device sends a request to the remote management backend to continue downloading the incomplete target firmware data, starting from the next data block after the recorded target data block sequence number, and continues writing to the third storage area based on the recorded storage address. This mechanism ensures that the download can be reliably completed even in the event of intermittent network interruptions, without having to start from scratch.

[0099] After the current firmware data is successfully backed up to the second storage area and the target firmware data has been completely downloaded to the third storage area, the fault diagnosis device obtains the operating status of the first storage area. The fault diagnosis device queries the task scheduling queue of the first storage area to determine if it is in an idle state with no tasks executing and no interruption response. In this idle state, the target firmware data in the third storage area is copied to the first storage area in block-by-block write mode. During the write process, if a power outage is detected (a common occurrence in location A), the fault diagnosis device suspends the data writing from the third storage area to the first storage area and determines the write breakpoint. After power is restored, the fault diagnosis device continues writing the remaining target firmware data to the first storage area according to the breakpoint. Furthermore, if an address mapped to the first storage area becomes abnormal during the write process (e.g., a sector is corrupted), the fault diagnosis device obtains a spare location in the first storage area. The remaining data is written to this spare location, and the mapping relationship of the corresponding entries in the address mapping table is updated. This error handling mechanism during the write phase ensures the integrity of the firmware update and prevents firmware corruption from causing device malfunction, even in complex environments.

[0100] Unlike traditional upgrade methods that may directly overwrite active firmware without prior mandatory backups, this approach ensures a safe recovery point. Furthermore, unlike systems that may require a complete re-download during network or power outages, the ability to pause, record progress, and resume downloads significantly improves reliability in environments with unstable infrastructure. Utilizing a third storage area for pre-downloading also makes the update process more controlled and less disruptive, as the new firmware is ready before touching the active firmware, and the actual update to the first storage area only occurs when the device is idle. This layered reliability approach, from mandatory backups to resilient downloads and write operations, directly addresses the challenges of upgrading critical diagnostic devices in environments susceptible to power and network instability, preventing device malfunctions or firmware corruption.

[0101] 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 method for upgrading a fault diagnosis device, wherein the fault diagnosis device is provided with a first storage area and a second storage area, characterized in that, The upgrade method for the fault diagnosis equipment includes: Set the first storage area as the current firmware storage area, and set the second storage area as the backup firmware storage area; Obtain the current firmware data and the target firmware data in the remote management backend that differs from the current firmware data; Back up the current firmware data from the first storage area to the second storage area; After the backup is complete, the target firmware data is downloaded, and the current firmware data in the first storage area is updated to the target firmware data.

2. The upgrade method for the fault diagnosis equipment as described in claim 1, characterized in that, The acquisition of current firmware data and target firmware data in the remote management backend that differ from the current firmware data includes: Obtain the firmware identifier from the current firmware data to determine the model and firmware version number of the device under test currently connected to the fault diagnosis device. Send the device under test model and the device under test firmware version number to the remote management backend; The remote management backend receives a difference data block determined by version matching based on the device under test model and the firmware version number of the device under test. The difference data block contains only code segments and configuration parameters that are different from the current firmware data. If the difference data block is empty, the current firmware data is determined to be the latest version; If the difference data block is not empty, it is determined that the target firmware data exists.

3. The upgrade method for the fault diagnosis equipment as described in claim 1, characterized in that, The step of downloading the target firmware data and updating the current firmware data in the first storage area to the target firmware data includes: After the backup is complete, a download request is automatically sent to the remote management backend, and the target firmware data returned by the remote management backend is received. During the download process, the target firmware data is divided into multiple sequentially arranged target data blocks according to a preset data length; The target data blocks are written sequentially into the free area of ​​the first storage area, and after each target data block is written, the sequence number of the target data block and its corresponding storage address are recorded. If a communication interruption or power interruption is detected during the download or writing process, the download is paused and the sequence number and storage address of the target data block that was written at the time of the interruption are recorded. After communication or power is restored, starting from the next target data block with the sequence number of the target data block already written, the system continues to request the target firmware data that has not been downloaded from the remote management backend, and continues to write to the first storage area based on the recorded storage address, until all target data blocks are written.

4. The upgrade method for the fault diagnosis equipment as described in claim 1, characterized in that, The step of downloading the target firmware data and updating the current firmware data in the first storage area to the target firmware data includes: In response to a firmware upgrade instruction request, a download request is sent to the remote management backend, and the target firmware data is received from the remote management backend; During the process of receiving the target firmware data, the power supply voltage and network signal strength of the fault diagnosis device are monitored in real time. If the power supply voltage is detected to be lower than a preset voltage threshold, or the network signal strength is lower than a preset signal strength threshold, the first storage area is controlled to pause receiving target firmware data, and the data length of the target firmware data to be downloaded is determined, and a corresponding data identifier of the received portion of the target firmware data is generated. After the power supply voltage recovers to above the voltage threshold and the network signal strength recovers to above the signal strength threshold, a resume request is sent to the remote management backend. The resume request includes a data identifier of the partially received target firmware data, in order to receive the remaining target firmware data. The partial target firmware data is concatenated with the remaining target firmware data to form complete target firmware data, thereby replacing the current firmware data in the first storage area.

5. The upgrade method for the fault diagnosis equipment as described in claim 1, characterized in that, The step of backing up the current firmware data from the first storage area to the second storage area includes: Detect the storage status of multiple storage cells in the second storage area; When determining the writable storage unit among the multiple storage units based on the storage situation, the address of the writable storage unit is written to the mapped address in the address mapping table, and the address of the first storage area storing the current firmware data is written to the mapped address in the address mapping table, so that when performing a backup operation, data copying is performed based on the writable storage unit and the address mapping table.

6. The upgrade method for the fault diagnosis equipment as described in claim 1, characterized in that, The fault diagnosis device also includes a third storage area, which is used to download and store the target firmware data. The upgrade method for the fault diagnosis equipment also includes: If the target firmware data is found to exist, download the target firmware data to the third storage area; After the current firmware data is backed up from the first storage area to the second storage area, the running status of the first storage area is obtained; When the operating state is idle, the target firmware data in the third storage area is written to the first storage area.

7. The upgrade method for the fault diagnosis equipment as described in claim 6, characterized in that, When the operating state is idle, writing the target firmware data from the third storage area to the first storage area includes: Query the task scheduling queue of the first storage area to determine that the first storage area is in a stable idle state with no task execution and no interruption response; In the stable idle state, the target firmware data in the third storage area is copied to the first storage area in a block write manner; If a power outage is detected during the writing process, the data writing from the third storage area to the first storage area is paused, and the write breakpoint location is determined. After power is restored, the remaining data of the target firmware data is written to the first storage area according to the breakpoint location; If an error occurs in the address mapped to the first storage area during the writing process, obtain a backup location in the first storage area; Write the remaining data to the backup location and update the mapping relationship of the corresponding entry in the address mapping table.

8. The upgrade method for the fault diagnosis equipment as described in claim 1, characterized in that, Setting the first storage area as the current firmware storage area and the second storage area as the backup firmware storage area includes: Obtain the stored configuration information of the fault diagnosis device at startup; Based on the storage configuration information, the starting address of the first storage area is mapped to the firmware running entry point, and the starting address of the second storage area is mapped to the firmware backup entry point; Establish a mapping table between the first storage area and the second storage area. The mapping table records the mapping relationship between the address of each storage block in the first storage area and the address of the corresponding backup storage block in the second storage area.

9. A control device, characterized in that, The control device includes: a memory, a processor, and an upgrade program for a fault diagnosis device stored in the memory and executable on the processor, the upgrade program being configured to implement the upgrade method for the fault diagnosis device as described in any one of claims 1 to 8.

10. A fault diagnosis device, characterized in that, Includes the control device as described in claim 9.

Images