Method, system, medium and product for detecting hardware state of a board card through a debugging serial port

Abstract

A method, system, medium, and product for detecting the hardware status of a circuit board via a debug serial port are disclosed, relating to the field of status detection technology. The method includes: receiving processor debug data output by the processor on the circuit board via a programmable logic device (PLD), and storing the processor debug data in a first first-in-first-out (FIFO) buffer within the PLD; continuously sampling multiple hardware signals on the circuit board via the PLD, and when a change in the state of any hardware signal is detected, forming hardware status data based on the current status data of all hardware signals, and storing the hardware status data in a second FIFO buffer within the PLD; selecting data from the first and second FIFO buffers based on a preset priority rule, serializing the selected data via the PLD, and then sending it externally via the processor debug serial port. Implementing the above technical solution can effectively detect the hardware status of a circuit board.

Description

Technical Field

[0001] This application relates to the field of status detection, and in particular to a method, system, medium, and product for detecting the hardware status of a board through a debugging serial port. Background Technology

[0002] With the continuous development of computer technology and electronic devices, the accurate detection of the hardware status of circuit boards, as an important component of electronic devices, is crucial for the stable operation of the devices.

[0003] Hardware boards typically output processor debugging information via a debug serial port, which can be used for cause analysis and localization when board problems occur. In high-reliability applications such as rail transportation and power, once a hardware product malfunctions, it is necessary to trace the process and cause of the problem and ultimately resolve it completely. Analyzing debug information is an important means of problem tracing; however, the debug information output by the debug serial port is issued by the CPU software, and its content includes the software's running status and some hardware register status information, but basically does not include information about the signals on the hardware board itself. Summary of the Invention

[0004] This application provides a method, system, medium, and product for detecting the hardware status of a circuit board through a debug serial port. It can effectively detect the hardware status of the circuit board, realize cross-location of hardware events and software logs, and generate fault diagnosis reports, thereby improving the efficiency and accuracy of data detection and processing.

[0005] Firstly, this application provides a method for detecting the hardware status of a circuit board via a debug serial port, the method comprising: The programmable logic device receives processor debugging data output by the processor on the board, the processor debugging data including the software running status, and stores the processor debugging data in the first first-in-first-out buffer in the programmable logic device. The programmable logic device continuously samples multiple hardware signals on the board. When a change in the state of any hardware signal is detected, the state data of all the hardware signals is obtained, a timestamp is added to the state data to form hardware state data, and the hardware state data is stored in the second first-in-first-out buffer in the programmable logic device. Based on a preset priority rule, data is selected from the first FIFO buffer and the second FIFO buffer. The selected data is serialized through the same serial transmission module within the programmable logic device and then transmitted externally via the processor debug serial port. The preset priority rule includes: when the second FIFO buffer is not empty, the hardware status data cached in the second FIFO buffer is transmitted; otherwise, the processor debug data cached in the first FIFO buffer is transmitted.

[0006] By employing the above technical solution, changes in key hardware signals of the board are monitored and recorded in real time, providing direct hardware evidence for fault analysis and overcoming the shortcomings of traditional debug serial ports that only output software information. No additional debug interface is required; the existing debug serial port on the board can be used to output both software and hardware information simultaneously, without altering the product form or user habits. Through dual FIFO buffering and hardware-priority transmission rules, data conflicts and buffer overflows are effectively avoided, ensuring that both hardware status change information and software debugging information are output completely. High-precision timestamps are added to hardware status changes, synchronizing the timeline of hardware events and software logs, facilitating the analysis of event sequence and significantly improving problem localization efficiency.

[0007] In some embodiments, the method further includes: Before storing the processor debug data into the first first-in-first-out buffer, the processor debug data is stream-scanned, and the current fill rate and overflow risk level of the second first-in-first-out buffer are continuously monitored. The processor debug data is identified as containing a preset priority control field, which includes general high-priority keywords and specific instruction fields. Based on the identification result and the current overflow risk level of the second first-in-first-out cache, a dynamic priority score is calculated using a preset weighted decision function. When the dynamic priority score exceeds the preset hardware data priority threshold, the transmission priority of the first first-in-first-out buffer is temporarily increased to a level higher than that of the second first-in-first-out buffer, and the duration of the increase is dynamically adjusted according to the overflow risk level. During the priority promotion process, if the fill rate of the second first-in-first-out buffer is detected to be continuously increasing and exceeding the safe rate limit, the current priority promotion will be terminated in advance and the system will immediately switch to the preset priority rule.

[0008] By employing the above technical solution, high-priority keywords in processor debug data are scanned in real time, dynamically increasing the sending priority of software data. This ensures that important software debug information is not overwhelmed by hardware data at critical moments, facilitating the capture of critical logs during faults. Combining the filling rate and overflow risk level of the second FIFO, priority scores are dynamically calculated and the duration of software priority is adjusted. This enables automatic adjustment of the scheduling strategy based on hardware data cache pressure, avoiding cache overflow caused by fixed priorities. During software priority promotion, the filling rate of the hardware data cache is continuously monitored. If the rate consistently exceeds the limit, software priority is immediately terminated and the system switches back to hardware priority mode, effectively preventing the loss of hardware status data due to cache overflow. By using a weighted decision function to comprehensively consider multiple factors and dynamically arbitrate priorities, both the output opportunity of high-value software logs and the integrity of hardware event data are guaranteed, thus improving the overall reliability and adaptability of debug information collection.

[0009] In some embodiments, calculating the dynamic priority score using a preset weighted decision function includes: A keyword-weight mapping table is pre-configured within the programmable logic device, and a basic weight value is assigned to each preset priority control field. The processor debugging data is scanned in real time. If multiple keywords are hit consecutively within a preset time window, the corresponding basic weight value is accumulated as the original score, and the number of hits is used as a multiplier factor. Read the current fill rate of the second first-in-first-out buffer and the percentage of the current fill depth to the total depth, normalize the fill rate into a rate factor, and quantify the overflow risk level into a risk factor. The dynamic priority score is calculated by substituting the original score, the multiplier factor, the rate factor, and the risk factor into the weighted decision function.

[0010] By employing the above technical solution, multiple independent variables, such as keyword weight, hit frequency, cache fill rate, and overflow risk level, are uniformly quantified into a dynamic priority score through a weighted function, enabling multi-dimensional information fusion decision-making. By accumulating the weight values ​​of hit keywords within a preset time window and using the hit count as a multiplier factor, consecutively occurring high-value debugging information receives amplified scores, ensuring timely identification of urgent software logs. The fill rate is normalized into a rate factor, and the overflow risk level is quantified into a risk factor, allowing the actual pressure state of the hardware data cache to dynamically influence the priority score, enabling adaptive adjustment of the scheduling strategy to the system load. The continuous score values ​​calculated by the weighted function can be smoothly compared to preset hardware data priority thresholds, avoiding jitter triggered by a single condition and ensuring the accuracy and stability of priority improvement decisions.

[0011] In some embodiments, the step of dynamically adjusting the duration of the increase based on the spillover risk level includes: A basic duration register and a risk-time mapping lookup table are set within the programmable logic device. In the risk-time mapping lookup table, a corresponding duration coefficient is configured for each overflow risk level. When a priority increase is triggered, the overflow risk level of the current second first-in-first-out buffer is read, the corresponding duration coefficient is obtained from the risk-time mapping lookup table, and the value of the base duration register is multiplied by the duration coefficient to obtain the preliminary adjusted actual duration. Read the current fill depth change rate of the second first-in-first-out buffer. If the current fill depth change rate is positive and the absolute value exceeds the preset acceleration threshold, then correct the actual duration based on the normalized value of the current fill depth change rate. The corrected actual duration is taken as the final boost duration and output to the priority scheduling module as the retention time of the high priority state of the first first-in-first-out buffer.

[0012] By employing the above technical solution, a risk-time mapping lookup table is used to configure different duration coefficients for different overflow risk levels (the higher the risk, the smaller the coefficient). This allows the software priority duration to be automatically compressed according to hardware cache pressure, preventing hardware data overflow caused by software data occupying bandwidth for extended periods under high pressure. A fill depth change rate (i.e., the derivative of the fill rate) is introduced to perform a secondary correction on the duration. When cache filling accelerates, the software priority duration is further shortened, enabling early prevention of overflow risks rather than responding only when the cache is nearly full. Based on a three-layer calculation of the base duration register, mapping coefficient, and change rate correction, a precise final hold duration is output, avoiding the two extremes caused by a fixed duration: too short a duration leading to incomplete transmission of critical software logs, or too long a duration leading to hardware data loss. While ensuring the integrity of hardware status data, the system maximizes the transmission window for high-priority software data, achieving a dynamic balance between the two types of data output opportunities through fine-grained duration control, thereby improving the reliability and efficiency of overall debugging information acquisition.

[0013] In some embodiments, the method further includes: The receiving end acquires the aggregated data stream output via the processor debug serial port, and distinguishes the processor debug data frame and hardware status data frame in the aggregated data stream according to the preset frame header identifier. Extract the timestamp field and the hexadecimal encoded status word field from the hardware status data frame. The bit width of the status word field is equal to the number of monitored hardware signals, and each bit corresponds to the current logic level of a hardware signal. The hexadecimal representation of the status word field is converted into a binary bit string, and then XORed bit by bit with the previously received status word to generate a change bit mask. Bits with a value of one in the change bit mask indicate hardware signals that have changed. An event record is generated based on the changed bitmask and the timestamp. The event record includes the time when the change occurred, the index of the signal bit that changed, and the changed level value.

[0014] By employing the above technical solution, and through a preset frame header identifier, processor debugging data and hardware status data in the aggregated data stream are accurately distinguished, avoiding interference between the two types of data and providing a clean data source for subsequent analysis. After converting the hexadecimal status word into a binary bit string, a change bit mask is generated through bitwise XOR operations. This allows for one-click location of changed hardware signal bits, eliminating the need for manual comparison byte by byte and significantly improving analysis efficiency. Only the change bit mask, timestamp, and changed level value are recorded, rather than storing the entire status word for each sample, significantly compressing the amount of hardware event records and facilitating long-term storage and transmission. Event records containing the change time, signal bit index, and changed level are generated, transforming the raw binary status information into structured data, laying the foundation for subsequent advanced analysis such as visualization and fault diagnosis.

[0015] In some embodiments, the method further includes: A signal mapping table is pre-configured at the receiving end. The signal mapping table records the mapping relationship between each signal bit index and the corresponding hardware signal name and signal type. The signal types include reset signal, power status indication signal, alarm signal, status gene signal, control signal, and interface signal. For each signal bit index in the event record, query the signal mapping table to obtain the corresponding hardware signal name and signal type, and replace the signal bit index with the hardware signal name to generate change event text; On the same user interface, with a unified time axis as the horizontal axis, the processor debugging data is displayed in the first display area in the form of a scrolling text stream, and the hardware signal level changes corresponding to the change event text are displayed in the second display area in the form of a waveform or level transition marker. In response to the user selecting a level transition marker in the second display area, the processor debug data entry with the timestamp closest to the level transition marker is highlighted in the first display area, thereby achieving cross-location of hardware events and software logs.

[0016] By employing the above technical solution, a pre-configured signal mapping table automatically converts abstract binary bit indices into specific hardware signal names and types (such as reset signals, alarm signals, etc.), generating intuitive change event text and lowering the understanding threshold for fault analysis. On the same user interface, using a unified timeline as a reference, processor debug data is displayed in text stream format, while hardware signal level changes are displayed in waveform graphs or transition markers, achieving spatiotemporal alignment between software logs and hardware events, facilitating the observation of causal relationships. When the user selects any transition marker on the hardware waveform, the system automatically highlights the software debug data entry with the closest timestamp, supporting rapid jumps from hardware anomalies to the corresponding software context, significantly improving troubleshooting efficiency. The fusion of software runtime status text and hardware signal timing waveforms preserves the integrity of traditional debugging information while adding a visual representation of hardware behavior, providing engineers with a panoramic view of fault diagnosis.

[0017] In some embodiments, the method further includes: A diagnostic rule base is set at the receiving end. The diagnostic rule base contains multiple diagnostic rules, and each diagnostic rule is associated with a signal bit change pattern and a corresponding fault description text. For each change bitmask in the event record, the change bitmask is combined with the previously received status word to restore the value of each bit before and after the change, and a change detail list is generated according to the signal mapping table. The change detail list includes the signal name, the level before the change, the level after the change, and the change time. Each change in the change details list is matched with all rules in the diagnostic rule base. If a match is successful, a diagnostic entry is generated. The diagnostic entry includes the matched fault description text, suggested troubleshooting steps, and associated processor debug data fragment index. All generated diagnostic entries are compiled into a fault diagnosis report in chronological order, and the report is previewed and exported on the user interface.

[0018] By employing the above technical solution, the changed bitmask is combined with the previous status word to reconstruct the level before the change, the level after the change, and the change time of each changed signal, generating a structured list of change details. This avoids manual bit-by-bit calculations and improves information readability. A diagnostic rule base is used to associate signal bit change patterns with fault description text and troubleshooting steps, enabling automatic matching and diagnosis of change events. This transforms raw hardware jumps into actionable fault prompts, lowering the analysis threshold. The diagnostic entries are associated with processor debug data fragment indexes, allowing fault phenomena to not only be associated with hardware changes but also to quickly locate the corresponding software logs, enabling joint hardware and software analysis and accelerating root cause localization. All diagnostic entries are summarized in chronological order into a complete fault diagnosis report, providing preview and export functions for easy recording, archiving, and team collaboration, forming traceable, closed-loop zeroing evidence.

[0019] In a second aspect, embodiments of this application provide a computer system including a memory, a processor, and a computer program stored in the memory; the processor executes the computer program to implement the steps of the method described in any possible implementation of the first aspect.

[0020] Thirdly, embodiments of this application provide a computer-readable storage medium having a computer program / instructions stored thereon, which, when executed by a processor, implement the steps of the method described in any possible implementation of the first aspect.

[0021] Fourthly, embodiments of this application provide a computer program product, including a computer program / instructions, which, when executed by a processor, implement the steps of the method described in any possible implementation of the first aspect.

[0022] It is understood that the computer system provided in the second aspect, the storage medium provided in the third aspect, and the computer program product provided in the fourth aspect are all used to execute the method provided in this application. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods, and will not be repeated here.

[0023] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages: 1. Traditional debugging serial ports only output CPU software information and lack direct evidence of hardware signals (such as reset, power enable, alarm, etc.). The embodiments of this application provide hardware-level data for fault analysis by continuously sampling hardware signals and recording timestamps when they change. 2. Two independent FIFO buffers are used to distinguish between the two types of data sources, and hardware status data is sent serially with priority, ensuring that hardware change events can be output in a timely manner without being overwhelmed by software debugging information; at the same time, since hardware signals may change very quickly, the FIFO buffer can cope with sudden large changes and prevent data loss. 3. Fully reuses the processor's built-in debug serial port, without changing the physical interface of the board or user habits, and without adding additional connectors or modifying existing debug tools; 4. The hardware status data includes a high-precision timestamp and shares the same output channel with the software debugging information, which facilitates the alignment of the event sequence during subsequent analysis and accurately determines the causal chain of the fault. Attached Figure Description

[0024] Figure 1 This is a flowchart illustrating the method for detecting the hardware status of a board via a debug serial port in an embodiment of this application. Figure 2 This is a schematic diagram of the system architecture of the method for detecting the hardware status of a board through a debug serial port in this embodiment of the application; Figure 3 This is a schematic diagram of an exemplary hardware structure of a computer system in an embodiment of this application. Detailed Implementation

[0025] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to any or all possible combinations including one or more of the listed items.

[0026] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0027] The following is combined Figure 1 The method of the embodiments of this application will be described below.

[0028] Please see Figure 1 This is a flowchart illustrating the method for detecting the hardware status of a board via a debug serial port in an embodiment of this application. Figure 1 As shown, the method includes the following steps: S101. Receive processor debugging data output by the processor on the board through the programmable logic device. The processor debugging data includes the software running status. Store the processor debugging data in the first first-in-first-out buffer in the programmable logic device. S102. The programmable logic device continuously samples multiple hardware signals on the board. When a change in the state of any hardware signal is detected, the current state data of all hardware signals is obtained, a timestamp is added to the state data to form hardware state data, and the hardware state data is stored in the second first-in-first-out buffer in the programmable logic device. S103. Based on a preset priority rule, select data from the first first-in-first-out (FIFO) buffer and the second FIFO buffer, and serialize the selected data through the same serial transmission module in the programmable logic device, and then send it externally via the processor debug serial port. The preset priority rule includes: when the second FIFO buffer is not empty, send the hardware status data cached in the second FIFO buffer; otherwise, send the processor debug data cached in the first FIFO buffer.

[0029] The processor on the board typically has one or more debug serial ports (UARTs) for outputting debug information such as kernel logs, application runtime status, and exception stacks. This information exists in the form of a serial data stream, with baud rates typically 115200, 921600, etc. In this embodiment, the transmit pin (TX) of the debug serial port is connected to a general-purpose input / output pin of a programmable logic device (such as a CPLD or FPGA). The programmable logic device internally implements a UART receiver module using a hardware description language (Verilog / VHDL). The UART receiver module samples the serial data at the same baud rate as the processor's debug serial port. Oversampling techniques (e.g., 16x oversampling) are typically used to identify the start bit, data bits, parity bit, and stop bit. After completing the serial-to-parallel conversion, the receiver module converts each byte (8 bits of data) into parallel data. This parallel data is immediately written to the first first-in-first-out buffer (FIFO-1). The depth of FIFO-1 needs to be designed according to the maximum data burst length that the processor's debug serial port may continuously output, such as 512 bytes or 1024 bytes, to prevent data overflow.

[0030] Connect the key hardware signals that need to be monitored on the board (e.g., reset signals, control signals, power status indicators, alarm signals, clock lock signals, temperature alarm signals, etc., the number of which can range from several to hundreds) to different input pins of the programmable logic device. Inside the programmable logic device, design a high-speed clock-triggered monitoring module. High-speed clock: The frequency is generally no less than 100MHz to ensure that it can capture signal changes at the nanosecond level.

[0031] Sampling and latching: At the rising edge of each high-speed clock, the monitoring module samples all connected hardware signals and latches the sampled values ​​into a current status register.

[0032] Change detection: The current status register value is compared bit by bit with the previous status register value. If they are exactly the same, it means that no signal has changed; if any bit is different, it means that the hardware signal corresponding to that bit has undergone a level transition.

[0033] Generating Hardware Status Data: Once a change is detected, a high-precision timestamp is immediately read. This timestamp is generated by a wide-bit counter (e.g., 48-bit or 64-bit), also driven by a high-speed clock, providing nanosecond-level time resolution. The values ​​of all currently monitored signals (i.e., the current value of the status register, with each signal corresponding to one binary bit) are combined with the timestamp to form a hardware status data entry. This hardware status data is written to a second first-in-first-out buffer (FIFO-2).

[0034] The programmable logic device also includes a UART transmission module, which is responsible for serializing the data in FIFO-1 and FIFO-2 and transmitting it externally through the processor's debug serial port pin (usually multiplexing the same TX pin). To avoid conflicts between the two types of data during transmission and to ensure that critical hardware events can be output in a timely manner, this application embodiment adopts a preset fixed priority rule: Transmission scheduling logic: The UART transmission module continuously monitors the non-empty flags of the two FIFOs.

[0035] Priority determination: First, check if FIFO-2 is not empty. If FIFO-2 contains hardware status data, immediately read one data entry from FIFO-2, serialize it, and send it. If FIFO-2 is empty, check if FIFO-1 is not empty. If FIFO-1 contains processor debug data, read the data from FIFO-1 and send it. If both FIFOs are empty, the sending module enters an idle state and continues the loop checking.

[0036] Serialization transmission: The transmitting module sends out bytes bit by bit in parallel according to the UART protocol (start bit, data bit, stop bit). The transmission baud rate should be consistent with the original baud rate of the processor's debug serial port to ensure that external debugging tools can receive the data correctly.

[0037] Changes in hardware signals are often sudden and transient. If they are blocked for extended periods (e.g., overwhelmed by continuous software debugging information), critical hardware events may be lost or excessively delayed, affecting the accuracy of fault analysis. Processor debugging data typically has retransmission mechanisms or relatively relaxed real-time requirements; therefore, prioritizing the transmission of hardware status data by default is reasonable.

[0038] Figure 2 This is a schematic diagram of the system architecture of the method for detecting the hardware status of a board through a debug serial port in this embodiment of the application, as shown below. Figure 2 As shown, the processor debug serial port output signal is input to the UART receiving module, then the data is input to the instruction judgment module and stored in FIFO-1; multiple hardware signals are input to the hardware signal monitoring module and the data is stored in FIFO-2; high-priority data is directly sent through the UART sending module. In addition, data is selected from FIFO-1 and FIFO-2 according to preset sending rules and sent through the UART sending module.

[0039] In some embodiments, the method further includes: Before storing the processor debug data into the first first-in-first-out buffer, the processor debug data is stream-scanned, and the current fill rate and overflow risk level of the second first-in-first-out buffer are continuously monitored. The processor debug data is identified as containing a preset priority control field, which includes general high-priority keywords and specific instruction fields. Based on the identification result and the current overflow risk level of the second first-in-first-out cache, a dynamic priority score is calculated using a preset weighted decision function. When the dynamic priority score exceeds the preset hardware data priority threshold, the transmission priority of the first first-in-first-out buffer is temporarily increased to a level higher than that of the second first-in-first-out buffer, and the duration of the increase is dynamically adjusted according to the overflow risk level. During the priority promotion process, if the fill rate of the second first-in-first-out buffer is detected to be continuously increasing and exceeding the safe rate limit, the current priority promotion will be terminated in advance and the system will immediately switch to the preset priority rule.

[0040] Inside the programmable logic device (PLD), after the UART receiving module and before writing to FIFO-1, an instruction judgment module is added. This module performs a streaming scan on each received byte (i.e., analyzes as it is received, without waiting for a complete data frame). Simultaneously, this module continuously monitors the fill rate and overflow risk level of FIFO-2. Fill rate: The number of bytes written to FIFO-2 per unit time. This can be obtained by counting the number of writes within a fixed time window (e.g., 1 millisecond) using a counter. Overflow risk level: Classified according to the percentage of the current fill depth of FIFO-2 relative to the total depth, for example: Low risk: <30%; Medium risk: 30%~60%; High risk: 60%~85%; Critical risk: >85%. A keyword library is embedded internally in the PLD or configured through an external interface, including general high-priority keywords and specific instruction fields. General high-priority keywords: such as "ERROR", "FATAL", "WARN", etc., these are common high-priority indicators in processor debugging information. Specific instruction fields: such as "CPU Up" and "CPU Down", used to indicate critical processor state transitions. The instruction judgment module uses a sliding window matching method when scanning the data stream: it maintains a buffer with a length equal to the number of bytes of the longest keyword; each new byte received is moved into the buffer, and the oldest byte is discarded; the contents of the buffer are compared in parallel with each entry in the keyword library. If a match is successful, the matched keyword and its position are recorded. When the instruction judgment module detects a "CPU Up" field at the beginning of a field, the data transmission priority is set to the highest, and the data is sent to the UART transmission module first. When a "CPU Down" field is detected at the beginning of a field, the transmission priority is reduced to normal. A dynamic priority score is calculated using a preset weighted decision function. When the dynamic priority score exceeds a threshold: the transmission priority of the first FIFO buffer (FIFO-1) is temporarily increased to be higher than that of the second FIFO buffer (FIFO-2). That is, during the promotion period, the UART transmission module will prioritize reading data from FIFO-1, and will postpone transmission even if FIFO-2 is not empty. To avoid FIFO-2 overflowing due to prolonged bandwidth occupation under high hardware cache pressure, the duration needs to be dynamically adjusted according to the overflow risk level. Set a base duration (e.g., 100 microseconds). Based on the current overflow risk level, look up the duration coefficient in a table (e.g., low risk coefficient = 1.0, medium risk = 0.6, high risk = 0.3, critical risk = 0.1). Initial duration = base duration × coefficient. Further consider the rate of change of fill depth (i.e., the first derivative of the fill rate, reflecting whether the cache pressure is accelerating or slowing down): if the rate of change is positive and the absolute value exceeds the acceleration threshold, then further shorten the duration (e.g., multiply by (1 - normalized rate of change)). The final duration is the duration of the FIFO-1 high-priority state.During priority enhancement, even with the duration shortened as described above, sudden hardware signal storms may still cause the FIFO-2 write rate to far exceed expectations. Therefore, a safe rate cap is set (e.g., FIFO-2 total depth / safe time constant, such as 512 bytes / 10 milliseconds = 51.2 bytes / millisecond). The write pointer increment of FIFO-2 is sampled at microsecond intervals (e.g., every 10 microseconds) to calculate the instantaneous fill rate. If the instantaneous fill rate exceeds the safe rate cap for multiple consecutive sampling periods (e.g., 3 periods), it is determined that the fill rate is continuously rising and exceeding the limit. An early termination flag is triggered, immediately suspending FIFO-1 reads. The data source of the UART transmit module is forcibly switched to FIFO-2, and the cached hardware status data is transmitted with the highest priority. After the switch, the fill depth of FIFO-2 is continuously monitored until it drops below the safe level (e.g., below 20% of the total depth), at which point normal service checks on FIFO-1 are resumed, and dynamic priority arbitration is re-enabled.

[0041] In some embodiments, calculating the dynamic priority score using a preset weighted decision function includes: A keyword-weight mapping table is pre-configured within the programmable logic device, and a basic weight value is assigned to each preset priority control field. The processor debugging data is scanned in real time. If multiple keywords are hit consecutively within a preset time window, the corresponding basic weight value is accumulated as the original score, and the number of hits is used as a multiplier factor. Read the current fill rate of the second first-in-first-out buffer and the percentage of the current fill depth to the total depth, normalize the fill rate into a rate factor, and quantify the overflow risk level into a risk factor. The dynamic priority score is calculated by substituting the original score, the multiplier factor, the rate factor, and the risk factor into the weighted decision function.

[0042] Inside the programmable logic device, a keyword-weight mapping table is stored in registers or read-only memory (ROM). This table can be configured online via external interfaces (such as I²C, SPI, or JTAG) to adapt to the debugging needs of different products. Each record in the table contains a keyword and a basic weight value. Keyword: A string or binary signature (e.g., "ERROR" can be converted to the ASCII sequence 0x45 0x52 0x52 0x4F 0x52). Basic weight value: An integer representing the importance of the keyword. For example: "FATAL": 12; "CPU_Up": 10; "ERROR": 8; "WARN": 4; "CPU_Down": 2 (normal priority). The instruction judgment module uses a sliding window matching mechanism: it maintains a shift register with a length equal to the number of bytes of the longest keyword. Each time a new byte is received from the UART receiving module, it is shifted into the register, and the oldest byte is discarded. The byte sequence in the register is then compared in parallel with all keywords in the mapping table (using content-addressable memory CAM or combinational logic comparators). A time window counter is set up, with a configurable window length (e.g., 10 milliseconds). This counter is driven by a high-speed clock inside the programmable logic device. Within the window, each keyword hit adds its base weight value to the raw score register, and the hit count is incremented by 1. When the window ends, the raw score and hit count are locked and used for subsequent calculations; then the window is cleared, and the next window begins. A multiplier factor (i.e., the hit count) is used to amplify the raw score. For example, if "ERROR" occurs 3 times consecutively within 10 milliseconds, the raw score = 8 × 3 = 24, the multiplier factor = 3, and the final product is 72. This highlights the importance of event frequency—when errors occur frequently, the software log should be sent out more quickly to analyze the root cause. Fill rate: The number of bytes written to FIFO-2 per unit time. This can be achieved using a rate counter: reading the write pointer increment of FIFO-2 every 1 millisecond (or other fixed period) to obtain the number of bytes written in that period. Maximum allowed rate: Usually determined by the baud rate of the UART transmit module. For example, at a baud rate of 115200, the theoretical maximum transmission rate is approximately 11.5 KB / s (about 11.5 bytes / millisecond). However, the write rate of FIFO-2 may be affected by sudden changes in hardware signals, and the theoretical upper limit is much higher. Therefore, a safe upper limit is set, such as 80% of the UART transmission rate (about 9.2 bytes / millisecond). Normalization: Rate factor = Actual fill rate / Safe upper limit, truncated to the [0, 1] interval. When the actual rate approaches the upper limit, the rate factor approaches 1, indicating high pressure on the hardware data cache, and the likelihood of software priority should be reduced. Fill depth percentage = FIFO-2 current used depth / FIFO-2 total depth.Overflow risk levels can be divided into several grades, for example: Low risk: <30% → Risk factor = 0.2; Medium risk: 30%~60% → Risk factor = 0.5; High risk: 60%~85% → Risk factor = 0.8; Critical risk: >85% → Risk factor = 1.0. The role of the risk factor is: when FIFO-2 is close to full, even if the software debugging data contains high-weight keywords, the software priority should be cautiously increased, otherwise it may lead to hardware data loss. A typical form of the weighted decision function is as follows: Dynamic priority score = (Original score × Multiplier factor) × (1 - Rate factor) × (1 - Risk factor). Original score × Multiplier factor: The basic value item, reflecting the importance and frequency of the software debugging data. Example: Original score = 24, multiplier factor = 3 → base value = 72; rate factor = 0.6, risk factor = 0.5 → (1-0.6) = 0.4, (1-0.5) = 0.5 → score = 72 × 0.4 × 0.5 = 14.4. If the threshold is set to 15, then 14.4 < 15, and software priority is not triggered; conversely, if there is no hardware pressure (rate factor = 0, risk factor = 0), score = 72 > 15, and triggering occurs. Complete process example: FIFO-2 total depth = 512 bytes, current fill depth = 400 bytes (78%), risk level = high risk (factor = 0.8), fill rate = 8 bytes / millisecond, safe rate limit = 10 bytes / millisecond, rate factor = 0.8. Keyword hit: Hit "ERROR" (weight 8) twice and "FATAL" (weight 12) once within 10 milliseconds, original score = 8 + 8 + 12 = 28, multiplier factor = 3. Base value = 28 × 3 = 84. Dynamic priority score = 84 × (1 - 0.8) × (1 - 0.8) = 84 × 0.2 × 0.2 = 3.36. The threshold is set to 10. If 3.36 < 10, then software priority is not increased; hardware priority remains. If the hardware pressure is very small (rate factor = 0.1, risk factor = 0.2), then the score = 84 × 0.9 × 0.8 = 60.48 > 10, triggering software priority.

[0043] In some embodiments, the step of dynamically adjusting the duration of the increase based on the spillover risk level includes: A basic duration register and a risk-time mapping lookup table are set within the programmable logic device. In the risk-time mapping lookup table, a corresponding duration coefficient is configured for each overflow risk level. When a priority increase is triggered, the overflow risk level of the current second first-in-first-out buffer is read, the corresponding duration coefficient is obtained from the risk-time mapping lookup table, and the value of the base duration register is multiplied by the duration coefficient to obtain the preliminary adjusted actual duration. Read the current fill depth change rate of the second first-in-first-out buffer. If the current fill depth change rate is positive and the absolute value exceeds the preset acceleration threshold, then correct the actual duration based on the normalized value of the current fill depth change rate. The corrected actual duration is taken as the final boost duration and output to the priority scheduling module as the retention time of the high priority state of the first first-in-first-out buffer.

[0044] Inside a programmable logic device, two key elements are set via registers or read-only memory (ROM): (1) a base duration register. This stores a base time value, such as 100 microseconds, 500 microseconds, or 1 millisecond. This value can be configured online via an external interface (such as I²C, SPI, or JTAG) as required by the system. The base duration represents the software priority hold duration in “no risk” or “very low risk” situations. (2) a risk-time mapping lookup table. This table maps overflow risk levels (e.g., low, medium, high, urgent) to corresponding duration coefficients (a decimal less than or equal to 1). Typical mapping examples: Low risk - fill depth percentage < 30% - duration coefficient 1; Medium risk - fill depth percentage 30%~60% - duration coefficient 0.6; High risk - fill depth percentage 60%~85% - duration coefficient 0.3; Urgent risk - fill depth percentage > 85% - duration coefficient 0.1.

[0045] Read the current overflow risk level: This level is maintained in real time by an independent monitoring module and calculated based on the fill depth percentage of FIFO-2 (e.g., updated every 1 microsecond). The read operation only requires one clock cycle to obtain the current risk level code (e.g., 2-bit binary: 00=low, 01=medium, 10=high, 11=urgent). Look up the duration coefficient: Using the risk level as the address index, access the risk-time mapping lookup table and output the corresponding coefficient (e.g., 0.6). The lookup table can be implemented using combinational logic (multiplexer), with extremely low latency. Multiply to obtain the initial duration: Initial duration = base duration register value × duration coefficient. For example: base duration = 1000 microseconds, coefficient = 0.3 → initial duration = 300 microseconds. Multiplication can be implemented in programmable logic using a multiplier or shift-address. Since the coefficient is usually a negative power of 2 (e.g., 0.5, 0.25) or a decimal, the coefficient can be pre-represented as a fraction (e.g., 3 / 10) and completed using integer multiplication and division.

[0046] Classifying risk levels solely based on the current percentage of fill depth is static and fails to reflect the changing trend of the fill rate. For example, in scenario A: the current fill depth is 70% (high risk), but the fill rate is decreasing (hardware events are gradually subsiding). In this case, the software priority time can be appropriately extended because the overflow risk is decreasing. In scenario B: the current fill depth is also 70%, but the fill rate is rising sharply (sudden hardware storm). In this case, even a duration of 300 microseconds may be too long and needs further compression. Therefore, the fill depth change rate (i.e., the first derivative of the fill rate) is introduced to predict the fill trend in the short term and dynamically adjust the initial duration.

[0047] Calculate the fill depth change rate: Fill depth change rate = (Current fill rate - Previous fill rate) / Sampling interval. In the hardware implementation, the write pointer of FIFO-2 can be sampled every 1 millisecond, the fill rate is calculated from the difference between two samples, and then the change rate is obtained from the difference. The change rate can be positive or negative: a positive value indicates filling acceleration (more hardware events), and a negative value indicates filling deceleration (fewer hardware events). Determine whether correction is needed: Correction is only performed when the change rate is positive and the absolute value exceeds a preset acceleration threshold. The acceleration threshold is used to filter out small fluctuations, for example, it is set to 0.5 bytes / millisecond². If the change rate is less than the threshold, the trend is considered not obvious and no correction is performed. If the change rate is negative (fill deceleration), it means that the risk is decreasing. At this time, there is no need to further shorten the duration, and it can even be considered to extend it. However, this scheme is conservative and does not perform extension correction, only handling the positive acceleration case. Correction based on normalized change rate: Normalize the change rate to the [0, 1] interval: Normalized change rate = min(actual change rate / maximum expected change rate, 1.0). The maximum expected rate of change can be estimated based on the system's maximum hardware signal toggle rate (e.g., the peak write rate when all monitored signals toggle simultaneously). Correction formula: Corrected duration = Initial duration × (1 - Normalized rate of change × Correction strength coefficient). The correction strength coefficient (e.g., 0.5) is used to control the correction magnitude and avoid over-correction. For example: Initial duration = 300 microseconds, Normalized rate of change = 0.4, Correction strength = 0.5 → Correction factor = 1 - 0.2 = 0.8 → Final duration = 240 microseconds. Hardware implementation points: The calculation of the rate of change requires storing the fill rate of the previous moment, which can be done using registers; multiplication and normalization can be approximated using shift and addition to avoid floating-point operations; the acceleration threshold, maximum expected rate of change, and correction strength coefficient can all be configured online via registers.

[0048] The corrected actual duration is written to a hardware timer driven by a high-speed clock (e.g., 100MHz, 10ns period) within the programmable logic device. The timer count = final duration / clock period. For example, 240 microseconds / 10ns = 24000 clock periods. The timer is started, and the priority scheduling module is notified simultaneously. The scheduling module begins reading from and sending data from FIFO-1 (software data), ignoring the non-empty flag of FIFO-2 during this period (i.e., forcing software priority). The timer counts down, and a timeout signal is generated when the count reaches 0. After the timeout, the default priority is restored. Upon receiving the timeout signal, the scheduling module immediately stops forcing software priority and reverts to the default rule of "prioritizing hardware data transmission when FIFO-2 is not empty." If an early termination condition is triggered during timer operation (e.g., continuous exceedance of the fill rate limit), the timer is reset, and the system switches to hardware priority mode early (refer to the emergency decision mechanism in section 8 above). The duration is logged (optional). The final duration value is written to a log register for external reading or subsequent analysis. This helps in debugging and optimizing parameter configuration.

[0049] In some embodiments, the method further includes: The receiving end acquires the aggregated data stream output via the processor debug serial port, and distinguishes the processor debug data frame and hardware status data frame in the aggregated data stream according to the preset frame header identifier. Extract the timestamp field and the hexadecimal encoded status word field from the hardware status data frame. The bit width of the status word field is equal to the number of monitored hardware signals, and each bit corresponds to the current logic level of a hardware signal. The hexadecimal representation of the status word field is converted into a binary bit string, and then XORed bit by bit with the previously received status word to generate a change bit mask. Bits with a value of one in the change bit mask indicate hardware signals that have changed. An event record is generated based on the changed bitmask and the timestamp. The event record includes the time when the change occurred, the index of the signal bit that changed, and the changed level value.

[0050] The receiving end continuously reads a byte stream via a serial port driver (e.g., Python's pyserial, C's termios) and stores it in a circular buffer. A finite state machine is implemented to scan the buffer byte by byte: the initial state is "searching for frame header." When the first frame header byte (e.g., 0x7E) is read, it enters the "acknowledging frame header" state. If subsequent bytes match a preset complete frame header sequence (e.g., the next byte after 0x7E is 0xAA), then it is confirmed that this is the beginning of a hardware status data frame; otherwise, all previous bytes are treated as ordinary debug data output. Hardware status data frames typically have a fixed length (e.g., 2-byte frame header + 6-byte timestamp + N-byte status word + 1-byte checksum). Once the frame header is acknowledged, the receiving end extracts the complete frame from the buffer according to the frame length and then performs subsequent parsing. The remaining bytes are output as processor debug data to the text log.

[0051] Extract the timestamp and status word fields from the hardware status data frame. The data frame includes a frame header, timestamp, status word, and checksum. Timestamp extraction: Read 6 bytes and combine them into a 48-bit integer. This value represents the number of nanoseconds since system startup or synchronization pulse. For example, 0x00022D22EC, after being converted to decimal, can be further converted to human-readable units such as milliseconds and microseconds. Status word field extraction: Based on the pre-configured number of hardware signals (e.g., 32 signals require 4 bytes, 64 signals require 8 bytes, and a maximum of 128 signals requires 16 bytes), read the corresponding length of data. This data is represented in hexadecimal encoding, for example, 5FFDE3F20C3F70FC (16 bytes, i.e., 128 bits). Each bit in the status word represents the current logic level (0 or 1) of a hardware signal. By comparing the currently received status word with the previously received status word, the changed signal can be quickly located. Convert the hexadecimal string of the status word field to a binary bit string. For example: 5FFDE3F20C3F70FC → 128-bit binary. A lookup table method (each hexadecimal character corresponds to 4 binary bits) can be used for fast conversion. The receiving end maintains a reference status word variable, initially set to all zeros. After parsing each frame, the current status word is saved as the reference for the next frame. The current binary bit string is XORed bit by bit with the reference status word. In the XOR result, a bit being 1 indicates that the corresponding hardware signal has changed (0→1 or 1→0), and a result of 0 indicates that the signal has not changed. This result is called the change bitmask. For example, the first line of status word: 5FFDE3F20C3F70FC; the second line of status word: 5FFFFFF20C3F70FC; after bit by bit XOR, only the 4th, 5th, and 6th hexadecimal bits (corresponding to bits 13~24 of the binary number) have changed. In the generated change bitmask, these bits are set to 1. The change bitmask and timestamp are combined into a structured event record for easy subsequent processing (such as visualization and diagnosis). Each event log should contain three core pieces of information: the time the change occurred, the signal that changed (signal bit index), and the changed level value (0 or 1). Each bit of the changed bitmask is checked cyclically (from bit 0 to bit N-1, where N is the total number of monitored signals). If a bit is 1, it indicates that the signal has changed. The changed level value is read directly from the corresponding bit of the current status word (0 or 1). The level before the change can be obtained from the reference status word (i.e., the previous status word), but the event log usually only needs the changed value because it can be inferred by combining the timestamp and the direction of change. For each changed signal bit, a record is generated, with a format such as: {timestamp: 36512.492ms, signal_index: 16, new_value: 1}.Alternatively, multiple changes can be merged into a single record (if the changes occur at the same timestamp): {timestamp: 36512.492ms, changes: [(16, 1), (20, 1), (21, 1), (22, 0), (24, 1)]}. These event records can be stored in memory, written to a file, or directly fed into the visualization module. Meanwhile, a reference status word is retained for the next comparison.

[0052] In some embodiments, the method further includes: A signal mapping table is pre-configured at the receiving end. The signal mapping table records the mapping relationship between each signal bit index and the corresponding hardware signal name and signal type. The signal types include reset signal, power status indication signal, alarm signal, status gene signal, control signal, and interface signal. For each signal bit index in the event record, query the signal mapping table to obtain the corresponding hardware signal name and signal type, and replace the signal bit index with the hardware signal name to generate change event text; On the same user interface, with a unified time axis as the horizontal axis, the processor debugging data is displayed in the first display area in the form of a scrolling text stream, and the hardware signal level changes corresponding to the change event text are displayed in the second display area in the form of a waveform or level transition marker. In response to the user selecting a level transition marker in the second display area, the processor debug data entry with the timestamp closest to the level transition marker is highlighted in the first display area, thereby achieving cross-location of hardware events and software logs.

[0053] Maintain a configuration file or database on the receiving end (e.g., analysis software on a PC). Each record contains: signal bit index (starting from 0 or 1), hardware signal name (string, such as "CPU_RESET_N"), and signal type (enumeration: reset signal, power status indicator signal, alarm signal, status gene signal, control signal, interface signal, etc.). Example (CSV format): Bit index - signal name - signal type: 0, PWR_GOOD, power status indicator signal; 1, SYS_RESET, reset signal; 2, OVER_TEMP_ALERT, alarm signal; 3, STATUS_GENE, status gene signal; 4, CTRL_SIG, control signal; 5, IF_SIG, interface signal. Generate change event text based on the generated event records. Each event record contains a timestamp, a list of changed signal bit indices, and the changed level value. For example: [36839.349ms] Reset signal changes from 0 to 1 [36839.349ms] Power status indicator signal changes from 0 to 1. Traverse each changed bit in the event log: For each signal bit index in the event log (e.g., 16, 20, 21, 22, 24), query the signal mapping table: Using the bit index as the key, search the mapping table to obtain the corresponding signal name and signal type. If a bit index is not defined in the table, use the default name (e.g., "Unknown signal

[16] "). Determine the change direction: The level value before the change is needed to describe "from X to Y". The event log only directly contains the level value after the change, but the level value before the change can be obtained from the previous status word. Compare the value before the change with the value after the change to generate the direction text: "from 0 to 1" (rising edge) or "from 1 to 0" (falling edge). Format the output: Combine the timestamp (converted to easily readable milliseconds or microseconds), signal name, and change direction into a single line of text. For example: [36839.349ms] Reset signal rising edge (0→1) [36839.349ms] Alarm signal falling edge (1→0). To reduce redundancy, all changes occurring at the same timestamp can be merged into a single text message, for example: [36839.349ms] Reset signal ↑, Power status indicator signal ↑, Alarm signal ↓. The analysis software's main window is divided into two areas (vertically or horizontally): The first display area (software log area): displays processor debugging data in a scrolling text stream format. Each line contains a timestamp (if any) and log content. This area is similar to traditional serial port debugging tools. The second display area (hardware waveform area): graphically displays changes in hardware signal levels over time. It can use one of the following two formats (or be switchable): Waveform graph: Each signal has a horizontal line, high level is high, low level is low, and vertical lines connect transition points; suitable for a small number of signals (e.g., up to 16). Level transition markers: Transition points are marked on the time axis with vertical lines or triangles; hovering the mouse displays the signal name and transition direction.Suitable for overviewing large numbers of signals (hundreds). Two areas share the same time axis (horizontal axis), scaled in absolute time (milliseconds / microseconds) or relative time (from the start of acquisition). Different time periods can be browsed by zooming and panning. When the user clicks (or hovers the mouse over) a level transition marker in the hardware waveform area, the software log area automatically scrolls and highlights the processor debug data entry closest to that transition time. In the second display area, a click event is registered for each transition marker (or each change point on the waveform). Upon clicking, the timestamp of that transition is obtained (e.g., 36839.349ms). The software log area maintains a time-sorted list of entries (each entry contains a timestamp and text content). Using binary search or sequential search (sequential scanning is acceptable due to the small data volume), the entry with the smallest difference from the target timestamp is found. If two entries are equidistant (e.g., the first differs by 0.1ms, the second by 0.1ms), both can be highlighted or the first one can be selected. The background color of the selected software log entry's row is changed to yellow or a border is added. Automatically scrolls the software log area, placing the entry within the visible range (usually centered or at the top). Optional: Simultaneously highlights the corresponding transition point in the hardware waveform area, creating bidirectional positioning. Supports using the up and down arrow keys to switch between adjacent hardware transitions, synchronously moving the software highlight. Supports exporting software logs and hardware events within the selected time window for reporting purposes.

[0054] In some embodiments, the method further includes: A diagnostic rule base is set at the receiving end. The diagnostic rule base contains multiple diagnostic rules, and each diagnostic rule is associated with a signal bit change pattern and a corresponding fault description text. For each change bitmask in the event record, the change bitmask is combined with the previously received status word to restore the value of each bit before and after the change, and a change detail list is generated according to the signal mapping table. The change detail list includes the signal name, the level before the change, the level after the change, and the change time. Each change in the change details list is matched with all rules in the diagnostic rule base. If a match is successful, a diagnostic entry is generated. The diagnostic entry includes the matched fault description text, suggested troubleshooting steps, and associated processor debug data fragment index. All generated diagnostic entries are compiled into a fault diagnosis report in chronological order, and the report is previewed and exported on the user interface.

[0055] Each diagnostic rule includes the following fields: Rule ID, signal bit change pattern, fault description text, suggested troubleshooting steps, and associated signal type. Restore the value of each bit before and after the change: For each bit in the changed bitmask that is 1 (i.e., the signal bit that has changed), read the level value before the change from the previous status word, and read the level value after the change from the current status word. For example: previous status word bit 16 = 0, current status word bit 16 = 1 → before change = 0, after change = 1. Query the mapping table: Obtain the signal name and signal type based on the bit index. For example, bit 16 corresponds to "reset signal", type "reset signal". Construct change detail entries: Each entry includes the change time (timestamp), signal name, signal type, level before change, level after change, and change direction (rising edge or falling edge). Example: {Time: 36839.349ms, Signal: Reset signal, Type: Reset signal, Before: 0, After: 1, Direction: Rising edge}. Generate a change detail list: Organize all change entries into a list in chronological order for subsequent matching. Traverse the change details list: For each change (or a group of changes within a time window), match it against each rule in the rule base. Pattern matching: Single signal rule: Check if the signal name and direction of the change match the rule. Combination rule: Within a specified time window (e.g., 1 milliseconds before and after), check if multiple signal changes satisfy the combination condition. This can be implemented using a sliding window or state machine. Timing rule: Calculate the time difference between two changes and determine if it is within the constraints. Generate a diagnostic entry upon successful matching: Each diagnostic entry contains the matched rule ID and fault description text, suggested troubleshooting steps, the timestamp of the event that triggered the diagnosis, and the associated processor debug data fragment index (i.e., the software log line number or offset near that time). Example: {rule_id:"R001", fault_desc:"Abnormal reset detected: power state dropped before reset", suggestions:"1. Check input power stability; 2. Check watchdog log; 3. Check reset signal path", timestamp:36839.349ms, related_log_indices:[1024, 1025, 1026] / / line numbers in software log}. Deduplication and merging: To avoid the same fault being reported repeatedly in a short period, a silent window can be set (e.g., the same rule is only reported once within 10ms). Organize all diagnostic entries into a complete report for engineers to archive, share, or as evidence of problem resolution. Report content includes: Summary information: board model, start / end time of data collection, total number of events, number of diagnostic entries, etc. Diagnostic entry list: List all diagnostic entries in chronological order, each entry includes a fault description, occurrence time, and suggested troubleshooting steps. Related data: Each diagnostic entry can be accompanied by a corresponding software log fragment (e.g., the first and last 10 lines) and a hardware waveform screenshot.Statistical charts: optional, such as statistics on the frequency of various faults, ranking of the number of signal changes.

[0056] The method for detecting the hardware status of a board through a debug serial port in the embodiments of this application has been described above. The computer system in the embodiments of this application will be described in detail below in conjunction with the above method for detecting the hardware status of a board through a debug serial port.

[0057] Please see Figure 3 This is a schematic diagram of an exemplary hardware structure of a computer system in an embodiment of this application.

[0058] In some embodiments, the computer system 300 includes a computer device, which may be a terminal device. The computer device includes a processor 301, a memory 302, a sensor module 303, a communication module 304, an input device 305, and an output device 306 connected via a system bus. The processor 301 of the computer device provides computing and control capabilities. The memory 302 of the computer device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database is used to store data.

[0059] Those skilled in the art will understand that Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0060] In some embodiments of this application, a computer-readable storage medium is provided, including instructions that, when executed on the computer system 300, cause the computer system 300 to perform the method of detecting the hardware status of a board via a debug serial port as described in this application.

[0061] In some embodiments of this application, a computer program product is also provided, which, when run on a computer system 300, causes the computer system 300 to execute the method of detecting the hardware status of a board through a debug serial port as described in this application.

[0062] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0063] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0064] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method for detecting the hardware status of a circuit board via a debug serial port, characterized in that, include: The programmable logic device receives processor debugging data output by the processor on the board, the processor debugging data including the software running status, and stores the processor debugging data in the first first-in-first-out buffer in the programmable logic device. The programmable logic device continuously samples multiple hardware signals on the board. When a change in the state of any hardware signal is detected, the state data of all the hardware signals is obtained, a timestamp is added to the state data to form hardware state data, and the hardware state data is stored in the second first-in-first-out buffer in the programmable logic device. Based on a preset priority rule, data is selected from the first FIFO buffer and the second FIFO buffer. The selected data is serialized through the same serial transmission module within the programmable logic device and then transmitted externally via the processor debug serial port. The preset priority rule includes: when the second FIFO buffer is not empty, the hardware status data cached in the second FIFO buffer is transmitted; otherwise, the processor debug data cached in the first FIFO buffer is transmitted.

2. The method according to claim 1, characterized in that, The method further includes: Before storing the processor debug data into the first first-in-first-out buffer, the processor debug data is stream-scanned, and the current fill rate and overflow risk level of the second first-in-first-out buffer are continuously monitored. The processor debug data is identified as containing a preset priority control field, which includes general high-priority keywords and specific instruction fields. Based on the identification result and the current overflow risk level of the second first-in-first-out cache, a dynamic priority score is calculated using a preset weighted decision function. When the dynamic priority score exceeds the preset hardware data priority threshold, the transmission priority of the first first-in-first-out buffer is temporarily increased to a level higher than that of the second first-in-first-out buffer, and the duration of the increase is dynamically adjusted according to the overflow risk level. During the priority promotion process, if the fill rate of the second first-in-first-out buffer is detected to be continuously increasing and exceeding the safe rate limit, the current priority promotion will be terminated in advance and the system will immediately switch to the preset priority rule.

3. The method according to claim 2, characterized in that, The calculation of the dynamic priority score using a preset weighted decision function includes: A keyword-weight mapping table is pre-configured within the programmable logic device, and a basic weight value is assigned to each preset priority control field. The processor debugging data is scanned in real time. If multiple keywords are hit consecutively within a preset time window, the corresponding basic weight value is accumulated as the original score, and the number of hits is used as a multiplier factor. Read the current fill rate of the second first-in-first-out buffer and the percentage of the current fill depth to the total depth, normalize the fill rate into a rate factor, and quantify the overflow risk level into a risk factor. The dynamic priority score is calculated by substituting the original score, the multiplier factor, the rate factor, and the risk factor into the weighted decision function.

4. The method according to claim 3, characterized in that, The duration of the dynamic adjustment based on the spillover risk level includes: A basic duration register and a risk-time mapping lookup table are set within the programmable logic device. In the risk-time mapping lookup table, a corresponding duration coefficient is configured for each overflow risk level. When a priority increase is triggered, the overflow risk level of the current second first-in-first-out buffer is read, the corresponding duration coefficient is obtained from the risk-time mapping lookup table, and the value of the base duration register is multiplied by the duration coefficient to obtain the preliminary adjusted actual duration. Read the current fill depth change rate of the second first-in-first-out buffer. If the current fill depth change rate is positive and the absolute value exceeds the preset acceleration threshold, then correct the actual duration based on the normalized value of the current fill depth change rate. The corrected actual duration is taken as the final boost duration and output to the priority scheduling module as the retention time of the high priority state of the first first-in-first-out buffer.

5. The method according to claim 1, characterized in that, The method further includes: The receiving end acquires the aggregated data stream output via the processor debug serial port, and distinguishes the processor debug data frame and hardware status data frame in the aggregated data stream according to the preset frame header identifier. Extract the timestamp field and the hexadecimal encoded status word field from the hardware status data frame. The bit width of the status word field is equal to the number of monitored hardware signals, and each bit corresponds to the current logic level of a hardware signal. The hexadecimal representation of the status word field is converted into a binary bit string, and then XORed bit by bit with the previously received status word to generate a change bit mask. Bits with a value of one in the change bit mask indicate hardware signals that have changed. An event record is generated based on the changed bitmask and the timestamp. The event record includes the time when the change occurred, the index of the signal bit that changed, and the changed level value.

6. The method according to claim 5, characterized in that, The method further includes: A signal mapping table is pre-configured at the receiving end. The signal mapping table records the mapping relationship between each signal bit index and the corresponding hardware signal name and signal type. The signal types include reset signal, power status indication signal, alarm signal, status gene signal, control signal, and interface signal. For each signal bit index in the event record, query the signal mapping table to obtain the corresponding hardware signal name and signal type, and replace the signal bit index with the hardware signal name to generate change event text; On the same user interface, with a unified time axis as the horizontal axis, the processor debugging data is displayed in the first display area in the form of a scrolling text stream, and the hardware signal level changes corresponding to the change event text are displayed in the second display area in the form of a waveform or level transition marker. In response to the user selecting a level transition marker in the second display area, the processor debug data entry with the timestamp closest to the level transition marker is highlighted in the first display area, thereby achieving cross-location of hardware events and software logs.

7. The method according to claim 5, characterized in that, The method further includes: A diagnostic rule base is set at the receiving end. The diagnostic rule base contains multiple diagnostic rules, and each diagnostic rule is associated with a signal bit change pattern and a corresponding fault description text. For each change bitmask in the event record, the change bitmask is combined with the previously received status word to restore the value of each bit before and after the change, and a change detail list is generated according to the signal mapping table. The change detail list includes the signal name, the level before the change, the level after the change, and the change time. Each change in the change details list is matched with all rules in the diagnostic rule base. If a match is successful, a diagnostic entry is generated. The diagnostic entry includes the matched fault description text, suggested troubleshooting steps, and associated processor debug data fragment index. All generated diagnostic entries are compiled into a fault diagnosis report in chronological order, and the report is previewed and exported on the user interface.

8. A computer system comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the steps of the method according to any one of claims 1-7.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1-7.

10. A computer program product comprising a computer program / instructions, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1-7.

Images