A clock line state-based SPI bus active anti-hanging method and device

Abstract

The application belongs to the field of electronic equipment communication, and discloses a SPI bus active anti-hanging method and device based on clock line state, which comprises the following steps: presetting a first level signal of the SPI clock line in an idle state and a preset anti-hanging count threshold; an SPI controller monitors a second level signal of the clock line in real time; when the condition that the second level signal is inconsistent with the first level signal lasts, an internal counter is started to count; when the count value of the counter reaches the anti-hanging count threshold, the SPI controller determines that the clock line is hung up, and sets an internal hanging state flag; if the SPI hanging interrupt function is enabled through software configuration, the SPI controller sends an interrupt request signal to a processor; and the processor responds to the interrupt request signal to perform a corresponding fault recovery operation. Through real-time monitoring of the clock line state by the SPI controller and comparison with the preset idle level, the identification process can be started at the moment when the clock line is pulled down.

Description

Technical Field

[0001] This invention belongs to the field of electronic device communication technology, and specifically relates to an active anti-hang-up method and device for SPI bus based on clock line status. Background Technology

[0002] SPI (Serial Peripheral Interface) is a high-speed, full-duplex, synchronous serial communication bus. Due to its simple protocol and high communication efficiency, it is widely used for short-distance communication between microcontrollers (MCUs), system-on-a-chip (SOCs) and various peripheral devices (such as memory, sensors, display modules, RF chips, etc.).

[0003] A typical SPI system consists of a master device and one or more slave devices connected by four basic signal lines: CLK (Clock), a clock signal generated by the master device for synchronizing data transmission; MOSI (Master Output / Slave Input), the master device's data output and slave device's data input; MISO (Master Input / Slave Output), the master device's data input and slave device's data output; and SS / CS (Slave Select / Chip Select), the chip select signal from the master device used to select the specific slave device to communicate with.

[0004] When a slave device connected to the SPI bus experiences a hardware failure, it may force the clock line to a fixed level, meaning the clock line is "stuck" by the device. This is a relatively common and serious problem, which directly causes the SPI master to be unable to generate a correct clock, thereby interrupting communication on the entire SPI bus.

[0005] In existing technologies, when an SPI clock line is stuck on a slave device, the common approach is to handle the situation by observing subsequent transmission failures. This involves indirectly inferring the problem by detecting data transmission timeouts or failures. This method is inaccurate, unable to distinguish between clock issues and other causes of transmission failure; furthermore, it is inefficient, requiring waiting for the entire transmission process to time out. Summary of the Invention

[0006] The purpose of this invention is to monitor the clock line status in real time through the internal hardware of the SPI controller and compare it with the preset idle level. This enables the identification process to begin the instant the clock line is pulled to a dead end, achieving a fundamental shift from the existing technology of "passive discovery after transmission failure" to "active diagnosis when the bus is abnormal", greatly shortening the fault detection time.

[0007] In a first aspect, embodiments of the present invention provide an active anti-hang-up method for the SPI bus based on clock line status, applied to a system-on-a-chip (SOC), wherein the SOC acts as an SPI master device, including an SPI controller and a processor, and communicates with slave devices through an SPI interface. The method includes:

[0008] The processor configures the registers of the SPI controller through software, presets the first level signal of the SPI clock line in the idle state, and presets the anti-hang-up count threshold.

[0009] The SPI controller monitors the actual level of the clock line in real time and uses it as a second level signal.

[0010] When the condition that the second level signal is inconsistent with the first level signal continues, the SPI controller enables the internal counter to count;

[0011] When the counter value reaches the anti-hang-up counting threshold, the SPI controller determines that the clock line is hung up and sets the internal hang-up status flag.

[0012] If the SPI hang-up interrupt function has been enabled through software configuration, the SPI controller sends an interrupt request signal to the processor;

[0013] In response to the interrupt request signal, the processor performs the corresponding fault recovery operation.

[0014] Optionally, the preset anti-scratch counting threshold is determined by the following formula:

[0015] Anti-hangover counter threshold = Time threshold / System clock cycle;

[0016] Wherein, the time threshold is a preset minimum time width used to filter interference glitches on the clock line; the system clock period is the period of the clock signal driving the SPI controller.

[0017] Optionally, the step of enabling the SPI hang-up interrupt function through software configuration includes:

[0018] The processor configures specific bits in the interrupt enable register of the SPI controller through a write operation to enable the SPI hang-up interrupt function.

[0019] Optionally, the processor performs a corresponding fault recovery operation, including the following steps:

[0020] Generate a reset signal for the faulty slave device; wherein the reset signal is generated by: controlling the chip select signal of the SPI bus to flip the level; or by controlling a general-purpose input / output interface connected to the reset pin of the faulty slave device to generate a reset pulse.

[0021] The reset signal is sent to the faulty slave device to reset the faulty slave device and release the dead state of the SPI clock line.

[0022] Optionally, after sending a reset signal to the faulty slave device, the method further includes:

[0023] The processor reads the hang-up status flag in the SPI controller to verify whether the clock line has been restored to the idle state;

[0024] If the hang-up status flag indicates that the clock line has returned to normal, continue subsequent data transmission;

[0025] If the hang-up status flag indicates that the anomaly still exists, the fault recovery operation is re-executed.

[0026] Optionally, the re-execution of the fault recovery operation includes:

[0027] Before reaching the preset maximum number of retries, the operation of generating and sending a reset signal is executed repeatedly.

[0028] After reaching the maximum number of retries, if the hangup status flag still indicates an abnormality, the processor generates and records an error log message. The error log message includes at least one of the following: a fault timestamp; the SPI controller number or bus identifier where the hangup occurred; the clock line status level at the time of the hangup; a preset idle status level; the value of the hangup status flag; the number of retries for the reset operation; and the identification information of the faulty slave device.

[0029] Optionally, the SPI controller can only generate and send the interrupt request signal to the processor after the SPI hang-up interrupt function is enabled by software configuration;

[0030] Furthermore, the hang-up status flag of the SPI controller is configured to be cleared in one of the following ways: automatically by hardware logic after the processor reads the status flag, or manually by the processor through a software write operation.

[0031] Secondly, embodiments of the present invention provide an active anti-hang-up device for the SPI bus based on clock line status, applied in a system-on-a-chip (SoC). The device is an SPI controller, comprising:

[0032] The configuration module is used to receive the processor's configuration information through the register interface to preset the first level signal of the SPI clock line in the idle state and the anti-hang-up count threshold.

[0033] The monitoring module is used to monitor the actual level of the clock line in real time as a second level signal;

[0034] The counting and judgment module is used to enable an internal counter to count when the condition of inconsistency between the second level signal and the first level signal continues; and to determine that the clock line is stuck when the count value of the counter reaches the anti-hang-up counting threshold.

[0035] The status flag module is used to set the internal hang-up status flag when the counting and judging module determines that the clock line is hang-up;

[0036] The interrupt control module is used to send an interrupt request signal to the processor when the SPI hang-up interrupt function is enabled and the status flag module is set.

[0037] The processor is used to perform corresponding fault recovery operations in response to the interrupt request signal.

[0038] Thirdly, embodiments of the present invention provide an electronic device, including:

[0039] As described in the second aspect, an active anti-hang-up device for the SPI bus based on clock line status;

[0040] And one or more processors, coupled to the device, for executing instructions to operate the device and, in response to an interrupt request signal generated by the device, performing corresponding fault recovery operations.

[0041] Fourthly, a computer-readable storage medium, characterized in that, when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is able to perform the method described in the first aspect.

[0042] The technical solution provided by this invention monitors the clock line status in real time through an SPI controller and compares it with a preset idle level. This allows the identification process to begin the instant the clock line is pulled to dead, achieving a fundamental shift from the existing "passive detection after transmission failure" to "active diagnosis when the bus is abnormal," significantly shortening fault detection time. Furthermore, by employing a judgment mechanism based on a configurable counting threshold, a dead state is only determined when the abnormal level persists for a predetermined time (determined by the anti-hang-up counting threshold). This effectively filters out transient glitches and noise interference on the bus, avoiding false alarms and significantly improving the system's robustness and stability.

[0043] Moreover, this invention can definitively pinpoint the root cause of the fault to a specific hardware problem—a "clock line dead"—rather than the general "communication failure." This provides a precise basis for subsequent targeted recovery operations (such as resetting a specific slave device), avoiding erroneous operations that may be taken due to ambiguous fault location in existing technologies. Furthermore, through hardware linkage between interrupt enable and interrupt request signals, an interrupt request is automatically and promptly sent to the processor once the fault is confirmed and interrupts are enabled. This allows the processor to quickly interrupt the current task and switch to handling the SPI bus anomaly, greatly optimizing fault response speed and meeting the requirements of real-time systems. Attached Figure Description

[0044] Figure 1 A schematic diagram of a timing diagram provided in an embodiment of the present invention;

[0045] Figure 2 A flowchart of an active anti-hang-up method for SPI bus based on clock line status provided in an embodiment of the present invention;

[0046] Figure 3 A flowchart illustrating a specific example provided in this embodiment of the invention;

[0047] Figure 4 This is a schematic diagram of an active anti-hang-up device for an SPI bus based on clock line status, provided as an embodiment of the present invention. Detailed Implementation

[0048] The present invention will be described in detail below through embodiments.

[0049] SPI (Serial Peripheral Interface) is a high-speed, full-duplex, synchronous serial communication bus. Due to its simple protocol and high communication efficiency, it is widely used for short-distance communication between microcontrollers (MCUs), system-on-a-chip (SOCs) and various peripheral devices (such as memory, sensors, display modules, RF chips, etc.).

[0050] A typical SPI system consists of a master device and one or more slave devices connected by four basic signal lines: CLK (Clock), a clock signal generated by the master device for synchronizing data transmission; MOSI (Master Output / Slave Input), the master device's data output and slave device's data input line; MISO (Master Input / Slave Output), the master device's data input and slave device's data output line; and SS / CS (Slave Select / Chip Select), the chip select signal issued by the master device, used to select the specific slave device to communicate with.

[0051] When a slave device connected to the SPI bus experiences a hardware failure, it may force the clock line to a fixed level, meaning the clock line is "stuck" by the device. This is a relatively common and serious problem, which directly causes the SPI master to be unable to generate a correct clock, thereby interrupting communication on the entire SPI bus.

[0052] In existing technologies, when an SPI clock line is stuck on a slave device, the common approach is to handle the situation by observing subsequent transmission failures. This involves indirectly inferring the problem by detecting data transmission timeouts or failures. This method is inaccurate, unable to distinguish between clock issues and other causes of transmission failure; furthermore, it is inefficient, requiring waiting for the entire transmission process to time out.

[0053] To address the aforementioned technical problems in the prior art, this invention provides an active anti-hang-up method for the SPI bus based on clock line status. This invention is applicable to various electronic devices that use the SPI interface for data transmission. For example, electronic devices may include smartphones, tablets, laptops, and wearable devices. This invention does not specifically limit the type of electronic device.

[0054] The core idea of ​​this invention is to use an SPI controller (also known as an SPI IP) to monitor in real time whether the SPI clock line level is consistent with a preset idle state level, where the preset idle state level can be either high (1) or low (0). This allows the controller to determine if the SPI bus is currently hung by a peripheral slave device. Upon confirming that the SPI bus is hung, the SPI controller uses an interrupt to notify the CPU to perform further operations such as resetting the faulty device, thereby restoring the SPI bus to usability.

[0055] The key protection points of the embodiments of the present invention are as follows:

[0056] Firstly, the SPI controller includes, but is not limited to, monitoring the bus, handling related logic when the bus hangs, ensuring the correctness of the judgment, and reporting related interrupts.

[0057] Secondly, after the SPI controller generates an interrupt, the processor performs further software processing in conjunction with the interrupt. This includes, but is not limited to, how to reset the faulty slave device and re-enable the bus after the corresponding interrupt, restoring its normal transmission function.

[0058] To facilitate a clear description, the overall technical solution of the present invention will first be explained below with reference to the timing diagram of the embodiment of the present invention.

[0059] like Figure 1 The diagram shown is a schematic diagram of a timing diagram provided in an embodiment of the present invention.

[0060] from Figure 1 As can be seen, assuming the CLK (clock line) is high by default when idle, after several normal data transmissions, if the CLK signal is abnormally pulled low due to a peripheral malfunction, the SPI controller will initiate an internal processing flow. At this time, the hang_cnt counter inside the SPI controller will start counting according to the preset configuration value during software initialization. Here, hang_cnt can be understood as the hang-up count value. When the count value reaches the preset anti-hang-up count threshold, the SPI_hang (SPI hang-up) status signal inside the SPI controller is immediately set to valid, indicating that the SPI controller has determined that the CLK signal line is in a hang-up state. This status can be read through the status register inside the SPI controller.

[0061] If the hang-up interrupt function has been enabled in software during the SPI controller initialization phase (i.e., the SPI_int_en signal is set), then after the SPI_hang signal becomes active, and following a predetermined timing delay, the SPI_int_req interrupt request signal will be pulled high, thereby sending an interrupt request to the SoC and triggering subsequent exception handling procedures. Here, SPI_int_en is the interrupt enable signal, and SPI_int_req is the interrupt request signal.

[0062] The SPI controller then reports the generated interrupt request information to the processor for further processing. The processor responds to the interrupt request signal by performing the corresponding fault recovery operation.

[0063] The beneficial effects brought about by the embodiments of the present invention include at least the following aspects:

[0064] 1. Enables proactive and rapid fault diagnosis. By monitoring the clock line status in real time through the internal hardware of the SPI controller and comparing it with the preset idle level, the identification process can begin the instant the clock line is pulled to a dead end. This represents a fundamental shift from the existing technology of "passive discovery after transmission failure" to "proactive diagnosis when the bus is abnormal," greatly shortening the fault detection time.

[0065] 2. Improved system reliability and anti-interference capability. A judgment mechanism based on a configurable counting threshold is adopted. Only when an abnormal level persists for a predetermined time (determined by the Hang_cnt threshold) is the system considered hanged. This effectively filters out transient glitches and noise interference on the bus, avoids false alarms, and significantly improves the system's robustness and stability.

[0066] 3. Achieved precise fault location. This invention can clearly pinpoint the root cause of the fault to the specific hardware problem of "clock line being pulled dead," rather than the general "communication failure." This provides a precise basis for subsequent targeted recovery operations (such as resetting a specific slave device), avoiding erroneous operations that may be taken due to ambiguous fault location in existing technologies.

[0067] 4. It provides an efficient interrupt-driven response mechanism. Through hardware linkage of the SPI_int_en (interrupt enable) and SPI_int_req (interrupt request) signals, an interrupt request is automatically and promptly sent to the processor, provided that a fault is confirmed and interrupt is enabled. This allows the processor to quickly interrupt the current task and switch to handling SPI bus anomalies, greatly optimizing fault response speed and meeting the requirements of real-time systems.

[0068] 5. Optimized hardware and software division of labor and system efficiency. The most time-consuming status monitoring and judgment logic is handled in parallel by the SPI controller hardware, with only the final interrupt results and status information submitted to the CPU software for processing. This design reduces the burden on the CPU to frequently poll the status register, freeing up CPU computing power to handle core application tasks more efficiently and improving overall system efficiency.

[0069] In summary, the embodiments of the present invention provide an efficient, reliable, and real-time SPI bus fault detection and interrupt response mechanism, which fundamentally solves the problem of system paralysis caused by clock line hangup, and greatly enhances the availability and maintainability of the system.

[0070] After describing the overall technical solution of the embodiments of the present invention in conjunction with timing diagrams, the following will describe in detail an active anti-hangover method for the SPI bus based on clock line status provided by the embodiments of the present invention. Figure 2As shown in the figure, an embodiment of the present invention provides an active anti-hang-up method for the SPI bus based on clock line status, applied to a system-on-a-chip (SOC). The SOC acts as an SPI master device, including an SPI controller and a processor, and communicates with slave devices through the SPI interface. The method may include the following steps:

[0071] S210: The processor configures the SPI controller's registers via software, presets the first level signal of the SPI clock line in the idle state, and presets the anti-hang-up count threshold.

[0072] Specifically, this step is the initialization phase of the entire anti-hang-up mechanism, and it is completed by the software driver. The processor accesses the internal configuration register set of the SPI controller through the system bus.

[0073] The first level signal in the idle state can be determined by the clock polarity parameter in the SPI protocol. The software can preset the first level signal to a high or low level according to the characteristics of the communication slave device. This preset value will serve as a reference value for subsequent hardware to determine whether the clock line state is abnormal.

[0074] The anti-hang-up counting threshold (i.e., hang_cnt in the above embodiment) is a key parameter, and its value determines the strength of the system's anti-interference capability. It is not set arbitrarily.

[0075] As one implementation of this invention, the preset anti-snagging counting threshold can be determined by the following formula:

[0076] Anti-hangover count threshold = time threshold / system clock cycle.

[0077] The time threshold is a pre-set minimum time width used to filter interference glitches on the clock line; the system clock period is the period of the clock signal driving the SPI controller.

[0078] The time threshold is a preset time value determined by the software based on the electromagnetic environment and reliability requirements of the system. It must be greater than the width of the maximum noise spike that may occur on the SPI clock line (e.g., 500ns or 1μs). The system clock cycle is the cycle of the master clock that drives the SPI controller. By configuring this threshold, it is ensured that only abnormal levels that continuously exceed the time threshold are considered faults, effectively filtering out transient interference.

[0079] The S220 SPI controller monitors the actual level of the clock line in real time as the second level signal.

[0080] Specifically, this step is performed by dedicated hardware circuitry within the SPI controller, independent of the processor, enabling continuous and parallel monitoring. The actual physical level on the clock line is sampled by the digital logic of the SPI controller core through an input buffer; for clarity, this real-time sampling result can be referred to as the second-level signal. This monitoring is a hardware-based process, requiring no software intervention, thus ensuring real-time performance and high efficiency.

[0081] S230, when the condition of the second level signal being inconsistent with the first level signal continues, the SPI controller enables the internal counter to count.

[0082] Specifically, the SPI controller contains a digital comparator that compares the real-time monitored second-level signal with a software-preset first-level signal. When an inconsistency is detected (e.g., the preset level is idle high, but it is actually pulled low), an internal enable signal is activated, starting a dedicated hardware counter. The condition here is crucial: as long as the inconsistency exists, the counter increments by 1 every system clock cycle; once the inconsistency disappears (e.g., a glitch passes and the level returns to normal), the counter is immediately reset to zero. This design ensures that only persistent anomalies accumulate a count value, while transient noise is ignored.

[0083] S240 When the counter value reaches the anti-hang-up counting threshold, the SPI controller determines that the clock line is hung up and sets the internal hang-up status flag.

[0084] Specifically, the counter compares its real-time count value with a preset anti-hangover count threshold. When the count value equals or exceeds this threshold, it means that the duration of the abnormal level has exceeded the software-defined safety window, and the SPI controller's logic will deterministically determine that the clock line has entered a hangover state. Subsequently, the hangover status flag bit in a specific status register inside the SPI controller (i.e., Figure 1 In this embodiment, the SPI_hang bit will be automatically enabled by hardware (e.g., pulled high to 1). This status bit can be queried by software at any time, providing a clear hardware status indication for diagnostics.

[0085] If the SPI hang-up interrupt function has been enabled through software configuration, the SPI controller sends an interrupt request signal to the processor.

[0086] Specifically, this step is crucial for the hardware to automatically notify the software. An interrupt requires two conditions to be met simultaneously:

[0087] 1. A hang event has occurred. This means that the SPI_hang flag has been set, i.e., pulled high.

[0088] 2. Interrupt function is enabled. During the initialization phase, the software has set the corresponding "hang-up interrupt enable bit (such as SPI_int_en)" in the interrupt enable register of the SPI controller to 1, thus enabling the interrupt output switch.

[0089] Only when both of the above conditions are met will the SPI controller's interrupt logic generate an interrupt request signal (SPI_int_req) and send it to the central interrupt controller in the system-on-a-chip. Ultimately, the interrupt controller will report the SPI exception interrupt to the processor core CPU.

[0090] As one implementation of this invention, the step of enabling the SPI hang-up interrupt function through software configuration may include:

[0091] The processor enables the SPI hang-up interrupt function by configuring specific bits in the interrupt enable register of the SPI controller through write operations. Specifically, when the software writes a 1 to the SPI_int_en bit (e.g., bit 2), the hang-up interrupt function is enabled. At this time, the interrupt generation logic path inside the SPI controller is fully open. Subsequently, once the hardware detects a clock hang-up event and sets the internal status flag, the interrupt control logic will immediately generate a valid interrupt request signal (SPI_int_req) and send it to the processor. Conversely, if the SPI_int_en bit is written to 0 or remains 0, even if a hang-up is detected, the interrupt request path will be blocked, and the controller will not report an interrupt to the processor.

[0092] S260, the processor responds to the interrupt request signal and performs the corresponding fault recovery operation.

[0093] Specifically, after receiving an interrupt request signal, the processor will pause the current task and perform corresponding fault recovery operations. This may include the following steps: First, query the status register. Read the SPI controller's status register and check the SPI_hang flag to confirm whether it is a hang interrupt. Second, perform the corresponding fault recovery operations.

[0094] The technical solution provided by this invention monitors the clock line status in real time through an SPI controller and compares it with a preset idle level. This allows the identification process to begin the instant the clock line is pulled to dead, achieving a fundamental shift from the existing "passive detection after transmission failure" to "active diagnosis when the bus is abnormal," significantly shortening fault detection time. Furthermore, by employing a judgment mechanism based on a configurable counting threshold, a dead state is only determined when the abnormal level persists for a predetermined time (determined by the anti-hang-up counting threshold). This effectively filters out transient glitches and noise interference on the bus, avoiding false alarms and significantly improving the system's robustness and stability.

[0095] Moreover, this invention can definitively pinpoint the root cause of the fault to a specific hardware problem—a "clock line dead"—rather than the general "communication failure." This provides a precise basis for subsequent targeted recovery operations (such as resetting a specific slave device), avoiding erroneous operations that may be taken due to ambiguous fault location in existing technologies. Furthermore, through hardware linkage between interrupt enable and interrupt request signals, an interrupt request is automatically and promptly sent to the processor once the fault is confirmed and interrupts are enabled. This allows the processor to quickly interrupt the current task and switch to handling the SPI bus anomaly, greatly optimizing fault response speed and meeting the requirements of real-time systems.

[0096] As one implementation of this invention, the processor performing a corresponding fault recovery operation may include the following steps, namely step a1 and step a2:

[0097] Step a1: Generate a reset signal for the faulty slave device.

[0098] The reset signal can be generated in two ways: either by controlling the chip select signal of the SPI bus to flip the level, or by controlling the general-purpose input / output interface connected to the reset pin of the fault slave device to generate a reset pulse.

[0099] Step a2: Send a reset signal to the faulty slave device to reset the faulty slave device and release the dead state on the SPI clock line.

[0100] Specifically, after confirming the hangup interrupt, the software executes a predefined recovery procedure. The most common operation is to generate and send a reset signal to the faulty slave device. This can be achieved by controlling the SPI chip select signal (SS / CS) through a series of level toggles; or by configuring a general-purpose GPIO (General Purpose Input / Output) pin to output a reset pulse to the slave device's reset pin.

[0101] The above fault recovery process can bring the following significant benefits:

[0102] 1. It achieves diversity and flexibility in recovery methods. Multiple selectable reset signal generation paths (such as chip select signal operation or dedicated GPIO control) are provided, allowing system designers to choose the most suitable and effective reset method based on the hardware characteristics and reset logic of the target slave device. This flexibility ensures that the anti-hang-up solution is widely applicable to various types of SPI slave devices, enhancing its versatility and practical value.

[0103] 2. It provides an efficient and targeted fault isolation and recovery mechanism. By precisely sending reset signals to specific slave devices identified as fault sources, rather than resetting the entire system or all devices on the bus, it achieves accurate fault isolation and minimal-scale recovery. This greatly shortens the system recovery time from faults, avoids unnecessary context loss or service interruption, and significantly improves system availability and service continuity.

[0104] 3. Fully utilizing existing hardware resources, a low-cost, reliable reset is achieved. Neither of the two specific methods mentioned above incurs additional hardware costs. Using the chip select signal (SS / CS) for level toggling cleverly reuses the control signals necessary for the SPI protocol itself, resulting in an extremely simple and efficient software reset method. Generating a reset pulse through general-purpose input / output pins (GPIO) utilizes widely available general-purpose resources on the SoC, providing an independent and reliable hardware reset path. Both methods achieve the highest reliability at the lowest cost.

[0105] In summary, this predefined recovery process provides a flexible, accurate, low-cost, and efficient fault recovery mechanism. It is an indispensable and important component of the entire SPI active anti-hang-up solution, ensuring that the system can be quickly and automatically repaired after encountering a serious bus failure, thereby achieving the design goal of high robustness.

[0106] As one implementation of this invention, after sending the reset signal to the faulty slave device, the method may further include the following steps, namely steps b1 to b3:

[0107] In step b1, the processor reads the hang-up status flag in the SPI controller to verify whether the clock line has been restored to the idle state.

[0108] Step b2: If the hangup status flag indicates that the clock line has returned to normal, continue with subsequent data transmission.

[0109] Step b3: If the hang-up status flag indicates that the abnormality still exists, re-execute the fault recovery operation.

[0110] Specifically, after sending the reset signal to the faulty slave device, the software reads the SPI_hang flag again to check if the clock line has returned to normal. If it has, the interrupt is exited and normal communication continues. If it has not, the software can trigger multiple reset attempts.

[0111] This implementation method can bring at least the following beneficial effects:

[0112] The verification and retry steps described in this section bring the following significant benefits:

[0113] 1. A reliable fault handling closed loop is formed, ensuring the effectiveness of recovery operations. By actively reading back the hardware status flags for verification after performing a recovery operation, this step establishes a negative feedback closed loop of "execution-verification-confirmation". This ensures that recovery operations (such as resetting slave devices) effectively release the clock line from its suspended state, avoiding the system blindly performing subsequent operations without truly recovering, thus fundamentally guaranteeing the reliability and effectiveness of the fault handling process.

[0114] 2. The system achieves automatic healing and rapid recovery, minimizing business interruptions. When verification is successful (status flags return to normal), the system can seamlessly and automatically resume subsequent data transmission. This significantly shortens the duration of business interruptions and meets the stringent requirements of high continuity and real-time application scenarios.

[0115] 3. It provides fault tolerance levels, enhancing the system's ability to handle persistent faults. The mechanism of re-executing the fault recovery operation when the initial recovery operation fails (the status flag remains abnormal) provides valuable fault tolerance. For non-permanent persistent faults (such as devices requiring multiple resets to recover), this mechanism increases the probability of eventual success through multiple attempts, thereby improving the system's resilience and robustness in non-ideal environments.

[0116] In summary, the verification and retry steps add crucial reliability assurance and intelligent fault tolerance to the entire anti-hangover mechanism, transforming it from a simple fault detector into an intelligent system capable of autonomous decision-making, multiple attempts, and ultimately ensuring the bus recovers to health. This is a key design feature for improving the long-term operational stability of the SPI bus.

[0117] Based on the above implementation, as one implementation of this invention, re-executing the fault recovery operation may include the following steps, namely step c1 and step c2:

[0118] Step c1 involves repeatedly generating and sending a reset signal before reaching the preset maximum number of retries.

[0119] Specifically, this step is the core embodiment of the system's fault-tolerant design. The software driver predefines a maximum number of retries (e.g., 3 or 5 times), which is set based on the system's assessment of the slave device's reset response time and its tolerance for recovery latency.

[0120] If, after the initial recovery operation, the check reveals that the stuck state has not been cleared, the interrupt service routine will not immediately give up. Instead, the control flow will jump, and the operation of generating and sending a reset signal will be executed again. This loop structure provides secondary or even multiple recovery opportunities for non-fatal faults caused by signal glitches, slow device response, etc.

[0121] However, the loop operation does not run indefinitely; it terminates when the preset maximum number of retries is reached. This is a crucial safety mechanism to prevent the system from entering an infinite loop due to permanent physical damage to a slave device. Once the retry counter reaches the maximum number of retries, the loop terminates immediately, and the program flow proceeds to step c2. This ensures the sustainability of system resources and the stability of core functions.

[0122] Step c2. After reaching the maximum number of retries, if the hang status flag still indicates an exception, the processor generates and records an error log message.

[0123] The error log information includes at least one of the following: fault timestamp; SPI controller number or bus identifier where the hang occurred; clock line status level at the time of hang; preset idle status level; value of hang status flag; number of retries for reset operation; and identification information of the faulty slave device.

[0124] Specifically, this step is the final stage of fault management, and its purpose is to provide the most detailed fault information to system maintenance personnel or upper-level diagnostic systems when automatic recovery measures are completely ineffective.

[0125] This step is performed only if the hang persists after the maximum number of retries has been reached. This clearly identifies the current fault as a persistent hardware failure that cannot be resolved by a software reset; for example, the device may have suffered irreversible physical damage. The processor will generate an error log entry with rich context. The information contained within has extremely high diagnostic value.

[0126] For fault timestamps, they accurately record the time when the fault occurred, and are used for system log analysis, problem tracing, and correlation of faults across multiple devices.

[0127] The SPI controller number or bus identifier that caused the hang. In a complex SoC with multiple SPI controllers, pinpoint the specific bus where the fault occurred.

[0128] Clock line status level when suspended and preset idle status level: Record the actual level (e.g., pulled low) and preset idle level (e.g., should be high) when an abnormality occurs, to help determine the fault type, such as whether it is a short circuit to ground or a short circuit to the power supply.

[0129] The value of the hang-up status flag and the number of retries for the reset operation provide evidence of the SPI controller's internal state and software recovery efforts.

[0130] The fault is identified by the device's identification information. This is the most critical information, directly indicating which specific device has failed, and is the core basis for hardware replacement or isolation.

[0131] After recording the error log information, the software can perform the final operation. For example, it can permanently disable the faulty slave device (e.g., mark it as a faulty component to prevent subsequent communication from triggering a hangup), and report the error information to the upper-level management unit or operating system through the system management bus, which may eventually trigger a system-level alarm (e.g., illuminate the fault indicator, send a network alarm, etc.) to notify maintenance personnel to intervene.

[0132] This implementation method constitutes at least a complete and intelligent final fault handling process, and its beneficial effects include at least the following:

[0133] 1. Enhanced system fault tolerance. Through a finite retry mechanism, it effectively addresses non-persistent failures, improving the system's self-recovery capability and resilience in harsh environments.

[0134] 2. System freezes are avoided. By setting a retry limit, system resources are prevented from being exhausted indefinitely in the event of a permanent failure, ensuring the stable operation of core functions.

[0135] 3. It enables precise fault diagnosis and location. The detailed error logs provide technicians with accurate remote fault diagnosis capabilities, greatly shortening the mean time to repair (MTBL).

[0136] 4. Supports predictive maintenance. The system can track the number of failures of specific slave devices over a long period. If a device frequently triggers this process and eventually records an error, it can provide an early warning of impending failure, thus enabling predictive maintenance.

[0137] Based on the above embodiments, as one implementation of the present invention, the SPI controller can only generate and send an interrupt request signal to the processor after the SPI hang-up interrupt function is enabled by software configuration.

[0138] Furthermore, the hang-up status flag of the SPI controller is configured to be cleared in one of the following ways: automatically by hardware logic after the processor reads the status flag, or manually by the processor through a software write operation.

[0139] Specifically, even if the bus is in an abnormal state before system startup and software initialization, no uncontrollable interrupt requests will be generated because interrupts are not enabled, ensuring the stability of the system startup process. Furthermore, the software can dynamically enable or disable the hang-up interrupt function according to different stages and modes of system operation, achieving fine-grained and flexible interrupt management. In addition, separating event occurrence and interrupt reporting makes the hardware IP design clearer and more modular.

[0140] Furthermore, this implementation provides two optional strategies for clearing the hang status flag, one of which is typically selected during IP design via parameterized configuration or registers:

[0141] Method 1 is automatic clearing. This is a read-and-clear mode. When the processor reads the register containing the status flag via the bus, the hardware logic automatically and immediately clears the flag bit to zero. This method is simple to operate, requiring no additional clearing operation from the software, reducing programming complexity and the possibility of errors; it can also effectively prevent interrupt storms caused by the status bit remaining valid, i.e., the same interrupt request being repeatedly triggered, thereby excessively consuming CPU resources.

[0142] Method two is manual clearing. In this mode, the status flag remains set until the processor explicitly performs a specific write operation (e.g., writing a 1 or 0 to the status flag). This method ensures the flag remains set until explicitly cleared by software, greatly facilitating debugging and diagnostics. Software developers can read the registers at convenient times to accurately understand historical fault information without losing data due to premature reading. Furthermore, the software has complete control over the clearing timing, ensuring that all related processing (such as logging and status reporting) is completed before the status flag is cleared.

[0143] To ensure clarity, a specific example will be used below to illustrate the overall technical solution of this invention. For example... Figure 3 As shown, during the system initialization phase, the software driver needs to initialize and configure the SPI controller. This configuration includes communication parameters such as baud rate, clock phase and polarity, and transmission bit width. Specifically for the anti-hangover mechanism described in this invention, the following key parameters must be preset: the default level of the clock line in the idle state; the anti-hangover count threshold (hang_cnt); and the hangover interrupt enable bit (SPI_int_en).

[0144] When the SPI bus clock line (CLK) is hung during data transmission due to a slave device failure, the system's processing flow depends entirely on the configuration of the hang-up interrupt enable during the initialization phase.

[0145] 1. If hang-up interrupts are not enabled, it indicates that the software does not pay attention to this type of fault. Even if a clock line hang-up occurs, the SPI controller will not generate an interrupt, and the software will therefore not respond to this event, and bus communication will remain interrupted.

[0146] 2. If hang-up interrupts are enabled (this is the typical configuration), the SPI controller will immediately send an interrupt request to the processor (CPU) after detecting and confirming the hang-up condition. Upon receiving this interrupt, the software will initiate a predefined fault recovery process. Common reset methods include: performing a specific level toggle operation by controlling the chip select signal (SS / CS); or sending a reset pulse to the reset pin of the faulty slave device by configuring a general purpose input / output (GPIO) pin.

[0147] After the fault recovery operation is completed, the software needs to read the hangup status flag of the SPI controller for verification. If the status flag indicates that the clock line has returned to the idle default state, the fault is considered resolved, and normal data transmission can continue. If the status flag still shows an abnormality, the software should initiate a retry mechanism and repeatedly perform the reset operation. If the fault still exists after reaching the preset maximum number of retries, detailed error log information is generated and recorded, and can be reported to the upper-level system.

[0148] It is important to note that the hang-up interrupt function is typically enabled during SPI initialization. Therefore, if a clock line hang occurs before initialization is complete, the interrupt request can only be reported to the processor after the initialization process is finished and the interrupt enable bit is active.

[0149] Furthermore, the hang status flag can be configured to be cleared in one of two ways:

[0150] The first method is automatic clearing. The hardware logic automatically clears the status flag after the processor reads it, which can effectively prevent repeated interrupts caused by the status bit remaining valid and avoid the CPU resources being occupied for a long time.

[0151] The second method is manual clearing. This requires the processor to explicitly clear the state through a write operation. This method is beneficial for software to retain state information during the debugging phase for diagnostic purposes.

[0152] Secondly, embodiments of the present invention provide an SPI bus active anti-hang-up device 40 based on clock line status, applied in a system-on-a-chip (SOC). The device is an SPI controller, such as... Figure 4 As shown, it includes:

[0153] Configuration module 410 is used to receive configuration information from the processor through the register interface to preset the first level signal of the SPI clock line in the idle state and the anti-hang-up count threshold.

[0154] Monitoring module 420 is used to monitor the actual level of the clock line in real time as a second level signal;

[0155] The counting and judgment module 430 is used to enable an internal counter to count when the condition of the second level signal being inconsistent with the first level signal continues; and to determine that the clock line is hung when the count value of the counter reaches the anti-hang-up counting threshold.

[0156] The status flag module 440 is used to set the internal hang-up status flag when the counting and judging module determines that the clock line is hang-up.

[0157] The interrupt control module 450 is used to send an interrupt request signal to the processor when the SPI hang-up interrupt function is enabled and the status flag module is set.

[0158] The processor is used to perform corresponding fault recovery operations in response to the interrupt request signal.

[0159] Thirdly, embodiments of the present invention provide an electronic device, including:

[0160] As described in the second aspect, an active anti-hang-up device for the SPI bus based on clock line status;

[0161] And one or more processors, coupled to the device, for executing instructions to operate the device and, in response to an interrupt request signal generated by the device, performing corresponding fault recovery operations.

[0162] Fourthly, a computer-readable storage medium, characterized in that, when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is able to perform the method described in the first aspect.

[0163] Although embodiments of the present invention have been shown and described above, these embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of the present invention without departing from the principles and spirit of the present invention.

Claims

1. A method for actively preventing hang-up on an SPI bus based on clock line status, characterized in that, The method, applied to a system-on-a-chip (SOC) where the SOC acts as an SPI master device and includes an SPI controller and a processor, and communicates with slave devices via an SPI interface, includes: The processor configures the registers of the SPI controller through software, presets the first level signal of the SPI clock line in the idle state, and presets the anti-hang-up count threshold. The SPI controller monitors the actual level of the clock line in real time and uses it as a second level signal. When the condition that the second level signal is inconsistent with the first level signal continues, the SPI controller enables the internal counter to count; When the counter value reaches the anti-hang-up counting threshold, the SPI controller determines that the clock line is hung up and sets the internal hang-up status flag. If the SPI hang-up interrupt function has been enabled through software configuration, the SPI controller sends an interrupt request signal to the processor; The processor responds to the interrupt request signal and performs the corresponding fault recovery operation; The preset anti-scratch counting threshold is determined by the following formula: Anti-hangover counter threshold = Time threshold / System clock cycle; Wherein, the time threshold is a preset minimum time width used to filter interference glitches on the clock line; the system clock period is the period of the clock signal driving the SPI controller.

2. The method according to claim 1, characterized in that, The step of enabling the SPI hang-up interrupt function through software configuration includes: The processor configures specific bits in the interrupt enable register of the SPI controller through a write operation to enable the SPI hang-up interrupt function.

3. The method according to claim 1, characterized in that, The processor performs the corresponding fault recovery operation, including the following steps: Generate a reset signal for the faulty slave device; wherein, the reset signal is generated by: controlling the chip select signal of the SPI bus to flip the level; or by controlling the general-purpose input / output interface connected to the reset pin of the faulty slave device to generate a reset pulse; The reset signal is sent to the faulty slave device to reset the faulty slave device and release the dead state of the SPI clock line.

4. The method according to claim 3, characterized in that, After sending a reset signal to the faulty slave device, the method further includes: The processor reads the hang-up status flag in the SPI controller to verify whether the clock line has been restored to the idle state; If the hang-up status flag indicates that the clock line has returned to normal, continue subsequent data transmission; If the hang-up status flag indicates that the anomaly still exists, the fault recovery operation is re-executed.

5. The method according to claim 4, characterized in that, The re-execution of the fault recovery operation includes: Before reaching the preset maximum number of retries, the operation of generating and sending a reset signal is executed repeatedly. After reaching the maximum number of retries, if the hangup status flag still indicates an abnormality, the processor generates and records an error log message. The error log message includes at least one of the following: a fault timestamp; the SPI controller number or bus identifier where the hangup occurred; the clock line status level at the time of the hangup; a preset idle status level; the value of the hangup status flag; the number of retries for the reset operation; and the identification information of the faulty slave device.

6. The method according to any one of claims 1 to 5, characterized in that: The SPI controller can only generate and send the interrupt request signal to the processor after the SPI hang-up interrupt function is enabled by software configuration; Furthermore, the hang-up status flag of the SPI controller is configured to be cleared in one of the following ways: automatically by hardware logic after the processor reads the status flag, or manually by the processor through a software write operation.

7. An active anti-hang-up device for SPI bus based on clock line status, characterized in that, The device, used in a system-on-a-chip (SoC), is an SPI controller and includes: The configuration module is used to receive the processor's configuration information through the register interface to preset the first level signal of the SPI clock line in the idle state and the anti-hang-up count threshold. The monitoring module is used to monitor the actual level of the clock line in real time as a second level signal; The counting and judgment module is used to enable an internal counter to count when the condition of inconsistency between the second level signal and the first level signal continues; and to determine that the clock line is stuck when the count value of the counter reaches the anti-hang-up counting threshold. The status flag module is used to set the internal hang-up status flag when the counting and judging module determines that the clock line is hang-up; The interrupt control module is used to send an interrupt request signal to the processor when the SPI hang-up interrupt function is enabled and the status flag module is set. The processor is used to perform corresponding fault recovery operations in response to the interrupt request signal; The preset anti-scratch counting threshold is determined by the following formula: Anti-hangover counter threshold = Time threshold / System clock cycle; Wherein, the time threshold is a preset minimum time width used to filter interference glitches on the clock line; the system clock period is the period of the clock signal driving the SPI controller.

8. An electronic device, characterized in that, include: The active anti-hang-up device for SPI bus based on clock line status as described in claim 7; And one or more processors, coupled to the device, for executing instructions to operate the device and, in response to an interrupt request signal generated by the device, performing corresponding fault recovery operations.

9. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device is enabled to perform the method as described in any one of claims 1-6.

Images