An I2C bus network maintenance method, device, equipment and medium

Abstract

The application discloses an I2C bus network maintenance method and device, equipment and medium, which is applied to a target system composed of a plurality of master devices connected with each other through an I2C bus in a mesh architecture, and comprises the following steps: when a second master device detects that the firmware version of a first master device is an abnormal version, the data exchange between the second master device and the first master device is stopped, the firmware version of the second master device is frozen, and the target state of the second master device is changed to a risk state and a frozen state; the second master device sends first alarm information to an upper-layer device, so that the upper-layer device updates the abnormal version of the first master device to a trusted version based on the first alarm information; when the second master device detects that the firmware version of the first master device is the trusted version, the data exchange between the second master device and the first master device is restored, the freezing of the firmware version of the second master device is released, and the target state of the second master device is changed to a normal state. The application can maintain an I2C bus network.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to an I2C bus network maintenance method, apparatus, device, and medium. Background Technology

[0002] Currently, the I2C (Inter-Integrated Circuit) bus is a two-wire serial bus developed by Philips for connecting microcontrollers and their peripherals. It is a widely adopted bus standard in the field of microelectronics communication and control. It is a special form of synchronous communication, with advantages such as fewer interface lines, simpler control methods, smaller device packages, and higher communication speeds.

[0003] I2C transmits information between devices connected to the bus via the Serial Data (SDA) and Serial Clock (SCL) lines. Each device has a unique address identifier and can act as either a transmitter or a receiver (depending on the device's function). The master device is the one that initiates data transmission on the bus and generates a clock signal that allows transmission. At this point, any addressed device is considered a slave.

[0004] In a typical I2C link, the configuration is relatively simple, consisting of one master and multiple slaves. However, when servers form a data center and are interconnected via I2C links, the I2C devices will create a multi-master, multi-slave mesh architecture. In this architecture, servers can interact through various interfaces. If one or more servers are tampered with, it will pose a risk to the entire I2C bus network and the data center.

[0005] In conclusion, how to maintain the I2C bus network is a problem that urgently needs to be solved. Summary of the Invention

[0006] In view of this, the purpose of this invention is to provide an I2C bus network maintenance method, apparatus, device, and medium capable of maintaining an I2C bus network. The specific solution is as follows:

[0007] In a first aspect, this application discloses an I2C bus network maintenance method, applied to a target system consisting of several master devices interconnected in a mesh architecture via an I2C bus, including:

[0008] When the second master device detects the firmware version of the first master device, if the firmware version of the first master device is detected to be an abnormal version, the data exchange between the second master device and the first master device is stopped, the firmware version of the second master device is frozen, and then the target state of the second master device is modified to a risk state and a frozen state; the second master device is a master device directly connected to the first master device.

[0009] The second master device sends a first alarm message to the upper-layer device connected to the target system, so that the upper-layer device updates the abnormal version corresponding to the first master device to a trusted version based on the first alarm message;

[0010] When the second master device detects that the firmware version of the first master device is the trusted version, it resumes data exchange between the second master device and the first master device, unfreezes the firmware version of the second master device, and then modifies the target state of the second master device to the normal state.

[0011] Optionally, before the step of stopping data exchange between the second master device and the first master device, freezing the firmware version of the second master device, and then modifying the target state of the second master device to a risk state and a frozen state when the second master device detects the firmware version of the first master device, further includes:

[0012] For each I2C master device, a status table is constructed to store its own master device number, target status, and firmware version number; different master devices have different master device numbers; the target status is one or more of the following: normal status, risk status, frozen status, and fault status.

[0013] Optionally, when the second master device detects the firmware version of the first master device, if the detected firmware version of the first master device is an abnormal version, the data exchange between the second master device and the first master device is stopped, and the firmware version of the second master device is frozen, including:

[0014] When the second master device detects that the firmware version number of the first master device has not passed the trust verification based on the preset verification rules, the firmware version of the first master device is an abnormal version. Then, the data exchange between the second master device and the first master device is stopped, and the firmware version of the second master device is frozen.

[0015] Accordingly, when the second master device detects that the firmware version of the first master device is the trusted version, resuming data exchange between the second master device and the first master device and unfreezing the firmware version of the second master device includes:

[0016] When the second master device detects that the firmware version number of the first master device passes the trust verification based on the preset verification rules, the firmware version of the first master device is the trusted version. Then, the data exchange between the second master device and the first master device is resumed, and the freeze on the firmware version of the second master device is lifted.

[0017] Optionally, the step of sending a first alarm message to an upper-layer device connected to the target system via the second master device, so that the upper-layer device updates the abnormal version corresponding to the first master device to a trusted version based on the first alarm message, includes:

[0018] The second master device sends a first alarm message, including the first master device number, risk status, and frozen status, to the upper-layer device connected to the target system. This allows the upper-layer device to determine the first master device with a risk status and a frozen status based on the first master device number in the first alarm message, and to update the abnormal version corresponding to the first master device to a trusted version.

[0019] Optionally, the I2C bus network maintenance method further includes:

[0020] When the second master device detects the firmware version of the first master device, and the first master device detects the firmware version of the second master device, if neither the firmware version of the first master device nor the firmware version of the second master device can be detected, then the target state of the second master device is changed to a fault state, and the target state of the first master device is changed to a fault state.

[0021] The first master device sends a second alarm message, including the first master device number and fault status, to the upper-layer device connected to the target system. The second master device sends a third alarm message, including the second master device number and fault status, to the upper-layer device, so that the upper-layer device can obtain target information about the communication link between the first master device and the second master device based on the second alarm message and the third alarm message.

[0022] Optionally, after modifying the target state of the second master device to a risk state and a frozen state, the method further includes:

[0023] Based on the preset main device freezing range, determine the target main device that needs to be frozen and is directly or indirectly connected to the second main device.

[0024] Iterate through all the target master devices to freeze the firmware version of all the target master devices and change the target state of all the target master devices to the frozen state.

[0025] Optionally, after modifying the target state of the second master device to the normal state, the method further includes:

[0026] Traverse all the target master devices to unfreeze the firmware version of the fourth master device and modify the target state of all the target master devices to the normal state.

[0027] Secondly, this application discloses an I2C bus network maintenance device, applied to a target system consisting of several master devices interconnected in a mesh architecture via an I2C bus, comprising:

[0028] The first detection module is used to, when the second main device detects the firmware version of the first main device, if it detects that the firmware version of the first main device is an abnormal version, stop the data exchange between the second main device and the first main device, freeze the firmware version of the second main device, and then modify the target state of the second main device to a risk state and a frozen state; the second main device is a main device directly connected to the first main device.

[0029] An alarm module is used to send a first alarm message to an upper-layer device connected to the target system via the second main device, so that the upper-layer device updates the abnormal version corresponding to the first main device to a trusted version based on the first alarm message;

[0030] The second detection module is used to restore data exchange between the second main device and the first main device when the second main device detects that the firmware version of the first main device is the trusted version, and to unfreeze the firmware version of the second main device, and then modify the target state of the second main device to the normal state.

[0031] Thirdly, this application discloses an electronic device, including a processor and a memory; wherein, when the processor executes a computer program stored in the memory, it implements the aforementioned disclosed I2C bus network maintenance method.

[0032] Fourthly, this application discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned disclosed I2C bus network maintenance method.

[0033] As can be seen, when the second master device detects the firmware version of the first master device, if the firmware version of the first master device is detected to be an abnormal version, the data exchange between the second master device and the first master device is stopped, the firmware version of the second master device is frozen, and then the target state of the second master device is modified to a risk state and a frozen state. The second master device is a master device directly connected to the first master device. The second master device sends a first alarm message to an upper-layer device connected to the target system, so that the upper-layer device updates the abnormal version corresponding to the first master device to a trusted version based on the first alarm message. When the second master device detects that the firmware version of the first master device is the trusted version, the data exchange between the second master device and the first master device is resumed, the freeze on the firmware version of the second master device is lifted, and then the target state of the second master device is modified to a normal state. Therefore, this application sends a first alarm message to the upper-layer device through a second master device connected to the first master device, so that the upper-layer device updates the abnormal version corresponding to the first master device to a trusted version based on the first alarm message, thereby realizing the correction of the firmware version of the first master device to maintain the I2C bus network; in addition, by stopping the data exchange between the second master device and the first master device and freezing the firmware version of the second master device, the firmware version of the second master device can be prevented from being affected by the abnormal version of the first master device, making the I2C bus network more secure. Attached Figure Description

[0034] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0035] Figure 1 A flowchart of an I2C bus network maintenance method is provided for this application;

[0036] Figure 2 This application provides a standard flowchart for reading an I2C register.

[0037] Figure 3 This application provides a standard flowchart for writing an I2C register.

[0038] Figure 4 A specific target system schematic diagram is provided for this application;

[0039] Figure 5A flowchart of a specific I2C bus network maintenance method provided in this application;

[0040] Figure 6 A schematic diagram of an I2C bus network maintenance device is provided for this application;

[0041] Figure 7 This application provides a structural diagram of an electronic device. Detailed Implementation

[0042] 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, and not all embodiments. 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.

[0043] Currently, I2C links are typically simple, consisting of one master and multiple slaves. When servers form a data center and I2C links are interconnected, the I2C devices will form a multi-master, multi-slave mesh architecture. In this architecture, servers can interact through various interfaces. If one or more servers are tampered with, it will pose a risk to the entire I2C bus network and the data center.

[0044] To overcome the above problems, this application provides an I2C bus network maintenance scheme that can maintain the I2C bus network.

[0045] See Figure 1 As shown in the figure, this application discloses an I2C bus network maintenance method, applied to a target system consisting of several master devices interconnected in a mesh architecture via an I2C bus. The method includes:

[0046] Step S11: When the second master device detects the firmware version of the first master device, if the firmware version of the first master device is detected to be an abnormal version, the data exchange between the second master device and the first master device is stopped, the firmware version of the second master device is frozen, and then the target state of the second master device is modified to a risk state and a frozen state; the second master device is a master device directly connected to the first master device.

[0047] Existing technology centers, such as Figure 2The diagram shows the standard procedure for reading an I2C register, including: 1. The Master sends I2Caddr (7 bits) and w operation 1 (1 bit), and waits for ACK; 2. The Slave sends ACK; 3. The Master sends reg addr (8 bits), and waits for ACK; 4. The Slave sends ACK; 5. The Master initiates START; 6. The Master sends I2C addr (7 bits) and r operation 1 (1 bit), and waits for ACK; 7. The Slave sends ACK; 8. The Slave sends data (8 bits), which is the value in the register; 9. The Master sends ACK; 10. Steps 8 and 9 can be repeated multiple times, i.e., reading multiple registers sequentially. Figure 3 The diagram shows the standard procedure for writing an I2C register, including: 1. Master initiates START; 2. Master sends I2C addr (7 bits) and w operation 0 (1 bit), and waits for ACK; 3. Slave sends ACK; 4. Master sends reg addr (8 bits), and waits for ACK; 5. Slave sends ACK; 6. Master sends data (8 bits), which is the data to be written to the register, and waits for ACK; 7. Slave sends ACK; 8. Steps 6 and 7 can be repeated multiple times, i.e., writing to multiple registers sequentially; 9. Master initiates STOP.

[0048] In this embodiment of the application, before the second master device detects the firmware version of the first master device, and if the firmware version of the first master device is detected to be an abnormal version, the data exchange between the second master device and the first master device is stopped, the firmware version of the second master device is frozen, and the target state of the second master device is modified to a risk state and a frozen state, the method further includes: constructing a state table for each I2C master device to store its own master device number, target state, and firmware version number; different master devices have different master device numbers; the target state is one or more of a normal state, a risk state, a frozen state, and a fault state. The first master device's firmware version is an abnormal version, meaning that the first master device in the network has had its system firmware tampered with, becoming a vulnerability source with a "backdoor".

[0049] It should be noted that each of the aforementioned master devices has a corresponding state table, which can be called a register table. This table records the device's state, stores the node's BMC firmware version and other version information, and can be accessed by other devices. All I2C master devices periodically initiate communication with each other to obtain the state of surrounding devices. It should also be noted that upper-layer applications can access the state table using other high-speed interfaces. They can read information from the table, but writing is not supported to prevent tampering due to external factors. Furthermore, as shown in Table 1, which illustrates the state representation of the three master devices, the master device number, system firmware version, and device state need to be initialized and configured during the network setup phase.

[0050] Table 1

[0051] serial number System firmware version Device status (target status) 00000001 00000110 1000 00000110 00001110 1000 00001110 00000111 1000

[0052] The master device number represents a master device in the I2C network. This number is unique within the network and is recorded using an 8-bit binary number, with a maximum of 256. Expansion can be achieved by increasing the register width. Through the setting of this device address (master device number), all I2C devices can form an interconnected network. The system firmware version represents the policy version code of the slave device's internal control subsystem. It is automatically generated after initialization with each policy update. This policy version code allows comparison of the versions of two master devices; I2C devices using older versions will be updated. Device status indicates the current state of the device. The status is divided into four bits: the first bit indicates "normal," the second bit indicates "fault," the third bit indicates "risk," and the fourth bit indicates "frozen." The meanings of each part are as follows: Normal state: The data in the current I2C is normal, the firmware version is trustworthy, and data communication is allowed; Fault state: The current I2C node communication link is abnormal, and normal communication is impossible; the current node is faulty; Risk state: The firmware version number of the node connected to the current node has not passed the trust verification. In this state, data interaction will stop to prevent intrusion; Frozen state: In this state, normal interaction is maintained, but firmware updates for this node are refused to prevent tampering with the system firmware.

[0053] In this embodiment, when the second main device detects the firmware version of the first main device, if the firmware version of the first main device is detected to be an abnormal version, then stopping the data exchange between the second main device and the first main device and freezing the firmware version of the second main device includes: when the second main device detects, based on a preset verification rule, that the version number of the firmware version of the first main device has not passed the trust verification, the firmware version of the first main device is an abnormal version, then stopping the data exchange between the second main device and the first main device and freezing the firmware version of the second main device. It should be noted that stopping the data exchange between the second main device and the first main device and freezing the firmware version of the second main device can further ensure that the second main device is not affected by the abnormal version of the first main device. It should also be noted that a pre-defined underlying naming rule for the firmware version number is used to perform a trust verification on the version number of the firmware version of the first main device according to the underlying naming rule.

[0054] In this embodiment of the application, the target state of the second main device is modified to a risk state and a frozen state, at which time the target state is displayed as 0011.

[0055] In the embodiments of this application, such as Figure 4 As shown, this is a target system consisting of nine I2C master devices arranged in a two-dimensional plane and interconnected via an I2C bus. The status table is shown in Table 2. In the initialization state, the I2C firmware versions are the same (00100), and the device status (target status) is the same (normal, 1000).

[0056] Table 2

[0057] serial number System firmware version Device status 00000001 00100 1000 00000010 00100 1000 00000011 00100 1000 00000100 00100 1000

[0058] In this embodiment, the upper layer updates the strategy information of the main device 1. When the firmware version of the main device 1 changes to 00101, the other devices remain unchanged. During routine polling, the main devices 2 and 4, which are directly connected to the main device 1, discover that the main device 1 has been updated. Since the tamper does not understand the underlying naming rules, the code set by the tamper cannot pass the verification. During the reading process, the main devices 2 and 4 discover that the main device 1 is abnormal and change their own status to 0011, i.e., "risk" or "frozen", and send an alarm to the upper layer of their devices. Devices 2 and 4 detect that the code of device 1 in the system has passed the verification, clear their own "risk" or "frozen" status bits, and maintain the "normal" status.

[0059] In this embodiment, when the second master device detects the firmware version of the first master device, and the first master device detects the firmware version of the second master device, if neither the first nor the second master device's firmware version can be detected, the target state of the second master device is modified to a fault state, and the target state of the first master device is also modified to a fault state. The first master device sends a second alarm message, including the first master device's first master device number and the fault state, to the upper-layer device connected to the target system. The second master device also sends a third alarm message, including the second master device's second master device number and the fault state, to the upper-layer device, so that the upper-layer device can obtain target information about the communication link anomaly between the first and second master devices based on the second and third alarm messages. It should be noted that when the target state is a fault state, it is displayed as 0100.

[0060] Step S12: Send a first alarm message to the upper-layer device connected to the target system through the second master device, so that the upper-layer device updates the abnormal version corresponding to the first master device to a trusted version based on the first alarm message.

[0061] In this embodiment of the application, the step of sending a first alarm message to an upper-layer device connected to the target system via the second master device, so that the upper-layer device updates the abnormal version corresponding to the first master device to a trusted version based on the first alarm message, includes: sending a first alarm message including the first master device number, risk status, and frozen status of the first master device to the upper-layer device connected to the target system via the second master device, so that the upper-layer device determines the first master device with a target status of risk status and frozen status based on the first master device number in the first alarm message, and updates the abnormal version corresponding to the first master device to a trusted version.

[0062] Step S13: When the second master device detects that the firmware version of the first master device is the trusted version, it resumes the data exchange between the second master device and the first master device, unfreezes the firmware version of the second master device, and then modifies the target state of the second master device to the normal state.

[0063] In this embodiment of the application, the step of resuming data exchange between the second main device and the first main device and unfreezing the firmware version of the second main device when the second main device detects that the firmware version number of the first main device passes the trust verification based on a preset verification rule, indicating that the firmware version of the first main device is the trust version, then the data exchange between the second main device and the first main device is resumed, and the firmware version of the second main device is unfrozen. It should be noted that a pre-defined underlying naming rule for the firmware version number is used to perform trust verification on the firmware version number of the first main device according to the underlying naming rule.

[0064] As can be seen, when the second master device detects the firmware version of the first master device, if the firmware version of the first master device is detected to be an abnormal version, the data exchange between the second master device and the first master device is stopped, the firmware version of the second master device is frozen, and then the target state of the second master device is modified to a risk state and a frozen state. The second master device is a master device directly connected to the first master device. The second master device sends a first alarm message to an upper-layer device connected to the target system, so that the upper-layer device updates the abnormal version corresponding to the first master device to a trusted version based on the first alarm message. When the second master device detects that the firmware version of the first master device is the trusted version, the data exchange between the second master device and the first master device is resumed, the freeze on the firmware version of the second master device is lifted, and then the target state of the second master device is modified to a normal state. Therefore, this application sends a first alarm message to the upper-layer device through a second master device connected to the first master device, so that the upper-layer device updates the abnormal version corresponding to the first master device to a trusted version based on the first alarm message, thereby realizing the correction of the firmware version of the first master device to maintain the I2C bus network; in addition, by stopping the data exchange between the second master device and the first master device and freezing the firmware version of the second master device, the firmware version of the second master device can be prevented from being affected by the abnormal version of the first master device, making the I2C bus network more secure.

[0065] See Figure 5 As shown in the figure, this application discloses a specific I2C bus network maintenance method, applied to a target system consisting of several master devices interconnected in a mesh architecture via an I2C bus. The method includes:

[0066] Step S21: When the second master device detects the firmware version of the first master device, if the firmware version of the first master device is detected to be an abnormal version, the data exchange between the second master device and the first master device is stopped, the firmware version of the second master device is frozen, and then the target state of the second master device is modified to a risk state and a frozen state; the second master device is a master device directly connected to the first master device.

[0067] In this embodiment, the specific process of step S21 can be referred to the corresponding content disclosed in the previous embodiments, and will not be repeated here.

[0068] Step S22: Based on the preset main device freeze range, determine the target main devices that are directly or indirectly connected to the second main device that need to be frozen; traverse all the target main devices to freeze the firmware version of all the target main devices, and modify the target state of all the target main devices to the frozen state.

[0069] In this embodiment, target main devices that are directly or indirectly connected to the second main device and need to be frozen are determined based on a preset main device freeze range. When the third main device detects that the target state is a risk state or a frozen state, the firmware version of the third main device is frozen, and the target state of the third main device is modified to a frozen state. The third main device is the target main device whose firmware version is in a normal state and is directly connected to the second main device. When the fourth main device detects that the target state of the third main device is frozen, the firmware version of the fourth main device is frozen, and the target state of the fourth main device is modified to a frozen state. The fourth main device is detected as the target main device whose firmware version is in a normal state and is directly connected to the third main device. The detection is performed sequentially to traverse all the target main devices, freeze the firmware versions of all the target main devices, and modify the target state of all the target main devices to a frozen state.

[0070] In this embodiment, in addition to stopping data exchange between the second master device and the first master device and freezing the firmware version of the second master device, the firmware version of the target master device is further frozen, and the target state of the third master device is modified to a frozen state, which can enhance the security of the I2C bus network. It should be noted that the master device can only detect the state of the master device directly connected to it.

[0071] It should be pointed out that, such as Figure 4As shown, the strategy information of the upper-layer device 1 is updated. Assume the firmware version of the main device 1 changes to 00101, while the firmware versions of other devices remain unchanged. During routine polling, main devices 2 and 4, connected to main device 1, detect the update. Since the tamper is unaware of the underlying naming rules, their assigned code fails verification. Upon reading the firmware, main devices 2 and 4 detect the anomaly in main device 1 and change their own status to 0011 ("risk" or "frozen"). They also send an alert to the upper layer. The version codes of devices 3, 5, and 7, connected to main devices 2 and 4, are identical to those of main devices 2 and 4. Upon learning that main devices 2 and 4 have entered the "risk" state, they confirm an anomaly in the entire system and enter the "frozen" state themselves. Optionally, devices 6, 8, and 9, upon detecting that devices 3, 5, and 7 have entered the "frozen" state, will also freeze themselves. This function can be configured according to the security level of the upper-layer network to avoid impacting system operation and maintenance due to freezing too many nodes; that is, a preset freezing range for main devices can be set based on the security level of the upper-layer network.

[0072] In this embodiment of the application, the target host device is frozen by using an automatic diffusion synchronization method, thereby achieving policy security for the I2C bus network.

[0073] Step S23: Send a first alarm message to the upper-layer device connected to the target system through the second master device, so that the upper-layer device updates the abnormal version corresponding to the first master device to a trusted version based on the first alarm message.

[0074] In this embodiment, the specific process of step S23 can be referred to the corresponding content disclosed in the previous embodiments, and will not be repeated here.

[0075] Step S24: When the second master device detects that the firmware version of the first master device is the trusted version, the data exchange between the second master device and the first master device is resumed, the firmware version of the second master device is unfrozen, and then the target state of the second master device is modified to the normal state.

[0076] In this embodiment, the specific process of step S24 can be referred to the corresponding content disclosed in the previous embodiments, and will not be repeated here.

[0077] Step S25: Traverse all the target master devices to unfreeze the firmware version of the fourth master device and modify the target state of all the target master devices to the normal state.

[0078] In this embodiment, when the third main device detects that the target state of the second main device is normal, the firmware version of the third main device is unfrozen, and the target state of the third main device is modified to normal; when the fourth main device detects that the target state of the third main device is normal, the firmware version of the fourth main device is unfrozen, and the target state of the fourth main device is modified to normal; the detection is performed sequentially to traverse all the target main devices, so as to unfrozen the firmware version of the fourth main device and modify the target state of all the target main devices to normal.

[0079] In this embodiment, after the above operations are completed, all device states (target states) become 1000, the tampering handling is completed, and the entire system is in a trusted environment. This prevents the first master device in the network from having its system firmware tampered with, becoming a vulnerability source with a "backdoor".

[0080] As can be seen, this application sends a first alarm message to the upper-layer device through a second master device connected to the first master device, so that the upper-layer device updates the abnormal version corresponding to the first master device to a trusted version based on the first alarm message, thereby correcting the firmware version of the first master device to maintain the I2C bus network. In addition, by stopping data exchange between the second master device and the first master device and freezing the firmware version of the second master device, the firmware version of the second master device can be prevented from being affected by the abnormal version of the first master device, making the I2C bus network more secure. Furthermore, the security of the I2C bus network is further enhanced by freezing the firmware versions of all target master devices.

[0081] See Figure 6 As shown, this application discloses an I2C bus network maintenance device, applied to a target system consisting of several master devices interconnected in a mesh architecture via an I2C bus, including:

[0082] The first detection module 11 is used to, when the second main device detects the firmware version of the first main device, if it detects that the firmware version of the first main device is an abnormal version, stop the data exchange between the second main device and the first main device, freeze the firmware version of the second main device, and then modify the target state of the second main device to a risk state and a frozen state; the second main device is a main device directly connected to the first main device.

[0083] Alarm module 12 is used to send first alarm information to an upper-layer device connected to the target system through the second main device, so that the upper-layer device updates the abnormal version corresponding to the first main device to a trusted version based on the first alarm information;

[0084] The second detection module 13 is used to restore data exchange between the second main device and the first main device when the second main device detects that the firmware version of the first main device is the trusted version, and to unfreeze the firmware version of the second main device, and then modify the target state of the second main device to the normal state.

[0085] For more detailed information on the working process of each of the above modules, please refer to the relevant content disclosed in the foregoing embodiments, which will not be repeated here.

[0086] As can be seen, when the second master device detects the firmware version of the first master device, if the firmware version of the first master device is detected to be an abnormal version, the data exchange between the second master device and the first master device is stopped, the firmware version of the second master device is frozen, and then the target state of the second master device is modified to a risk state and a frozen state. The second master device is a master device directly connected to the first master device. The second master device sends a first alarm message to an upper-layer device connected to the target system, so that the upper-layer device updates the abnormal version corresponding to the first master device to a trusted version based on the first alarm message. When the second master device detects that the firmware version of the first master device is the trusted version, the data exchange between the second master device and the first master device is resumed, the freeze on the firmware version of the second master device is lifted, and then the target state of the second master device is modified to a normal state. Therefore, this application sends a first alarm message to the upper-layer device through a second master device connected to the first master device, so that the upper-layer device updates the abnormal version corresponding to the first master device to a trusted version based on the first alarm message, thereby realizing the correction of the firmware version of the first master device to maintain the I2C bus network; in addition, by stopping the data exchange between the second master device and the first master device and freezing the firmware version of the second master device, the firmware version of the second master device can be prevented from being affected by the abnormal version of the first master device, making the I2C bus network more secure.

[0087] Furthermore, embodiments of this application also provide an electronic device. Figure 7 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application.

[0088] Figure 7This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of this application. Specifically, the electronic device 20 may include: at least one processor 21, at least one memory 22, a power supply 23, an input / output interface 24, a communication interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps of the I2C bus network maintenance method disclosed in any of the foregoing embodiments.

[0089] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 25 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 24 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0090] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The memory 22 can be a random access memory that can be used as running memory and a non-volatile memory used for external memory storage. The storage resources on it include operating system 221, computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0091] The operating system 221 is used to manage and control the various hardware devices on the electronic device 20 on the source host and the computer program 222. The operating system 221 can be Windows, Unix, Linux, etc. In addition to the computer program that can be used to perform the I2C bus network maintenance method executed by the electronic device 20 as disclosed in any of the foregoing embodiments, the computer program 222 may further include computer programs that can be used to perform other specific tasks.

[0092] In this embodiment, the input / output interface 24 may include, but is not limited to, a USB interface, a hard disk read interface, a serial interface, a voice input interface, a fingerprint input interface, etc.

[0093] Furthermore, embodiments of this application also disclose a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned disclosed I2C bus network maintenance method.

[0094] For the specific steps of this method, please refer to the relevant content disclosed in the foregoing embodiments, which will not be repeated here.

[0095] The computer-readable storage medium referred to herein includes random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disks, magnetic disks, optical disks, or any other form of storage medium known in the art. When the computer program is executed by a processor, it implements the aforementioned I2C bus network maintenance method. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0096] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the I2C bus network maintenance method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0097] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0098] The steps of the algorithm described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0099] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0100] The above provides a detailed description of the I2C bus network maintenance method, apparatus, device, and medium provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A method of maintaining an I2C bus network, characterized by, Applied to target systems consisting of several master devices interconnected in a mesh architecture via an I2C bus, including: When the second master device detects the firmware version of the first master device, if the firmware version of the first master device is detected to be an abnormal version, the data exchange between the second master device and the first master device is stopped, the firmware version of the second master device is frozen, and then the target state of the second master device is modified to a risk state and a frozen state; the second master device is a master device directly connected to the first master device. The second master device sends a first alarm message to the upper-layer device connected to the target system, so that the upper-layer device updates the abnormal version corresponding to the first master device to a trusted version based on the first alarm message; When the second master device detects that the firmware version of the first master device is the trusted version, it resumes the data exchange between the second master device and the first master device, unfreezes the firmware version of the second master device, and then modifies the target state of the second master device to the normal state. When the second master device detects the firmware version of the first master device, if the firmware version of the first master device is detected to be an abnormal version, then the data exchange between the second master device and the first master device is stopped, and the firmware version of the second master device is frozen, including: When the second master device detects that the firmware version number of the first master device has not passed the trust verification based on the preset verification rules, the firmware version of the first master device is an abnormal version. Then, the data exchange between the second master device and the first master device is stopped, and the firmware version of the second master device is frozen. Accordingly, when the second master device detects that the firmware version of the first master device is the trusted version, resuming data exchange between the second master device and the first master device and unfreezing the firmware version of the second master device includes: When the second master device detects that the firmware version number of the first master device passes the trust verification based on the preset verification rules, the firmware version of the first master device is the trusted version. Then, the data exchange between the second master device and the first master device is resumed, and the freeze on the firmware version of the second master device is lifted.

2. The I2C bus network maintenance method of claim 1, wherein, Before the second master device detects the firmware version of the first master device and, if it detects that the firmware version of the first master device is an abnormal version, stops data exchange between the second master device and the first master device, freezes the firmware version of the second master device, and then modifies the target state of the second master device to a risk state and a frozen state, the method further includes: For each I2C master device, a status table is constructed to store its own master device number, target status, and firmware version number; different master devices have different master device numbers; the target status is one or more of the following: normal status, risk status, frozen status, and fault status.

3. The I2C bus network maintenance method of claim 2, wherein, The step of sending a first alarm message to an upper-layer device connected to the target system via the second master device, so that the upper-layer device updates the abnormal version corresponding to the first master device to a trusted version based on the first alarm message, includes: The second master device sends a first alarm message, including the first master device number, risk status, and frozen status, to the upper-layer device connected to the target system. This allows the upper-layer device to determine the first master device with a risk status and a frozen status based on the first master device number in the first alarm message, and to update the abnormal version corresponding to the first master device to a trusted version.

4. The I2C bus network maintenance method according to claim 2, characterized in that, Also includes: When the second master device detects the firmware version of the first master device, and the first master device detects the firmware version of the second master device, if neither the firmware version of the first master device nor the firmware version of the second master device can be detected, then the target state of the second master device is changed to a fault state, and the target state of the first master device is changed to a fault state. The first master device sends a second alarm message, including the first master device number and fault status, to the upper-layer device connected to the target system. The second master device sends a third alarm message, including the second master device number and fault status, to the upper-layer device, so that the upper-layer device can obtain target information about the communication link between the first master device and the second master device based on the second alarm message and the third alarm message.

5. A method of maintaining an I2C bus network according to any one of claims 1 to 4, characterized in that, After modifying the target state of the second main device to a risk state and a frozen state, the method further includes: Based on the preset main device freezing range, determine the target main device that needs to be frozen and is directly or indirectly connected to the second main device. Iterate through all the target master devices to freeze the firmware version of all the target master devices and change the target state of all the target master devices to the frozen state.

6. The I2C bus network maintenance method of claim 5, wherein, After modifying the target state of the second main device to the normal state, the method further includes: Iterate through all the target master devices to unfreeze the firmware versions of all the target master devices and modify the target state of all the target master devices to the normal state.

7. An I2C bus network maintenance device, characterized in that Applied to target systems consisting of several master devices interconnected in a mesh architecture via an I2C bus, including: The first detection module is used to, when the second main device detects the firmware version of the first main device, if it detects that the firmware version of the first main device is an abnormal version, stop the data exchange between the second main device and the first main device, freeze the firmware version of the second main device, and then modify the target state of the second main device to a risk state and a frozen state; the second main device is a main device directly connected to the first main device. An alarm module is used to send a first alarm message to an upper-layer device connected to the target system via the second main device, so that the upper-layer device updates the abnormal version corresponding to the first main device to a trusted version based on the first alarm message; The second detection module is used to restore data exchange between the second main device and the first main device when the second main device detects that the firmware version of the first main device is the trusted version, and to unfreeze the firmware version of the second main device, and then modify the target state of the second main device to the normal state. When the second master device detects the firmware version of the first master device, if the firmware version of the first master device is detected to be an abnormal version, then the data exchange between the second master device and the first master device is stopped, and the firmware version of the second master device is frozen, including: When the second master device detects that the firmware version number of the first master device has not passed the trust verification based on the preset verification rules, the firmware version of the first master device is an abnormal version. Then, the data exchange between the second master device and the first master device is stopped, and the firmware version of the second master device is frozen. Accordingly, when the second master device detects that the firmware version of the first master device is the trusted version, resuming data exchange between the second master device and the first master device and unfreezing the firmware version of the second master device includes: When the second master device detects that the firmware version number of the first master device passes the trust verification based on the preset verification rules, the firmware version of the first master device is the trusted version. Then, the data exchange between the second master device and the first master device is resumed, and the freeze on the firmware version of the second master device is lifted.

8. An electronic device, comprising: It includes a processor and a memory; wherein, when the processor executes a computer program stored in the memory, it implements the I2C bus network maintenance method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, Used to store computer programs; wherein, when the computer programs are executed by a processor, they implement the I2C bus network maintenance method as described in any one of claims 1 to 6.

Images