An IIC bus fault handling system

Abstract

An IIC bus fault handling system, relating to the field of circuit bus technology, includes: an IIC master controller having a signal transmission end and a first strobe end, the signal transmission end being used to communicate with slave devices via the IIC bus, and the first strobe end being used to output a channel strobe signal; a multiplexer having a first end, a second strobe end, and at least two second ends, the first end being connected to the signal transmission end of the IIC master controller, the second strobe end being connected to the first strobe end of the IIC master controller, and each second end being connected to at least one slave device; the multiplexer being used to select a path between the first end and one of the second ends according to the channel strobe signal received by the second strobe end; and a CPLD being used to determine that the IIC bus is in a hangup state in response to the detection end detecting that the SCL or SDA signal is continuously low for more than a preset time, and to perform fault handling operations, thereby realizing hardware-autonomous bus hangup detection and fault handling capabilities.

Description

Technical Field

[0001] This article relates to circuit bus technology, particularly an IIC bus fault handling system. Background Technology

[0002] The IIC (Inter-Integrated Circuit) bus is a two-wire, bidirectional serial communication bus consisting of an SCL (Serial Clock) line and an SDA (Serial Data) line. It is widely used in industrial switches, server motherboards, and communication equipment for communication between a master controller and multiple slave devices. To expand bus capabilities, multiplexers are often used to extend a master IIC bus into multiple sub-channels, with slave devices distributed across each channel.

[0003] In actual operation, the IIC bus may experience a "hang-up" phenomenon, where the SCL or SDA signal is abnormally and continuously pulled low, preventing the master controller from communicating with any slave devices. This phenomenon may be caused by a slave device abnormally pulling the bus low, a slave device not responding and timeout, or a bus arbitration conflict, and is particularly common under conditions such as long-term operation of the device, changes in ambient temperature, or electromagnetic interference.

[0004] To address this issue, existing technologies typically involve the master controller detecting the problem and restoring communication between the master controller and slave devices via a reset operation. However, this approach usually interrupts normal communication between the master controller and other healthy slave devices during the restoration process, resulting in the system losing its monitoring and access capabilities for these devices during recovery. Furthermore, because the specific fault causing the bus hang cannot be accurately identified, the same fault may recur after recovery, increasing the uncertainty of system operation. In addition, the time from the occurrence of a bus hang to communication restoration is relatively long, during which related functions are unavailable. These phenomena negatively impact system stability and availability in applications requiring high-reliability communication. Summary of the Invention

[0005] This application provides an IIC bus fault handling system, including: The IIC master controller has a signal transmission terminal and a first gating terminal. The signal transmission terminal is used to communicate with the slave device through the IIC bus, and the first gating terminal is used to output a channel gating signal. A multiplexer has a first terminal, a second gating terminal, and at least two second terminals. The first terminal is connected to the signal transmission terminal of the IIC master controller, and the second gating terminal is connected to the first gating terminal of the IIC master controller. Each second terminal is used to connect to at least one slave device through a downstream channel. The multiplexer is used to select a path between the first terminal and one of the second terminals according to the channel gating signal received by the second gating terminal. The CPLD has a detection terminal; the detection terminal is connected to the connection point between the signal transmission terminal of the IIC master controller and the first terminal of the multiplexer, and is used to detect the SCL and SDA signals on the IIC bus; the CPLD is used to determine that the IIC bus is in a hangup state and perform fault handling operation in response to the detection terminal detecting that the SCL or SDA signal is continuously low for more than a preset time.

[0006] In this embodiment, the CPLD is connected to the connection point between the IIC master controller signal transmission terminal and the first terminal of the multiplexer via a detection terminal, forming a hardware monitoring path independent of the IIC master controller. This avoids resource consumption and response delays caused by relying on the master controller software for detection. The channel expansion structure of the multiplexer allows each slave device to be distributed on an independent downstream channel, providing a physical basis for channel-level fault isolation. The direct connection between the first gating terminal of the IIC master controller and the second gating terminal of the multiplexer forms an independent channel gating control path, ensuring the determinism of channel gating. The above functional units work together through fixed signal connections, enabling the system to have hardware-autonomous bus hangup detection and fault handling capabilities, thereby effectively solving the problems in the prior art where the bus hangup recovery process affects normal communication and cannot identify the fault source.

[0007] Other features and advantages of this application will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the application. Other advantages of this application can be realized and obtained by means of the embodiments described in the description and the accompanying drawings. Attached Figure Description

[0008] The accompanying drawings are used to provide an understanding of the technical solutions of this application and constitute a part of the specification. They are used together with the embodiments of this application to explain the technical solutions of this application and do not constitute a limitation on the technical solutions of this application.

[0009] Figure 1 This is a schematic diagram of the structure of the IIC bus fault detection system provided in the embodiments of this application; Figure 2 This is a timing diagram of normal IIC communication; Figure 3 A timing diagram for the IIC bus hang state; Figure 4 Another schematic diagram of the IIC bus fault detection system provided in the embodiments of this application; Figure 5 This is a timing diagram illustrating the slave device waiting for the host clock to time out, provided as an embodiment of this application. Detailed Implementation

[0010] This application describes several embodiments, but these descriptions are exemplary and not limiting, and it will be apparent to those skilled in the art that many more embodiments and implementations are possible within the scope of the embodiments described herein. Although many possible combinations of features are shown in the drawings and discussed in the detailed description, many other combinations of the disclosed features are also possible. Unless specifically limited, any feature or element of any embodiment may be used in combination with, or may replace, any feature or element of any other embodiment.

[0011] This application includes and contemplates combinations of features and elements known to those skilled in the art. The embodiments, features, and elements disclosed in this application can also be combined with any conventional features or elements to form unique inventive solutions. Any feature or element of any embodiment can also be combined with features or elements from other inventive solutions to form another unique inventive solution. Therefore, it should be understood that any feature shown and / or discussed in this application can be implemented individually or in any suitable combination. Therefore, the embodiments are not limited except by the limitations imposed by the appended claims and their equivalents. Furthermore, various modifications and changes can be made within the scope of the appended claims.

[0012] Furthermore, in describing representative embodiments, the specification may have presented methods and / or processes as a specific sequence of steps. However, the method or process should not be limited to the specific order of steps described herein, to the extent that it does not depend on such a specific order. As will be understood by those skilled in the art, other sequences of steps are also possible. Therefore, the specific order of steps set forth in the specification should not be construed as a limitation of the claims. Moreover, the claims concerning the method and / or process should not be limited to the steps performed in the written order, and those skilled in the art will readily understand that these orders can be varied and still remain within the spirit and scope of the embodiments of this application.

[0013] This application provides an IIC bus fault detection system, which can be applied to scenarios such as industrial switches, server motherboards, industrial control systems, and communication equipment that require multiple slave devices to be connected via the IIC bus and have high requirements for communication reliability.

[0014] In the aforementioned application scenario, the IIC master controller expands the IIC bus into multiple downstream channels via a multiplexer. Each channel is connected to slave devices such as temperature sensors, EEPROMs (Electrically Erasable Programmable Read-Only Memory), real-time clocks, and optical modules. Factors such as slave device software malfunctions, timing errors, hardware failures, or environmental interference may cause the SCL or SDA signals to be continuously pulled low, resulting in a IIC bus hang. Once this occurs, the IIC master controller cannot communicate with any slave devices via the bus.

[0015] For the aforementioned bus hangup phenomenon, existing methods typically involve the IIC master controller detecting the bus status and performing a recovery operation upon determining a hangup. However, due to the lack of a hardware monitoring path independent of the IIC master controller, the IIC master controller's communication capabilities are limited when the bus hangs up, making it difficult to accurately determine the bus status. Furthermore, the lack of a direct reset control path from an independent hardware unit to each slave device makes it difficult to accurately reset the faulty device during recovery, often affecting normally communicating slave devices as well. Therefore, existing methods easily interrupt normal communication of other healthy slave devices during communication recovery and struggle to accurately identify the fault source, impacting the overall reliability of the system.

[0016] To address the aforementioned problems, embodiments of the present invention improve upon the system structure, which will be described in detail below with reference to specific structures.

[0017] Figure 1 This is a schematic diagram of the structure of the IIC bus fault detection system provided in an embodiment of this application. Figure 1 As shown, the system comprises three functional units: an IIC master controller, a multiplexer, and a CPLD (Complex Programmable Logic Device). These three functional units are connected by fixed signals to form a hardware monitoring and hierarchical recovery control system, which together realizes autonomous hardware detection and handling of IIC bus hang faults.

[0018] Each functional unit will be described below: 1. IIC Main Controller: The IIC master controller is the communication initiation unit of this system. It is used to communicate with each slave device via the IIC bus and to control the channel selection of the multiplexer.

[0019] The IIC master controller has two external interfaces: a signal transmission terminal and a first gating terminal. The signal transmission terminal is fixedly connected to the first terminal of the multiplexer, forming the IIC communication path for transmitting SCL and SDA signals. The first gating terminal is fixedly connected to the second gating terminal of the multiplexer, forming the channel gating control path, used to output a channel gating signal to control the multiplexer to select a specified downstream channel.

[0020] In this embodiment, the IIC master controller initiates IIC communication transactions through the signal transmission terminal to send or read data to the target slave device. When access to a slave device on a specific channel is required, the IIC master controller sends a channel selection signal to the multiplexer through the first selection terminal, causing the multiplexer to connect the signal transmission terminal to the second terminal of the corresponding channel. When no hang-up fault occurs on the IIC bus, the IIC master controller communicates normally with each slave device through the above-mentioned path.

[0021] Example Description: In industrial switch applications, the IIC master controller is configured with the IIC interface built into the main control chip. After the device is powered on, the IIC master controller sequentially selects each channel through the first strobe terminal and polls to read the status data of each slave device through the signal transmission terminal. When it is necessary to read the temperature sensor data on channel 2, the IIC master controller first outputs the corresponding strobe signal for channel 2 through the first strobe terminal, and then initiates the IIC read operation on the temperature sensor through the signal transmission terminal.

[0022] 2. Multiplexer: The multiplexer is the channel expansion and fault isolation unit of this system. It is used to expand a main IIC bus into multiple downstream channels and select one of them according to the channel selection signal.

[0023] The multiplexer has a first terminal, a second strobe terminal, and at least two second terminals. The first terminal is fixedly connected to the signal transmission terminal of the IIC master controller and is used to receive SCL and SDA signals from the IIC master controller. The second strobe terminal is fixedly connected to the first strobe terminal of the IIC master controller and is used to receive channel selection signals. Each second terminal is connected to at least one slave device through a downstream channel.

[0024] In this embodiment, the multiplexer selects a path between the first terminal and one of the second terminals based on the channel selection signal received at the second selection terminal, enabling the IIC master controller to communicate with the slave device on the corresponding channel. At any given time, the first terminal is only connected to one second terminal, while the remaining channels are physically disconnected. When the multiplexer is reset, all downstream channels are disconnected, and there is no connection between the first terminal and any of the second terminals.

[0025] Example Description: In the above industrial switch, the multiplexer is an 8-channel IIC multiplexer with eight second terminals, corresponding to channels 0 through 7. When the second selection terminal receives the selection signal for the corresponding channel 2, the multiplexer connects its first terminal to the second terminal of the corresponding channel 2, allowing the IIC master controller to access the temperature sensor on channel 2. When the multiplexer is reset, all eight channels are disconnected, and the signal transmission terminal of the IIC master controller is only connected to the first terminal of the multiplexer, without connecting to any slave devices.

[0026] 3. CPLD: The CPLD is the core unit for hardware monitoring and fault handling in this system. It is used to monitor the IIC bus status independently of the IIC master controller and perform fault handling operations when a bus hangup is detected.

[0027] The CPLD has a detection terminal. The detection terminal is connected to the connection point between the signal transmission terminal of the IIC master controller and the first terminal of the multiplexer, forming a hardware monitoring path for real-time detection of the SCL and SDA signal levels on the IIC bus.

[0028] In this embodiment, the CPLD continuously acquires the SCL and SDA signals on the IIC bus through its detection terminal. When the SCL or SDA signal is detected to be continuously low for more than a preset duration, the CPLD determines that the IIC bus is in a hangup state and performs fault handling operations. This detection path is physically connected in parallel with the communication path of the IIC master controller, and the CPLD's detection behavior does not affect the IIC bus communication in any way. The CPLD's determination and handling of bus hangup does not depend on the software participation of the IIC master controller; it is completed independently by the CPLD hardware logic.

[0029] Example Description: In the aforementioned industrial switch, the CPLD's detection terminal is connected in parallel to the SCL and SDA lines between the IIC master controller's signal transmission terminal and the first terminal of the multiplexer. During normal communication, the CPLD monitors the SCL and SDA signals, which fluctuate regularly with the communication cycle. When the temperature sensor on channel 2 abnormally pulls the SDA line low for more than 30ms, the CPLD determines that the IIC bus is stuck and immediately initiates fault handling operations.

[0030] To facilitate understanding of the CPLD's detection mechanism for the IIC bus status, this embodiment uses timing diagrams to illustrate the signal characteristics of normal IIC communication and the bus hangup state.

[0031] Figure 2 This is a timing diagram of normal IIC communication. Figure 2As shown, during normal communication, the SCL signal is driven by the IIC master controller, generating periodic clock pulses; the SDA signal varies during the SCL low level and remains stable during the SCL high level. The low-level duration of both the SCL and SDA signals does not exceed one byte transmission time.

[0032] Figure 3 This is a timing diagram illustrating the IIC bus hang state. (Example:) Figure 3 As shown, when a slave device continuously pulls the SDA signal low due to an abnormality, the SDA signal remains at a low level for an extended period and cannot be restored to a high level. The CPLD, through its detection terminal, detects that the SDA signal has remained low for more than a preset duration and determines that the IIC bus is in a suspended state, then initiates fault handling operations.

[0033] The workflow of the above system is explained below: Scenario 1 (Normal Communication Phase): After the device is powered on, the IIC master controller sends a channel selection signal to the multiplexer through the first selection terminal, selecting the channel where the target slave device is located. After the multiplexer connects the first terminal with the corresponding second terminal, the IIC master controller communicates with the target slave device through the signal transmission terminal. During this period, the CPLD continuously monitors the SCL and SDA signal levels through the detection terminal. If the signals toggle normally with the communication cycle, the CPLD determines that the bus is in a normal state and does not perform fault handling operations.

[0034] Scenario 2 (Bus hang occurrence and detection): When a slave device continuously pulls the SCL or SDA signal low due to an abnormality, the IIC bus enters a hangup state, and the IIC master controller cannot continue communication. The CPLD detects the continuous low level of the SCL or SDA signal through the detection terminal. After the low level lasts for more than a preset duration, it determines that the IIC bus is in a hangup state and then initiates fault handling operations.

[0035] Scenario 3 (Troubleshooting): After the CPLD determines that the bus is stuck, it performs a fault handling operation to release the bus from the stuck state and restore communication between the IIC master controller and the slave device.

[0036] The system provided in this embodiment connects the CPLD to the connection point between the IIC master controller's signal transmission terminal and the first terminal of the multiplexer via a detection terminal, forming a hardware monitoring path independent of the IIC master controller. This avoids resource consumption and response delays caused by relying on the master controller's software detection. The channel expansion structure of the multiplexer allows each slave device to be distributed on an independent downstream channel, providing a physical basis for channel-level fault isolation. The direct connection between the first gating terminal of the IIC master controller and the second gating terminal of the multiplexer forms an independent channel gating control path, ensuring the determinism of channel gating. The aforementioned functional units work together through fixed signal connections, enabling the system to possess hardware-autonomous bus hangup detection and fault handling capabilities. This effectively solves the problems in existing technologies where the bus hangup recovery process affects normal communication and fails to identify the fault source.

[0037] In one specific embodiment, based on the system structure described above, a fault recovery mechanism executed by a CPLD in a sequential and hierarchical manner is further provided, aiming to solve the problem that the recovery operation has too large an impact range and cannot accurately locate the fault source in the prior art.

[0038] The core of the fault recovery mechanism in this embodiment lies in proposing a hierarchical, progressive IIC bus fault diagnosis and recovery mechanism. This mechanism utilizes a hardware monitoring and reset control path of the CPLD independent of the IIC master controller. After the CPLD determines that the IIC bus is in a suspended state through the detection terminal, it executes fault handling operations step by step in the order of "interface isolation → bus transaction-assisted recovery → master-slave isolation judgment → fault slave device location and reset". Each level of operation determines whether to proceed to the next level based on the processing result of the previous level, so that the intensity and scope of the recovery operation progresses with the increasing precision of fault location. Ultimately, only the fault source is reset, and the normal communication of non-faulty slave devices remains unaffected. This hierarchical, progressive mechanism overcomes the shortcomings of existing technologies, such as a large impact range of recovery operations and inaccurate fault location.

[0039] Based on the above inventive concept, the system provided in this application embodiment has a CPLD configured to perform fault handling by sequentially executing the following hierarchical recovery operations, specifically including four processing stages: First processing phase (interface isolation): In this processing phase, the CPLD first performs an isolation operation on the interface between itself and the IIC bus to eliminate the possibility that the CPLD itself is the source of the fault.

[0040] Specifically, when the CPLD determines that the IIC bus is in a suspended state via the detection terminal, the CPLD first sets its interface connection with the IIC bus to a high-impedance state to release its own drive of the IIC bus. Then, the CPLD re-detects the SCL and SDA signals via the detection terminal. If both SCL and SDA signals return to a high level, indicating that the bus suspension state has been resolved, the CPLD itself is considered faulty, and the recovery process ends. If the bus suspension state remains unresolved, the fault is determined to be external to the CPLD, and the process enters the second processing stage.

[0041] Example: Consider a slave device connected to channel 2 that continuously pulls the SDA signal low due to an abnormality. After the CPLD detects that SDA is continuously low for more than a preset duration, it determines that the bus is stuck and immediately executes the first processing stage, setting the interface connection between itself and the IIC bus to a high-impedance state. Upon re-detection, the CPLD finds that SDA is still low, determining that the fault is not within the CPLD itself, and then proceeds to the second processing stage.

[0042] Compared to existing technologies that directly reset all devices, the improvement in this processing stage lies in the fact that the CPLD first isolates and verifies its own interface before performing any external recovery operation. This avoids erroneous triggering of external device resets due to CPLD failure, ensuring that subsequent diagnostic operations are based on the premise that the fault source has been eliminated from the CPLD itself. This self-isolation operation provides accurate prerequisites for subsequent hierarchical diagnosis.

[0043] Second processing phase (bus transaction-assisted recovery): After determining that the fault is located outside the CPLD through the first processing stage, this processing stage attempts to assist the slave device in completing the current IIC transaction in a way that minimizes the impact on the bus, so as to restore the bus.

[0044] Specifically, the CPLD determines whether the current hangup state meets the preset slave device clock waiting condition. If it does, the CPLD triggers a bus transaction recovery operation, injecting a clock pulse into the SCL line to enable the currently selected slave device to complete the IIC transaction that failed to complete due to the lack of a clock signal. After the operation is completed, the CPLD checks the SDA signal again through the detection terminal. If SDA returns to a high level, indicating that the bus hangup state is lifted, it is determined that the slave device's clock waiting timeout has occurred, and the recovery process ends. If SDA remains low, it indicates that the slave device is not hangup due to waiting for a clock, and the process enters the third processing stage.

[0045] Exemplary Explanation: Continuing from the previous example, after the CPLD enters the second processing stage, it detects that the current hangup state is SCL high and SDA low, satisfying the preset slave device waiting clock condition. The CPLD injects a preset number of clock pulses onto the SCL line. After the injection is complete, the CPLD detects that SDA is still low, indicating that the RTC on channel 2 is not hangup due to waiting for a clock, and then enters the third processing stage.

[0046] Compared with the existing technology that directly performs a hardware reset after detecting a bus hangup, the improvement of this processing stage is that, before entering the hardware reset, it first attempts to help the slave device complete the current transaction by injecting clock pulses through software assistance. For hangup failures caused by clock delay timeout, recovery can be achieved without performing a hardware reset on any device, thereby minimizing the impact of recovery operations on the system.

[0047] Third processing stage (master-slave isolation judgment): After determining in the second processing stage that the bus hangup was not caused by the slave device waiting for the clock timeout, this processing stage disconnects all downstream channels of the multiplexer to divide the devices on the IIC bus into master and slave sides in order to determine which side the fault source is located on.

[0048] Specifically, the CPLD triggers the disconnection of all downstream channels of the multiplexer, making the first and second terminals of the multiplexer unconnected. At this time, only the IIC master controller and the multiplexer itself are connected to the IIC bus. The CPLD then re-detects the SCL and SDA signals through the detection terminals. If both SCL and SDA signals return to high level, it indicates that the fault source is located on the side of the disconnected channel, and the process enters the fourth processing stage. If the SCL or SDA signal remains low, it indicates that the fault source is located on the master device side, and the system is determined to be a master IIC fault. The CPLD triggers the IIC master controller to perform a reset operation on its IIC interface communicating with the multiplexer, and then the recovery process ends.

[0049] Example Description: Continuing from the previous example, after the CPLD enters the third processing stage, it triggers the multiplexer to disconnect all eight downstream channels. At this time, the RTC on channel 2 is physically disconnected from the bus. The CPLD detects that both the SCL and SDA signals have returned to high level through the detection terminal, determines that the fault source is located on the channel side, and then enters the fourth processing stage.

[0050] Compared with existing technologies that cannot distinguish between master device faults and slave device faults, the improvement of this processing stage is that by physically disconnecting all downstream channels of the multiplexer, a clear isolation boundary is established between the master device side and the slave device side, and the fault source is determined based on the isolated bus status, providing a clear direction for subsequent channel-level precise location and avoiding erroneous recovery operations caused by the inability to distinguish the fault side.

[0051] Fourth stage of troubleshooting (fault location and reset from equipment): After determining that the fault source is located in the slave device on the channel side through the third processing stage, this processing stage uses the current strobe channel information previously acquired and saved by the CPLD to identify the faulty slave device and perform a reset operation on it.

[0052] Specifically, based on the current strobe channel information acquired and saved before the bus hangup occurred, the CPLD determines the strobe channel and the slave device on that channel at the time of the bus hangup, and identifies the slave device as a faulty slave device. Subsequently, the CPLD triggers a reset operation on the faulty slave device to restore its normal function.

[0053] Example Description: Continuing from the previous example, after the CPLD enters the fourth processing stage, it determines, based on the previously saved strobe channel information, that channel 2 was selected when the bus hangup occurred, and the RTC on this channel is the faulty slave device. The CPLD then triggers a reset operation on this RTC. After the reset is completed, the bus hangup state is released, and the IIC master controller resumes communication with the RTC on channel 2.

[0054] Compared with existing technologies that require checking each slave device individually or resetting all slave devices after determining that the fault is located on the slave device side, the improvement of this processing stage is that it directly locates the specific faulty slave device by using the strobe channel information stored in advance by the CPLD, and performs a reset operation only on that slave device, thus reducing the impact of the recovery operation to a single faulty slave device. Slave devices on other channels maintain normal communication unaffected during the recovery process, achieving precise channel-level fault isolation and recovery.

[0055] This embodiment employs a hierarchical, progressive IIC bus fault diagnosis and recovery mechanism. The first processing stage, interface isolation, eliminates interference from CPLD self-faults, providing accurate preconditions and preventing erroneous resets due to CPLD failures. The second processing stage, bus transaction-assisted recovery, prioritizes non-destructive recovery methods, avoiding unnecessary hardware resets and minimizing the impact of recovery operations on the system. The third processing stage, master-slave isolation, distinguishes the faulty side by physically disconnecting multiplexer channels, providing a clear direction for precise fault location and preventing erroneous operations due to the inability to distinguish the faulty side. The fourth processing stage, fault slave device location and reset, directly locates the faulty slave device using pre-saved strobe channel information, narrowing the impact of the recovery operation to a single slave device and achieving precise channel-level fault isolation. These four processing stages proceed sequentially and synergistically, causing the intensity and impact of the recovery operation to converge progressively with increasing accuracy in fault location. This effectively solves the problem of excessively large impact range and inaccurate fault source location in existing technologies.

[0056] Figure 4 Another structural schematic diagram of the IIC bus fault detection system provided in this application embodiment is shown below. Figure 4 The implementation method of each processing stage is explained.

[0057] Based on the first processing stage described above, this embodiment further defines the specific implementation structure of the CPLD execution interface isolation operation.

[0058] The CPLD has an isolation pin that connects to the SCL and SDA lines of the IIC bus. This isolation pin is the physical interface pin between the CPLD and the IIC bus; the CPLD accesses the IIC bus through this isolation pin to drive or release the SCL and SDA signals. In an alternative embodiment, this isolation pin can be integrated with the detection pin.

[0059] In the first processing stage, the CPLD is configured to control the isolation terminal to output a high-impedance state, so that its connection with the IIC bus is in a high-impedance state. The high-impedance state is equivalent in circuit characteristics to a physical disconnection between the CPLD and the IIC bus; the CPLD no longer exerts any drive or pull-down effect on the SCL and SDA lines. Through this operation, the CPLD electrically releases itself from driving the IIC bus, thereby eliminating the possibility of the CPLD itself acting as a source of bus hang-up faults. After the isolation terminal outputs a high-impedance state, the CPLD can still independently monitor the level of the SCL and SDA signals through the detection terminal to determine whether the bus hang-up has been resolved.

[0060] Example Description: Taking an industrial switch IIC bus management system as an example, the CPLD uses the Anlu EF3L15CG256B chip. The CPLD internally includes a slave IIC interface module, which is used to realize IIC communication between the CPLD and the IIC master controller. The signal pins of the slave IIC interface module correspond to the isolation terminals of the CPLD, and the isolation terminals are connected to the SCL and SDA lines of the IIC bus.

[0061] When the CPLD detects that the SDA signal has been continuously low for more than 30ms, it determines that the IIC bus is hanged and enters the first processing stage. The CPLD controls the isolation terminal to output a high-impedance state. Specifically, the CPLD resets and restarts the slave IIC interface module through internal logic, causing the module's output driver to enter a high-impedance state. At this time, the slave IIC interface module is electrically equivalent to being disconnected from the SCL and SDA lines, and the CPLD no longer generates any drive on the bus.

[0062] From the perspective of the CPLD's internal logic implementation, this working mechanism can be achieved through level detection and reset control logic. The CPLD has internal bus monitoring logic that samples the SCL and SDA signals at a fixed sampling period (e.g., 400μs). When both SCL and SDA are detected to be high, the bus monitoring logic determines that the bus is idle and resets the internal counter and fault flag. When SCL or SDA is detected to be low, the counter begins to accumulate. When the count value reaches a preset threshold (e.g., 75 sampling periods, corresponding to 30ms), the bus monitoring logic determines that the bus is hung and outputs a bus hang flag signal. In the first processing stage, the CPLD's internal logic responds to this hang flag signal, generating a reset enable signal for the slave IIC interface module, resetting the module to a high-impedance output state, thereby electrically isolating the CPLD from the IIC bus. The reset signal is released after a preset duration (e.g., 1.2ms, corresponding to 3 sampling periods) to ensure the reset operation is complete.

[0063] After the operation is completed, the CPLD re-detects the SCL and SDA signals via the detection terminal. If both SCL and SDA return to high level, it indicates that the previous bus hang was caused by an abnormal low-level pull of the bus by the CPLD's own slave IIC interface module, which is determined to be a CPLD fault, and the recovery process ends. If SCL or SDA remains low, it indicates that the fault source is outside the CPLD, and the CPLD continues to the second processing stage.

[0064] Compared to existing technologies where the CPLD maintains normal connection with the bus during fault handling, the improvement of this structure lies in the fact that the CPLD has an independently controlled isolation terminal, which can actively set its interface with the IIC bus to a high-impedance state during the first processing stage. Before performing any recovery operation on external devices, the CPLD itself is electrically isolated from the bus, ensuring that the CPLD itself is not the source of the bus hang, providing accurate preconditions for subsequent hierarchical diagnosis, and avoiding erroneous resets of external devices due to its own fault.

[0065] In one specific embodiment, based on the second processing stage described above, this embodiment further defines the specific implementation structure of the CPLD triggering bus transaction recovery operation.

[0066] The CPLD has a clock output pin, which is connected to the SCL line of the IIC bus. The clock output pin is a dedicated pin used by the CPLD to output clock pulse signals to the SCL line. Through this pin, the CPLD can independently inject clock signals into the IIC bus without relying on the IIC master controller.

[0067] In the second processing stage, the CPLD is configured to: if the current hangup state is that the SCL signal is high and the SDA signal is low, inject a preset number of clock pulses on the SCL line through the clock output terminal so that the currently selected slave device completes the unfinished IIC transaction.

[0068] The state where the SCL signal is high and the SDA signal is low indicates that the slave device is waiting for the IIC master controller to send a clock signal by pulling the SDA signal low, but the bus is stalled because the IIC master controller stops sending the clock. The CPLD injects a clock pulse through the clock output terminal to simulate the clock behavior of the IIC master controller, enabling the slave device to obtain the required clock edge, complete the transmission of the current data byte, and release the SDA line at the acknowledgment time. If SDA returns to a high level after the pulse is injected, it means that the slave device has successfully completed the unfinished transaction, and the bus hang is released. If SDA remains low, it means that the abnormality of the slave device is not caused by clock waiting, and further processing is required for more in-depth fault diagnosis.

[0069] Figure 5 This is a timing diagram illustrating the slave device waiting for the master clock to time out, as provided in an embodiment of this application. In this state, the SCL signal is high and the SDA signal is low, indicating that the slave device is waiting for the IIC master controller to send a clock signal by pulling the SDA signal low. After the CPLD detects this state, it injects a preset number of clock pulses onto the SCL line through the clock output terminal. Figure 5As shown, after the clock pulse is injected, the slave device releases the SDA line at the acknowledgment time, the SDA signal returns to a high level, and the bus hang-up state is released.

[0070] Example Description: Continuing from the aforementioned example of the industrial switch IIC bus management system. After completing the self-isolation operation in the first processing stage, the CPLD confirms that the fault is not within the CPLD itself and enters the second processing stage. The CPLD detects that the current SCL signal is high and the SDA signal is low, satisfying the preset slave device wait clock condition.

[0071] The CPLD internally includes a pulse generator module, which generates clock pulse signals on the SCL line. The signal output pin of the pulse generator module corresponds to the clock output of the CPLD, which is connected to the SCL line. When the CPLD detects that the SCL signal is high and the SDA signal is low, the internal logic triggers the pulse generator module, outputting a preset number of clock pulses on the SCL line through the clock output. The pulse frequency matches the IIC bus operating frequency, ensuring that slave devices can correctly identify the clock signal. The preset number can be configured according to actual needs, for example, it can be configured to 16 pulses.

[0072] From the perspective of the CPLD's internal logic implementation, after receiving a trigger signal, the pulse generator module toggles the output level on the SCL line at the same rate as the IIC bus operating frequency, generating clock pulses. Each toggle counts once; when the count reaches a preset value, the pulse generator module stops outputting, and the clock output returns to a high-impedance state. Taking this industrial switch as an example, the IIC bus operating frequency is 100kHz. The pulse generator module inside the CPLD toggles the level with a period of 400μs, injecting 16 clock pulses at a frequency of 100kHz onto the SCL line, with a total time of approximately 6.4ms. This pulse injection operation is entirely executed by the CPLD hardware logic, without the need for software intervention from the IIC master controller.

[0073] After injection, the CPLD checks the SDA signal again via the detection terminal. If SDA returns to a high level, it indicates that the slave device has timed out while waiting for the clock, and the bus recovery is successful. If SDA remains low, it means that the RTC on channel 2 is not stuck due to waiting for the clock, and the CPLD continues to the third processing stage.

[0074] Compared to existing technologies where the IIC master controller transmits clock pulses on the SCL line via software, the improvement of this structure lies in setting a dedicated clock output terminal on the CPLD, allowing the CPLD hardware logic to independently inject the clock pulses. Clock pulse injection does not rely on the software participation of the IIC master controller. Even when the IIC master controller's communication capabilities are limited during bus hangs, the bus recovery auxiliary operation can still be completed promptly through the CPLD hardware path, achieving zero CPU usage and millisecond-level response. Furthermore, placing this clock pulse injection operation as a second processing stage after the self-isolation operation and before the hardware reset operation prioritizes recovery in a way that minimizes system impact. Only when clock-assisted recovery fails does the subsequent hardware reset stage commence, reflecting a hierarchical and progressive recovery strategy.

[0075] In one specific embodiment, based on the third processing stage described above, this embodiment further defines the specific implementation structure for CPLD triggering the disconnection of all downstream channels of the multiplexer.

[0076] The multiplexer has a first reset terminal, and the CPLD has a first control terminal, which is connected to the first reset terminal. The first control terminal is a dedicated pin used by the CPLD to output a reset control signal to the multiplexer, while the first reset terminal is an input pin used by the multiplexer to receive external reset signals. Through this connection, the CPLD can independently control the hardware reset of the multiplexer from the IIC master controller.

[0077] In the third processing stage, the CPLD is configured to send a reset signal to the multiplexer via the first control terminal to reset the multiplexer, causing it to disconnect all downstream channels. After the multiplexer is reset, all paths between its first terminal and each of its second terminals are disconnected. Only the IIC master controller and the multiplexer itself are connected to the IIC bus, and all slave devices are physically isolated from the master bus. The CPLD then re-detects the SCL and SDA signal levels via its detection terminal: if both SCL and SDA return to high levels, the fault source is located in the slave device on the disconnected channel side; if SCL or SDA remains low, the fault source is located on the master device side, i.e., the IIC master controller itself is faulty. Through this operation, the CPLD establishes a clear electrical isolation boundary between the master and slave device sides and determines the location of the fault source based on the isolated bus status.

[0078] Example illustration: Continuing from the aforementioned example of the industrial switch IIC bus management system. After the CPLD completes the clock pulse injection operation in the second processing stage, SDA remains low, indicating that the slave device is not hanging due to waiting for the clock, and the CPLD enters the third processing stage.

[0079] The multiplexer uses the Naxin Microelectronics NCA9548 chip, which has a reset pin as the first reset terminal. The CPLD uses the Anlu EF3L15CG256B chip, which has one GPIO (General Purpose Input / Output) pin as the first control terminal, which is connected to the reset pin of the NCA9548.

[0080] The CPLD internally includes an interrupt and reset control module, which generates reset control signals for external devices. If the bus hang-up is not lifted in either the first or second processing stage, the CPLD's internal logic triggers the interrupt and reset control module, sending a reset signal to the multiplexer's first reset terminal via the first control terminal.

[0081] From the perspective of the CPLD's internal logic implementation, after receiving the trigger signal, the interrupt and reset control module pulls the output level of the first control terminal low and maintains it for a preset duration (e.g., 1ms), sending a low-level active reset signal to the multiplexer. Upon receiving the reset signal, the multiplexer's internal logic executes a reset operation, disconnecting the path between the first terminal and all second terminals. After the reset signal is released, the multiplexer remains in a state where all channels are disconnected.

[0082] After the reset operation is completed, the CPLD re-detects the SCL and SDA signals via the detection terminal. If both SCL and SDA return to high level, the fault source is determined to be located on the channel-side slave device, and the process proceeds to the fourth processing stage. If SCL or SDA remains low, the fault is determined to be a master IIC fault, and the CPLD continues to execute the reset operation on the IIC master controller. Taking the RTC on channel 2 as the fault source in this example, after resetting the multiplexer, since the RTC is physically disconnected from the bus, both SCL and SDA return to high level, and the CPLD determines that the fault source is on the channel side.

[0083] Compared to existing technologies where the IIC master controller resets the multiplexer via software or directly resets the entire IIC bus, the improvement of this structure lies in setting a dedicated first control terminal on the CPLD, directly connected to the first reset terminal of the multiplexer. The CPLD hardware logic independently completes the reset control of the multiplexer. The multiplexer reset operation does not rely on the software participation of the IIC master controller. Even when the IIC master controller's communication capability is limited during bus hangs, the channel disconnection operation can still be completed in a timely manner through the CPLD hardware path. Furthermore, placing the multiplexer reset operation as the third processing stage after clock-assisted recovery aims not only to perform recovery but, more importantly, to establish a master-slave isolation boundary by disconnecting the channel, enabling accurate identification of the fault source and providing a clear direction for subsequent precise channel-level localization.

[0084] In one specific embodiment, based on the third processing stage described above, this embodiment further defines the specific implementation structure of the CPLD triggering the IIC master controller to perform a reset operation on its IIC interface communicating with the multiplexer.

[0085] The IIC master controller has a reset control pin, and the CPLD has a host reset pin, which is connected to the reset pin of the IIC master controller. The host reset pin is a dedicated pin used by the CPLD to output a reset control signal to the IIC master controller, while the IIC master controller's reset control pin is an input pin used to receive external reset signals. Through this connection, the CPLD can operate independently of the IIC master controller's software and directly perform hardware reset control on the IIC interface circuit of the IIC master controller.

[0086] In the third processing stage, after the CPLD resets the multiplexer and disconnects all downstream channels via the first control terminal, if the SCL or SDA signal is still low at the detection terminal, it is determined to be a host IIC fault. At this time, the CPLD is configured to send a reset signal to the IIC master controller via the host reset terminal to reset the IIC interface circuit for communication between the IIC master controller and the multiplexer.

[0087] When all downstream channels of the multiplexer are disconnected, only the IIC master controller and the multiplexer itself are connected to the IIC bus, and all slave devices are physically isolated. If the bus is still pulled low at this time, the fault can be identified as a malfunction in the IIC interface circuit of the IIC master controller itself. The CPLD sends a reset signal to the IIC master controller through the host reset pin, resetting only its IIC interface circuit and not resetting other functional modules of the IIC master controller, thereby minimizing the impact on the system while troubleshooting.

[0088] Example illustration: Continuing from the aforementioned example of the industrial switch IIC bus management system. After the CPLD resets the multiplexer through the first control terminal in the third processing stage, if the detection terminal detects that SCL or SDA is still low, it determines that the host IIC is faulty.

[0089] The IIC master controller uses the IIC interface integrated within the Nanfei NF5180 switching chip. This chip has a reset pin as the reset terminal of the IIC master controller. The CPLD uses the Anlu EF3L15CG256B chip, one of which has a GPIO pin as the host reset terminal, which is connected to the corresponding reset pin of the NF5180.

[0090] The CPLD internally includes an interrupt and reset control module. This module generates reset control signals for the multiplexer and also for the IIC master controller. When the CPLD determines a host IIC fault, its internal logic triggers the interrupt and reset control module, sending a reset signal to the IIC master controller via the host reset pin.

[0091] From the perspective of the CPLD's internal logic implementation, after receiving the trigger signal, the interrupt and reset control module pulls the output level of the host reset terminal low and maintains it for a preset duration (e.g., 1ms), sending a low-level active reset signal to the IIC master controller. Upon receiving the reset signal, the IIC master controller's IIC interface circuit is reset, the state machine returns to its initial state, and the output driver releases its drive on the SCL and SDA lines. After the reset signal is released, the IIC interface circuit of the IIC master controller re-enters normal operation, while other functional modules of the IIC master controller (such as network processing and business logic) are unaffected by this reset operation.

[0092] After the reset operation is completed, the CPLD checks the SCL and SDA signals again through the detection terminal to confirm whether the bus hang-up state has been released, and the recovery process ends.

[0093] Compared to existing technologies that use a hardware watchdog to reset the entire IIC master controller or all slave devices, the improvement of this structure lies in setting a dedicated master reset terminal on the CPLD, which is directly connected to the reset terminal of the IIC master controller. Furthermore, the reset scope is limited to the IIC interface circuit where the IIC master controller communicates with the multiplexer, without affecting other functional modules of the IIC master controller. After the multiplexer disconnects all downstream channels and the fault source is confirmed on the master device side, only the faulty circuit is precisely reset. Other functions of the IIC master controller continue to operate normally during the reset, achieving finer reset granularity and minimizing the impact range.

[0094] In an optional embodiment, for the third processing stage, a mechanism is further defined in which the CPLD re-detects the bus status to verify whether the reset was successful after sending a reset signal to the IIC master controller.

[0095] In the third processing stage, after the CPLD sends a reset signal to the IIC master controller through the host reset terminal, the CPLD is configured to detect the SCL and SDA signals again through the detection terminal to determine whether the reset operation has successfully released the bus hang-up state.

[0096] If both SCL and SDA signals are high, it indicates that the IIC interface circuit of the IIC master controller has been successfully reset, its output driver has released its drive on the bus, the bus hang-up state has been released, the CPLD determines that the master IIC has been successfully restored and ends the recovery process.

[0097] If the SCL or SDA signal remains low, it indicates that the bus hang has not been lifted even after a reset operation has been performed on the IIC interface circuit of the IIC master controller. In this case, the CPLD determines that the host IIC is permanently faulty, meaning that the IIC interface circuit of the IIC master controller has hardware damage that cannot be recovered by a conventional reset.

[0098] This verification mechanism constitutes a closed-loop diagnosis in the third processing stage: after a reset operation, the objective bus status must be obtained through the detection terminal to verify the reset effect, rather than assuming the fault has been eliminated simply because the reset operation has been completed. If the reset is ineffective, the permanent fault handling process will begin.

[0099] Example illustration: Continuing from the aforementioned example of the industrial switch IIC bus management system. In the third processing stage, the CPLD sends a reset signal to the IIC master controller (the IIC interface of the Nanfei NF5180 switching chip) through the host reset terminal. The reset signal is released after 1ms.

[0100] After the reset signal is released, the CPLD detects the SCL and SDA signals again through the detection terminal. At this point, two possible scenarios exist: Scenario 1: Both SCL and SDA signals return to high level. The CPLD determines that the host IIC recovery was successful, the bus hang-up state has been released, and the recovery process ends. The IIC interface circuit of the IIC master controller resumes normal operation and can restart communication.

[0101] Scenario 2: The SCL or SDA signal remains low. The CPLD determines a permanent IIC fault in the host computer, records the fault information, and then initiates the corresponding permanent fault handling mechanism.

[0102] From the perspective of the CPLD's internal logic implementation, after outputting the reset signal to the host reset terminal, the CPLD starts a detection window. Within this window, the SCL and SDA signals are sampled multiple times through the detection terminal. If both the SCL and SDA signals remain high within this window, a successful recovery flag is output. If either the SCL or SDA signal goes low within this window, a permanent fault flag is output, and the fault type and fault information are recorded in an internal register for later retrieval.

[0103] Compared to existing technologies where reset operations only indicate "reset performed" without verifying the reset effect, this mechanism improves upon the fact that after sending the reset signal, the CPLD re-acquires the bus status through the detection terminal, using the objective bus level status as the basis for determining whether the reset was successful. This reset operation forms a closed loop of "reset execution → status detection → result determination," preventing the system from mistakenly believing the fault has been resolved and continuing operation when the reset operation is ineffective, thus avoiding the recurrence of the same fault and improving system reliability. Furthermore, by distinguishing between "successful recovery" and "permanent fault," it provides accurate decision-making basis for subsequent permanent fault handling.

[0104] In another optional embodiment, for the third processing stage, a mechanism for recording fault information and continuously resetting the IIC master controller is further defined, after the CPLD determines that the host IIC has a permanent fault.

[0105] In the third processing stage, after the CPLD re-detects the SCL and SDA signals via the detection terminal, if either the SCL or SDA signal remains low, the CPLD determines that the host IIC has a permanent fault. At this time, the CPLD is configured to record the host IIC permanent fault information and continuously send a reset signal to the IIC master controller via the host reset terminal.

[0106] The purpose of recording permanent IIC fault information is to save the type and occurrence of this permanent fault to the CPLD internal register so that the IIC master controller can read the information after communication is restored, providing data basis for system maintenance and fault analysis.

[0107] The purpose of continuously sending a reset signal to the IIC master controller via the host reset pin is to keep the IIC interface circuit in a reset state when there is an unrecoverable hardware fault in the IIC master controller's IIC interface circuit, preventing the abnormal state from causing continuous interference to the IIC bus and other devices. Simultaneously, the continuous reset signal keeps the IIC interface circuit of the IIC master controller in a deterministic initial state, providing a stable prerequisite for subsequent system maintenance or replacement.

[0108] Example illustration: Continuing from the aforementioned example of the industrial switch IIC bus management system. After the CPLD sends a reset signal to the IIC master controller via the host reset terminal in the third processing stage, it re-detects the SCL and SDA signals via the detection terminal and finds that SCL is still at a low level. Based on this, the CPLD determines that the host IIC has a permanent fault.

[0109] The CPLD contains a fault logging module that records fault information generated during the graded recovery process. When the CPLD determines a permanent IIC fault in the host system, the fault logging module writes the permanent fault information to an internal register. This information may include a fault type identifier (permanent IIC fault in the host system) and a timestamp or sequence number of the fault occurrence. The fault logging register maintained internally by the CPLD can be read by the IIC master controller via the IIC interface after communication is restored.

[0110] Meanwhile, the interrupt and reset control module inside the CPLD keeps the output level of the host reset terminal in a valid state (low level), continuously sending a reset signal to the IIC master controller. This continuous reset signal keeps the IIC interface circuit of the IIC master controller in a reset state until the system takes further action (such as a complete system restart or hardware replacement).

[0111] Example illustration: Fault log register mapping maintained by CPLD. Register 0x82 records the most recent bus hang cause; when a permanent host IIC failure occurs, this register is written with the corresponding fault type code. Registers 0x80 and 0x81 form a fault counter, recording the cumulative number of faults. These register contents can be read via the IIC interface, providing data support for maintenance personnel to analyze system fault modes and formulate maintenance strategies.

[0112] Compared to existing technologies that simply retry or abandon the process after a reset failure, this mechanism improves upon the fact that the CPLD performs two parallel processing actions—"recording fault information" and "continuous reset"—after determining a permanent fault in the host IIC. Recording fault information provides traceable diagnostic data for system maintenance, preventing the loss of fault information and supporting subsequent fault mode analysis and predictive maintenance. Continuous reset keeps the faulty circuit in a deterministic reset state, preventing its abnormal state from causing intermittent interference to the bus and other devices. The combined effect of these two actions enables the system to maintain a deterministic fault state and retain complete fault records even when facing unrecoverable hardware failures, providing a reliable basis for fault diagnosis and system recovery.

[0113] In one specific embodiment, based on the fourth processing stage described above, this embodiment further defines the specific implementation structure of the CPLD triggering the reset operation of the faulty slave device.

[0114] Each slave device has a second reset pin, and the CPLD has multiple third control pins, each connected one-to-one with the second reset pin of a slave device. The third control pins are dedicated pins used by the CPLD to independently output reset control signals to each slave device, while the second reset pins are input pins used by the slave devices to receive external reset signals. Through this one-to-one connection, the CPLD can perform independent hardware reset control on each slave device without affecting the normal operation of other slave devices.

[0115] In the fourth processing stage, for cases where a channel-side slave device has been identified as faulty in the third processing stage, the CPLD determines the channel where the faulty slave device is located based on the previously acquired and saved current strobed channel information. Subsequently, the CPLD is configured to send a hardware reset signal to the faulty slave device via a third control terminal corresponding to the channel where the faulty slave device is located.

[0116] Since each third control terminal of the CPLD is connected to a corresponding second reset terminal of a slave device, the CPLD can selectively send a reset signal only to the faulty slave device based on the fault location result. Slave devices on other channels are unaffected by this reset operation. The reset signal is released after a preset duration, and the slave device restarts and returns to its initial state. After the reset is complete, the bus hang state is released, and the IIC master controller resumes communication with the slave device.

[0117] Example Description: Continuing from the aforementioned example of the industrial switch IIC bus management system. In the third processing stage, the CPLD resets the multiplexer and detects the bus status to determine that the fault source is located in the slave device on the channel side. The CPLD enters the fourth processing stage, and based on the previously saved strobe channel information, determines that the channel selected when the bus hangup occurred is channel 2, and the RTC (AiP8563SA.TB) on this channel is the faulty slave device.

[0118] In this industrial switch system, each slave device has an independent reset pin as a second reset terminal. Taking the RTC on channel 2 as an example, the reset pin of this chip is the second reset terminal. The CPLD uses the Anlu EF3L15CG256B chip, whose multiple GPIO pins serve as third control terminals, each of which is connected one-to-one with the second reset terminal of a slave device. The third control terminal corresponding to channel 2 is connected to the reset pin of the RTC.

[0119] The CPLD contains an interrupt and reset control module, which generates independent reset control signals for each slave device. When the CPLD determines that the faulty slave device is the RTC on channel 2, its internal logic triggers the interrupt and reset control module, which sends a hardware reset signal to the RTC through the third control terminal corresponding to channel 2.

[0120] From the perspective of the CPLD's internal logic implementation, after receiving a trigger signal, the interrupt and reset control module pulls the output level of the corresponding third control terminal low and maintains it for a preset duration (e.g., 1ms), sending a low-level active hardware reset signal to the slave device. Upon receiving the reset signal, the slave device's internal logic performs a reset operation, its IIC interface circuit returns to its initial state, and the abnormal drive on the SCL and SDA lines is released. After the reset signal is released, the slave device completes internal initialization after a preset startup time (e.g., 5ms) and returns to normal operating status.

[0121] After the reset operation is completed, the bus hang-up state is released. At this time, the slave devices on the remaining 7 channels (such as the EEPROM on channel 0, the temperature sensor on channel 1, and the SFP optical modules on channels 3 to 7) maintain normal communication without being affected throughout the recovery process.

[0122] Compared to existing technologies that require individual troubleshooting or unified reset of all slave devices after determining the fault is on the slave device side, the improvement of this structure lies in setting multiple third control terminals on the CPLD, each corresponding to a second reset terminal of each slave device. The CPLD directly locates the faulty slave device based on pre-saved gating channel information and performs an independent reset only on that slave device. This reduces the impact of the recovery operation to a single faulty slave device, while slave devices on other channels maintain normal communication unaffected throughout the recovery process, achieving precise channel-level fault isolation and recovery, and minimizing the impact of the fault to a single channel. Furthermore, this reset operation is independently completed by the CPLD hardware logic, without the need for software intervention from the IIC master controller, achieving zero CPU usage and millisecond-level response.

[0123] In one specific embodiment, based on the fourth processing stage described above, this embodiment further defines the specific implementation structure of the CPLD triggering the reset operation of the faulty slave device.

[0124] Each slave device has a second reset pin, and the CPLD has multiple third control pins, each connected one-to-one with the second reset pin of a slave device. The third control pins are dedicated pins used by the CPLD to independently output reset control signals to each slave device, while the second reset pins are input pins used by the slave devices to receive external reset signals. Through this one-to-one connection, the CPLD can perform independent hardware reset control on each slave device without affecting the normal operation of other slave devices.

[0125] In the fourth processing stage, for cases where a channel-side slave device has been identified as faulty in the third processing stage, the CPLD determines the channel where the faulty slave device is located based on the previously acquired and saved current strobed channel information. Subsequently, the CPLD is configured to send a hardware reset signal to the faulty slave device via a third control terminal corresponding to the channel where the faulty slave device is located.

[0126] Since each third control terminal of the CPLD is connected to a corresponding second reset terminal of a slave device, the CPLD can selectively send a reset signal only to the faulty slave device based on the fault location result. Slave devices on other channels are unaffected by this reset operation. The reset signal is released after a preset duration, and the slave device restarts and returns to its initial state. After the reset is complete, the bus hang state is released, and the IIC master controller resumes communication with the slave device.

[0127] Example Description: Continuing from the aforementioned example of the industrial switch IIC bus management system. In the third processing stage, the CPLD resets the multiplexer and detects the bus status to determine that the fault source is located in the slave device on the channel side. The CPLD enters the fourth processing stage, and based on the previously saved strobe channel information, determines that the channel selected when the bus hangup occurred is channel 2, and the RTC (AiP8563SA.TB) on this channel is the faulty slave device.

[0128] In this industrial switch system, each slave device has an independent reset pin as a second reset terminal. Taking the RTC on channel 2 as an example, the reset pin of this chip is the second reset terminal. The CPLD uses the Anlu EF3L15CG256B chip, whose multiple GPIO pins serve as third control terminals, each of which is connected one-to-one with the second reset terminal of a slave device. The third control terminal corresponding to channel 2 is connected to the reset pin of the RTC.

[0129] The CPLD contains an interrupt and reset control module, which generates independent reset control signals for each slave device. When the CPLD determines that the faulty slave device is the RTC on channel 2, its internal logic triggers the interrupt and reset control module, which sends a hardware reset signal to the RTC through the third control terminal corresponding to channel 2.

[0130] From the perspective of the CPLD's internal logic implementation, after receiving a trigger signal, the interrupt and reset control module pulls the output level of the corresponding third control terminal low and maintains it for a preset duration (e.g., 1ms), sending a low-level active hardware reset signal to the slave device. Upon receiving the reset signal, the slave device's internal logic performs a reset operation, its IIC interface circuit returns to its initial state, and the abnormal drive on the SCL and SDA lines is released. After the reset signal is released, the slave device completes internal initialization after a preset startup time (e.g., 5ms) and returns to normal operating status.

[0131] After the reset operation is completed, the bus hang-up state is released. At this time, the slave devices on the remaining 7 channels (such as the EEPROM on channel 0, the temperature sensor on channel 1, and the SFP optical modules on channels 3 to 7) maintain normal communication without being affected throughout the recovery process.

[0132] Compared to existing technologies that require individual troubleshooting or unified reset of all slave devices after determining the fault is on the slave device side, the improvement of this structure lies in setting multiple third control terminals on the CPLD, each corresponding to a second reset terminal of each slave device. The CPLD directly locates the faulty slave device based on pre-saved gating channel information and performs an independent reset only on that slave device. This reduces the impact of the recovery operation to a single faulty slave device, while slave devices on other channels maintain normal communication unaffected throughout the recovery process, achieving precise channel-level fault isolation and recovery. Furthermore, this reset operation is completed independently by the CPLD hardware logic, without the need for software intervention from the IIC master controller, achieving zero CPU usage and millisecond-level response.

[0133] In one specific embodiment, based on the fourth processing stage described above, this embodiment further defines the specific implementation structure for the CPLD to acquire and save the current selected channel information of the multiplexer.

[0134] The CPLD also has a data acquisition terminal, which connects to the junction between the first and second strobe terminals. The first strobe terminal is the interface used by the IIC master controller to output channel strobe signals, and the second strobe terminal is the interface used by the multiplexer to receive channel strobe signals. The CPLD's data acquisition terminal, connected to the junction between these two interfaces, allows direct acquisition of the channel strobe signals sent by the IIC master controller to the multiplexer without interfering with normal communication between the IIC master controller and the multiplexer.

[0135] During normal system operation, the IIC master controller sends a channel selection signal to the multiplexer through the first selection terminal to control the multiplexer to select the specified downstream channel. The CPLD directly acquires the channel selection signal from the connection point between the first and second selection terminals through the acquisition terminal and saves the currently selected channel information.

[0136] When the IIC bus hangs and enters the fourth processing stage, the CPLD is configured to determine the channel where the faulty slave device is located based on the current strobe channel information. Since the CPLD stores the channel information corresponding to the last channel strobe operation before the bus hangs, this information accurately reflects the channel that was strobe at the time of the bus hang. The CPLD can then directly locate the slave device on that channel as the faulty slave device.

[0137] The channel selection information acquisition path is independent of the SCL and SDA communication paths of the IIC bus. The process of the CPLD acquiring the selection signal through the acquisition terminal does not pass through the IIC bus, and therefore is not affected by the bus being suspended. Even during the bus suspension period, the CPLD can still accurately acquire and save the channel selection information through this path.

[0138] Example Description: Continuing from the aforementioned example of an industrial switch IIC bus management system. In this system, the first strobe terminal of the IIC master controller (Nanfei NF5180 switching chip) is connected to the second strobe terminal of the multiplexer (Nanochip NCA9548), and the two transmit channel strobe commands via the IIC bus. The acquisition terminal of the CPLD (Anlu EF3L15CG256B) is connected to this connection point.

[0139] During normal system operation, before accessing slave devices on different channels, the IIC master controller first sends a channel selection signal to the multiplexer via the first selection terminal. For example, when the IIC master controller needs to read the RTC on channel 2, it first sends the corresponding channel 2 selection signal. The CPLD synchronously acquires this selection signal through the acquisition terminal and saves it to its internal register, recording that the currently selected channel is channel 2.

[0140] When the RTC on channel 2 causes the bus to hang due to an abnormal, continuous low SDA signal, the CPLD, after diagnostics in the first to third processing stages, determines that the fault source is located in the slave device on the channel side. Upon entering the fourth processing stage, the CPLD reads the currently selected channel information stored in its internal registers, confirming that channel 2 was selected when the bus hang occurred, thus identifying the RTC on that channel as the faulty slave device.

[0141] From the perspective of the CPLD's internal logic implementation, the CPLD continuously monitors the signal status at the connection point between the first and second strobe terminals through the acquisition end. When a change in the channel strobe signal is detected, the CPLD updates the current strobe channel information stored in its internal register. This register retains its original data during bus hangup until the CPLD detects a new change in the channel strobe signal. Therefore, when a bus hangup occurs, the CPLD's internal register stores the channel information corresponding to the communication that caused the hangup.

[0142] Compared to existing technologies where the IIC master controller records the last channel selection information via software, the improvement of this structure lies in setting up a dedicated acquisition terminal on the CPLD, directly connected to the connection point between the first and second selection terminals. The CPLD hardware logic independently completes the acquisition and storage of the channel selection signal. The acquisition of channel selection information does not depend on the software recording of the IIC master controller. Even when the IIC master controller's communication capabilities are limited and it cannot read its own records during bus hangs, the CPLD can still obtain accurate channel information through an independent hardware path. Simultaneously, the acquisition terminal is connected to the physical transmission path of the selection control signal, acquiring the actual selection signal received by the multiplexer, rather than the software instructions sent by the IIC master controller. This ensures the accuracy of the channel information and provides a reliable basis for fault location in the fourth processing stage.

[0143] In one specific embodiment, based on the fourth processing stage described above, this embodiment further defines the specific implementation structure of the CPLD cooperating with the IIC master controller to complete communication verification and permanent fault isolation after triggering the reset operation of the faulty slave device.

[0144] The IIC master controller has an interrupt pin, and the CPLD has a second control pin, which is connected to the interrupt pin. The second control pin is a dedicated pin used by the CPLD to send interrupt signals to the IIC master controller, while the interrupt pin is an input pin used by the IIC master controller to receive external interrupt requests. Through this connection, the CPLD can proactively notify the IIC master controller for further processing after completing fault handling operations.

[0145] In the fourth processing stage, after the CPLD triggers a reset operation on the faulty slave device, the CPLD is configured to send an interrupt signal to the IIC master controller via the second control terminal to notify the IIC master controller to read the fault information recorded by the CPLD.

[0146] The IIC master controller is configured to re-enable the channel containing the faulty slave device after reading fault information to verify whether communication on that channel has been restored. Specifically, the IIC master controller sends a channel selection signal to the multiplexer through a first selection terminal, selecting the downstream channel previously identified as the faulty channel. It then attempts to establish IIC communication with the slave device on that channel through a signal transmission terminal. If communication is normal, the verification is successful, and the system resumes normal operation. If communication fails, the verification fails, indicating that the slave device has a permanent fault that cannot be recovered from by a reset.

[0147] When channel communication verification fails, the CPLD is configured to send a reset signal to the multiplexer again via the first control terminal to physically disconnect all downstream channels. Simultaneously, the CPLD notifies the IIC master controller to disable the channel via the second control terminal. Thereafter, the IIC master controller will not select the channel marked as permanently faulty in subsequent operations to avoid the bus hanging again due to repeated attempts to access the faulty device.

[0148] Example illustration: Continuing from the aforementioned example of the industrial switch IIC bus management system. In the fourth processing stage, the CPLD sends a hardware reset signal to the RTC through the third control terminal corresponding to channel 2. The reset signal is released after 1ms, and the RTC completes its internal initialization after a 5ms startup time.

[0149] After the reset operation is completed, the interrupt and reset control module inside the CPLD sends an interrupt signal to the interrupt terminal of the IIC master controller (Nanfei NF5180 switching chip) through the second control terminal. The IIC master controller responds to the interrupt, reads the fault information stored in the fault record register inside the CPLD through the IIC bus, and obtains the fault type (channel-side slave device fault) and fault channel number (channel 2).

[0150] Based on the fault information read, the IIC master controller sends a strobe signal for channel 2 to the multiplexer via the first strobe terminal, re-enabling channel 2. Subsequently, the IIC master controller attempts to initiate an IIC read operation on the RTC on channel 2 via the signal transmission terminal. At this point, two possible scenarios exist: Scenario 1: Communication successful. The RTC returns data normally, and the IIC master controller confirms that communication on channel 2 has been restored. The system resumes normal operation, and the RTC on channel 2 is reinstated into the normal polling sequence.

[0151] Scenario 2: Communication Failure. If the IIC master controller does not receive an acknowledgment signal from the RTC within a preset time, it confirms a permanent fault in channel 2. The IIC master controller notifies the CPLD of the verification failure via the second control terminal. Upon receiving the notification, the CPLD's internal interrupt and reset control module sends a reset signal to the multiplexer (Nanochip NCA9548) again via the first control terminal, physically disconnecting all eight downstream channels and completely isolating the permanently faulty channel 2 from the bus. Simultaneously, the CPLD marks this channel as a permanently faulty channel, updates its internal fault log register, and notifies the IIC master controller via the second control terminal to permanently disable channel 2.

[0152] Subsequently, in subsequent slave device polling operations, the IIC master controller skips channel 2 and no longer sends the corresponding channel 2 strobe signal to the multiplexer. The slave devices on the remaining 7 channels (channels 0, 1, 3 to 7) maintain normal communication, and the overall system function is not affected by the permanently failed channel.

[0153] From the perspective of the CPLD's internal logic implementation, register 0x84 in the fault record register maintained internally by the CPLD is used to record the number of permanently faulty channels. When a channel is determined to be permanently faulty, the CPLD writes the corresponding channel number into this register and notifies the IIC master controller to read it via an interrupt signal. After reading it, the IIC master controller marks the channel as disabled at the software level, and will not initiate any further access to that channel.

[0154] Compared to existing technologies where recovery is considered complete upon reset without verification of the recovery effect, this mechanism improves upon the previous approach by establishing a complete closed loop after the CPLD performs a slave device reset: interrupt notification → fault information reading → channel re-selection → communication verification → verification failure handling. Its technical significance lies in three aspects: First, by actively notifying the IIC master controller via an interrupt signal, it achieves coordinated cooperation between CPLD hardware recovery and IIC master controller software processing. Second, by re-selecting the channel and performing communication verification, the actual communication result serves as an objective basis for judging the success of recovery, preventing the system from mistakenly believing the fault has been eliminated when the reset is ineffective. Third, when verification fails, the faulty channel is marked as a permanent fault and physically isolated. By resetting the multiplexer again to disconnect all channels, it ensures that the permanently faulty channel will not affect the main bus and other normal channels. Simultaneously, the IIC master controller is notified to disable the channel, preventing repeated attempts to access the faulty device from causing the bus to hang again. This mechanism elevates the system from a "single-time recovery" to "intelligent bus management with self-healing and self-optimization capabilities," ensuring long-term system reliability.

[0155] To verify the technical effectiveness of the IIC bus fault handling system provided in this embodiment, a fault simulation test was conducted in the IIC bus management system of an industrial switch. The test conditions were as follows: the IIC bus operating frequency was 100kHz, the CPLD sampling period was 400μs, and the bus hangup determination threshold was 30ms. The simulation showed that the slave device (RTC on channel 2) continuously pulled the SDA signal low due to software deadlock, triggering a bus hangup.

[0156] During the test, the system performed a four-level hierarchical recovery operation in sequence. The time consumption and results of each processing stage are as follows: In the first processing stage, the CPLD performs an interface isolation operation, setting its connection with the IIC bus to a high-impedance state, which takes approximately 2ms. After the isolation operation is completed, the CPLD detects that SDA is still low through the detection terminal, determining that the fault is not in the CPLD itself, and proceeds to the second processing stage.

[0157] In the second processing stage, the CPLD detects that the current hangup state is SCL high and SDA low. It injects 16 clock pulses at a frequency of 100kHz onto the SCL line through the clock signal output terminal, which takes about 6.4ms. After the pulse injection is completed, the CPLD detects that SDA is still low, determines that the slave device is not hangup due to waiting for a clock, and enters the third processing stage.

[0158] In the third processing stage, the CPLD sends a reset signal to the multiplexer through the first control terminal, disconnecting all downstream channels, which takes about 6ms. After the reset is completed, the CPLD detects that SCL and SDA have both returned to high level through the detection terminal, determines that the fault source is located in the slave device on the channel side, and enters the fourth processing stage.

[0159] In the fourth processing stage, the CPLD, based on the previously saved current strobe channel information, determines that the RTC on channel 2 is the faulty slave device. It then sends a hardware reset signal to the RTC via the corresponding third control terminal. The slave device reset and restart process takes approximately 8ms. After the reset is complete, the bus hangup is lifted, and the system resumes normal communication.

[0160] From the occurrence of the bus hang to the restoration of communication, the total recovery time of this system was approximately 22.4ms. During the entire recovery process, the slave devices on the remaining 7 channels (channels 0, 1, 3 to 7) maintained normal communication and were unaffected.

[0161] In contrast, the traditional solution uses a software timer to poll the bus for timeouts by the IIC master controller, with a detection delay of typically 200ms. After a timeout is detected, communication is restored via a global reset, with a recovery time of approximately 300ms. During the reset process, all slave devices are restarted, resulting in a total system interrupt time exceeding 500ms, and the entire recovery process consumes approximately 12% of the IIC master controller's CPU resources.

[0162] As can be seen from the above comparison, the system provided in this embodiment reduces the recovery time by about 96%, narrows the impact range to a single channel (only 1 / 8 of the channel), and the entire detection and recovery process is completed independently by the CPLD hardware logic without the need for software participation of the IIC main controller, thus achieving zero CPU usage.

[0163] In addition, the CPLD in this embodiment maintains a fault recording register internally to record fault information generated during the graded recovery process. The fault recording register includes: a fault counter (recording the cumulative number of faults), a recent bus hang cause register (recording the type of the current fault), a recent fault channel register (recording the channel number where the current fault occurred), a permanent fault channel register (recording the channel number marked as a permanent fault), and a fault count register for each channel (recording the cumulative number of faults for each channel respectively).

[0164] During fault handling, the CPLD writes information such as fault type and fault channel number into the corresponding registers and notifies the IIC master controller to read it via an interrupt signal after completing the reset operation. Maintenance personnel can analyze the fault frequency, fault type distribution, and timing patterns of each channel by reading the aforementioned fault records. This allows them to proactively replace frequently faulty slave devices, optimize hardware design or software drivers, and identify the impact of environmental factors on system reliability, thus shifting from a "passive repair" to a "proactive prevention" maintenance model.

[0165] It will be understood by those skilled in the art that all or some of the steps, systems, or apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all components may be implemented as software executed by a processor, such as a digital signal processor or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software may be distributed on a computer-readable medium, which may include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term "computer storage medium" includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by a computer. Furthermore, it is well known to those skilled in the art that communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

Claims

1. An IIC bus fault handling system, characterized in that, include: The IIC master controller has a signal transmission terminal and a first gating terminal. The signal transmission terminal is used to communicate with the slave device through the IIC bus, and the first gating terminal is used to output a channel gating signal. A multiplexer has a first terminal, a second gating terminal, and at least two second terminals. The first terminal is connected to the signal transmission terminal of the IIC master controller, and the second gating terminal is connected to the first gating terminal of the IIC master controller. Each second terminal is used to connect to at least one slave device through a downstream channel. The multiplexer is used to select a path between the first terminal and one of the second terminals according to the channel gating signal received by the second gating terminal. The CPLD has a detection terminal; the detection terminal is connected to the connection point between the signal transmission terminal of the IIC master controller and the first terminal of the multiplexer, and is used to detect the SCL and SDA signals on the IIC bus; the CPLD is used to determine that the IIC bus is in a hangup state and perform fault handling operation in response to the detection terminal detecting that the SCL or SDA signal is continuously low for more than a preset time.

2. The system according to claim 1, characterized in that: The CPLD is configured to perform fault handling by sequentially executing the following graded recovery operations: In the first processing stage, an interface isolation operation is performed to make its connection with the IIC bus a high-impedance state, thereby releasing its own drive of the IIC bus; if the bus hang-up state is subsequently released, it is determined that the CPLD itself is faulty and the process ends; otherwise, it is determined that the fault is outside the CPLD and enters the second processing stage. In the second processing stage, if the current hang-up state meets the preset slave device waiting clock condition, a bus transaction recovery operation is triggered so that the currently selected slave device can complete the unfinished IIC transaction; if the bus hang-up state is subsequently lifted, it is determined that the slave device waiting clock has timed out and the process ends. Otherwise, proceed to the third processing stage; In the third processing stage, all downstream channels of the multiplexer are disconnected to distinguish whether the fault source is located on the master device side or the slave device side. If the bus hang-up state is subsequently released, it is determined that the channel-side slave device is faulty and the process enters the fourth processing stage. If the bus hang-up state is not released, it is determined that the master IIC is faulty, and the IIC master controller is triggered to perform a reset operation on its IIC interface communicating with the multiplexer before the process ends. In the fourth processing stage, for cases where the fault is determined to be a faulty slave device on the channel side, the faulty slave device is identified based on the previously acquired and saved current strobe channel information, and a reset operation for the faulty slave device is triggered.

3. The system according to claim 2, characterized in that, The CPLD has an isolation terminal, which is connected to the SCL and SDA lines of the IIC bus; The CPLD is further configured to: during the first processing phase, control the isolation terminal to output a high-impedance state so that its connection with the IIC bus is in a high-impedance state.

4. The system according to claim 2, characterized in that, The CPLD has a clock output terminal, which is connected to the SCL line. The CPLD is further configured to: in the second processing stage, if the current hangup state is that the SCL signal is high and the SDA signal is low, inject a preset number of clock pulses into the SCL line through the clock output terminal so that the currently selected slave device completes the unfinished IIC transaction.

5. The system according to claim 2, characterized in that, The multiplexer has a first reset terminal, and the CPLD has a first control terminal, which is connected to the first reset terminal. The CPLD is further configured to: in the third processing stage, send a reset signal to the multiplexer via the first control terminal to reset the multiplexer and disconnect all downstream channels.

6. The system according to claim 2, characterized in that, The IIC master controller has a reset control terminal, and the CPLD has a host reset terminal, which is connected to the reset control terminal of the IIC master controller. The CPLD is further configured to: in the third processing stage, when the bus hang-up state is still not released after all downstream channels are disconnected, send a reset signal to the IIC master controller through the host reset terminal to reset the IIC interface circuit for communication between the IIC master controller and the multiplexer.

7. The system according to claim 6, characterized in that, The CPLD is further configured to: after sending a reset signal to the IIC master controller via the host reset terminal, detect the SCL and SDA signals again via the detection terminal; If both the SCL and SDA signals are high, the host IIC recovery is determined to be successful and the recovery process ends. If the SCL or SDA signal remains low, the host IIC is determined to be permanently faulty.

8. The system according to claim 7, characterized in that, The CPLD is further configured to: record the permanent fault information of the host IIC when a permanent fault is determined in the host IIC, and continuously send a reset signal to the IIC master controller through the host reset terminal.

9. The system according to claim 2, characterized in that, Each slave device has a second reset terminal, and the CPLD has multiple third control terminals, each of which is connected to a slave device's second reset terminal in a one-to-one correspondence. The CPLD is further configured to: in the fourth processing stage, send a hardware reset signal to the faulty slave device via a third control terminal corresponding to the channel where the faulty slave device is located.

10. The system according to claim 2, characterized in that, The CPLD also has a data acquisition terminal, which is connected to the connection point between the first gating terminal and the second gating terminal; The CPLD is further configured to: acquire the channel selection signal sent by the IIC master controller to the multiplexer through the acquisition terminal, acquire and save the current selected channel information of the multiplexer, and determine the channel where the faulty slave device is located based on the current selected channel information in the fourth processing stage.

11. The system according to claim 2, characterized in that, The IIC master controller has an interrupt terminal, and the CPLD has a second control terminal, which is connected to the interrupt terminal. The CPLD is further configured to: after triggering a reset operation on the faulty slave device in the fourth processing stage, send an interrupt signal to the IIC master controller through the second control terminal to notify the IIC master controller to read the fault information recorded by the CPLD; The IIC master controller is configured to: after reading the fault information, re-enable the channel where the faulty slave device is located to verify whether the communication of the channel has been restored; The CPLD is further configured to: when the channel communication verification fails, send a reset signal to the multiplexer again to physically disconnect all downstream channels, and notify the IIC master controller to disable the channel via the second control terminal.

Images