Debugging method and system for hanging of embedded system

Abstract

This invention discloses a hang-up debugging method and system for embedded systems, relating to the field of embedded system technology. The method configures a Debugbus module and a Debugscan module within the embedded system's SOC chip, and an external host receiver. The Debugbus module operates independently of the system bus and is used to collect register information that needs to be observed when the system bus is hanged. The Debugscan module is used to send the register information collected by the Debugscan module to the host receiver. The Debugscan module only needs to be turned on and off; when it is on, it obtains register information from the Debugbus module and transmits it to the host receiver for parsing; when it is off, it does not transmit information. This invention can also dump system information when the bus is hanged, reducing the demand on the embedded system's internal RAM, thus saving system costs while providing debugging functionality.

Description

Technical Field

[0001] This invention relates to the field of embedded system technology, and in particular to a hang-up debugging method and debugging system for embedded systems. Background Technology

[0002] Embedded devices typically employ highly integrated dedicated chips and streamlined architectures. Unlike general-purpose computers (such as personal computers and servers), embedded devices are not designed to run various user-installed applications; their functions and operations are usually embedded within the device itself. A typical embedded device consists of two main parts: hardware and software.

[0003] To adapt to specific application scenarios (such as industrial control, automotive electronics, and smart terminals), hardware resources (including processor computing power, memory capacity, and peripheral interfaces) are often customized. Furthermore, to ensure stability and cost control, redundant debugging hardware channels are often not reserved. Functionally, embedded devices aim to "complete specific core tasks," with core logic highly focused on dedicated business functions (such as sensor data acquisition, device status control, and real-time signal processing). The system software (including operating systems and drivers) within embedded devices is also lightweighted and tailored to this task, and general debugging modules (such as complex log monitoring and multi-node status feedback functions) are often simplified or omitted. In terms of the working environment, embedded devices are often deployed in non-ideal scenarios such as industrial sites, automotive environments, and outdoor terminals, potentially facing external interference such as electromagnetic interference, voltage fluctuations, and drastic temperature and humidity changes. These interferences can easily trigger hardware-level anomalies. These characteristics mean that if an embedded device experiences a "hang-up" failure due to external interference, hardware failure, or software logic conflicts during operation, the embedded system inside the device will directly fall into a complete standstill.

[0004] In other words, the system bus of an embedded device may freeze during operation. As a critical channel connecting various components of the embedded device, a freeze in the system bus will prevent the device from accessing any system information. This is because embedded devices typically have a compact architecture, and communication between components heavily relies on the system bus. When the bus freezes, the processor cannot interact with memory, peripherals, etc., rendering the device paralyzed and causing it to malfunction. Specifically, on the one hand, due to the streamlined hardware architecture and lack of redundant debugging channels, traditional access paths relying on external hardware debuggers (such as JTAG and SWD) will be interrupted by a bus freeze, making it impossible to read low-level hardware information such as processor registers and memory data. On the other hand, when using lightweight software to monitor and provide system status logs and real-time process monitoring, the software relies on the system bus. If the bus freezes, these monitoring modules will also fail, unable to output critical information such as system operation, task scheduling, and peripheral interactions before the failure occurred. These two factors make it impossible for R&D personnel to determine whether the fault originates from physical damage to the bus or abnormal triggering of peripherals at the hardware level, or from driver vulnerabilities or task priority conflicts at the software level; they also cannot trace the system's operating trajectory before the fault occurred, thus falling into the dilemma of "difficulty in reproducing the fault, difficulty in locating the root cause, and difficulty in solving the problem".

[0005] Common solutions for troubleshooting system crashes include:

[0006] Option 1 is similar to the sysdump debugging function in the Linux kernel, which dumps the current information to RAM, and then saves the dumped information to a medium for analysis after a reset.

[0007] Option 2 involves adding marker information to the critical path. This marker information is stored in the internal RAM of the embedded system. When the system freezes, the embedded system is reset and the marker information is printed out.

[0008] Option 3 involves creating a security island system independent of the embedded system. When the embedded system encounters a problem, the watchdog module notifies the security island system to record the abnormal situation.

[0009] The above solutions have the following drawbacks: With Solution 1, if the system bus freezes, the entire system becomes unusable, making information dumping impossible. While Solution 2 can dump information when the system bus freezes, due to system performance considerations, it's not possible to add markers to all suspected points during the design phase. If markers are not added where they should, important debugging information may be missed. Furthermore, the configuration of markers is limited by the size and cost of the internal RAM. Solution 3 can also dump information when the system bus freezes, but the separate subsystem (the security island system) significantly impacts cost. Since these are two separate systems, the security island system cannot access CPU internal register information, and the two systems are connected by a bus. If this bus also freezes, system information cannot be obtained. Most importantly, if the system bus freezes, the security island system will also freeze when reading information from the embedded system, leading to a situation similar to Solution 1, thus failing to solve the bus-level freeze problem.

[0010] In summary, how to leverage the characteristics of embedded devices to solve the problem of being unable to access system information and thus hindering debugging when the embedded system bus is stuck is a technical problem that urgently needs to be solved. Summary of the Invention

[0011] The purpose of this invention is to overcome the shortcomings of existing technologies and provide a low-cost method and system for debugging embedded systems during bus hang-up. This invention can dump system information even when the bus is hang-up, reducing the demand on the embedded system's internal RAM and eliminating the need for a separate dedicated debugging subsystem. Simultaneously, it can obtain key information from the CPU's internal registers, providing debugging functionality while saving system costs.

[0012] To achieve the above objectives, the present invention provides the following technical solution:

[0013] A hang-up debugging method for an embedded system, which configures a debugbus module and a debugscan module inside the SOC chip of the embedded system, and configures a host receiver outside the embedded system.

[0014] The Debugbus module is independent of the system bus and is used to collect register information of the registers to be observed according to the preset registers when the system bus is hung.

[0015] The Debugscan module connects to the Debugbus module and is used only to access the Debugbus module to send the register information collected by the Debugbus module to the host receiver outside the embedded system. The Debugscan module is configured with an on state and a off state. In the on state, Debugscan starts working, obtains register information from the Debugbus module and transmits the register information to the host receiver. In the off state, the Debugscan module does not transmit information.

[0016] The receiver described above is equipped with a parsing unit, which is used to receive and parse the register information transmitted by the Debugscan module.

[0017] Furthermore, the Debugscan module transmits register information to the host receiver via a single-wire transmission, and the single-wire transmission physical layer protocol is compatible with the serial bus protocol; the host computer uses a general serial port tool for reception.

[0018] Furthermore, it also includes a register configuration module, which is used to assign a unique identification number (ID) to each register to be observed according to the registers selected by the user during the chip design stage to form a register observation list. The register observation list records the names of the registers to be observed and the IDs corresponding to each register; and to store the register observation list in the Debugbus module.

[0019] The Debugscan module is equipped with a serial shift register.

[0020] When the system bus is suspended, the Debugscan module is triggered to enter the open state. The Debugscan module accesses the Debugbus module through the ID, obtains the value of the register to be observed from the Debugbus module, and puts the ID and the corresponding value into the internal serial shift register and transmits it to the chip pin according to the single-wire protocol to the host receiver.

[0021] Furthermore, the method for placing the ID and its corresponding value into the internal serial shift register is as follows: according to the pre-configured frame format, the ID and its corresponding value are placed into the internal serial shift register, and the data format of the frame format is [START][ID][LEN][PAYLOAD][CRC] .

[0022] The START field is used to configure the frame start flag, using a preset fixed number of bytes, and the length of the START field is configured to be 1 byte; the ID field is used to configure the module ID of the register, and the length of the ID field is configured to be multiple bytes; the LEN field is used to configure the payload length, and the payload length takes a fixed value between 0 and 255 bytes, and the length of the LEN field is configured to be 1 byte; the PAYLOAD field is used to configure the specific data content; the CRC field is used to configure the CRC-8 check information, and the check covers the [ID] [LEN] [PAYLOAD] information, and the length of the CRC field is configured to be 1; the END field is used to configure the frame end flag, using a preset fixed number of bytes, and the length of the END field is configured to be 1.

[0023] Furthermore, the steps for the host receiver to parse the data frame include:

[0024] Start byte received;

[0025] Determine if it is the preset frame start flag; if not, determine an abnormal situation, discard the data, wait to receive characters until the start byte is received again, and return to the execution step to receive the start byte; if yes, read the ID field and LEN field.

[0026] Continue to check if LEN is equal to the preset fixed value; if not, it is determined to be an abnormal situation, discarded, and wait to receive characters until the start byte is received again, then return to the execution step to receive the start byte; if yes, read LEN PAYLOAD data, and then read the CRC.

[0027] Check if the CRC is correct; if not, determine an abnormal situation, discard the character, wait to receive characters until the start byte is received again, and return to the execution step to receive the start byte; if yes, receive the end character.

[0028] Determine if it is the preset end-of-frame marker; if not, determine an abnormal situation, discard the data, wait to receive characters until the start byte is received again, and return to the execution step to receive the start byte; if yes, save the ID and the corresponding return value, and return to the execution step to receive the start byte.

[0029] Furthermore, in the register observation list, the ID of the first register is 0, and the ID of the subsequent registers is the ID of the previous register plus 1;

[0030] At this time, the Debugscan module is implemented by hardware logic. After the Debugscan module enters the open state, it performs the following steps:

[0031] S100, module initialization ID=0;

[0032] S200, send the current ID to the Debugbus module;

[0033] S300 receives the value of the register corresponding to the aforementioned ID from the Debugbus module;

[0034] S400 places the ID and its corresponding value into a serial shift register and transmits it to the chip pins according to the single-wire protocol.

[0035] S500 increments the ID by 1 to prepare the register for the next ID;

[0036] S600: Determine whether all registers have been traversed; if not, return to step S200; if yes, end and return to step S100. At this point, the IDs and corresponding values ​​of all registers that need to be observed have been transmitted.

[0037] Furthermore, the Debugbus module includes a Master Port and a Slave Port. The Master Port is used to connect to the Master device, and the other end of the Master device is connected to the aforementioned receiver. The Slave Port is used to connect to the Slave device and configure the registers to be observed as slave devices.

[0038] The Master Port is used to receive the register ID sent by the Master and send the register ID to the Slave Port; the Slave Port is used to find the corresponding Slave register from the connected Slave according to the received register ID, obtain the value of the Slave register and return it to the Master Port.

[0039] The Master Port will return the acquired register values ​​as a return value to the corresponding Master to complete the register information collection.

[0040] Furthermore, in the event that the system bus is suspended, the Debugscan module is configured as the master device to perform debugging through the Debugscan module;

[0041] At this time, Debugscan, acting as the master device, can send an ID to the slave port through the master port of the Debugbus module. The slave port finds the value of the corresponding register based on the received ID and returns it to the master port. The master port then sends the obtained register value back to the Debugscan module.

[0042] Furthermore, in the case of non-system bus hangup, one or more IP modules in the SOC chip of the embedded system are configured as the master device for debugging the IP module.

[0043] At this point, for any IP module, acting as the master device, it can send an ID to the slave port through the MasterPort of the Debugbus module. The slave port finds the value of the corresponding register based on the received ID and returns it to the master port. The master port then sends the obtained register value back to the IP module, which in turn sends the register information to the aforementioned host receiver for parsing.

[0044] The present invention also provides a hang-up debugging system for an embedded system, the system including a debugbus module and a debugscan module configured in the SOC chip of the embedded system, and a host receiver configured outside the embedded system.

[0045] The debugbus module is independent of the system bus and is configured to: collect register information of registers that need to be observed according to preset parameters when the system bus is suspended.

[0046] The debug scan module Debugscan is connected to the Debugbus module and is configured to: access the Debugbus module only and send the register information collected by the Debugbus module to the host receiver outside the embedded system; wherein, the Debugscan module is configured with an on state and a off state. In the on state, Debugscan starts working, obtains register information from the Debugbus module and transmits the register information to the host receiver; in the off state, the Debugscan module does not transmit information.

[0047] The receiver described above is equipped with a parsing unit, which is configured to receive and parse the register information transmitted by the Debugscan module.

[0048] Compared with the prior art, the present invention, by adopting the above technical solution, has the following advantages and positive effects: The present invention can also dump system information when the bus is hung, which not only reduces the demand for the internal RAM of the embedded system, but also eliminates the need to set up a separate subsystem for debugging. At the same time, it can also obtain key information of the CPU internal registers, thus providing debugging functions while saving system costs. Attached Figure Description

[0049] Figure 1The module structure diagram of the hang-up debugging system for an embedded system provided in the embodiment of the present invention is shown.

[0050] Figure 2 This is a schematic diagram illustrating the working principle of the Debugbus module provided in an embodiment of the present invention.

[0051] Figure 3 The execution logic diagram of the Debugscan module provided in this embodiment of the invention.

[0052] Figure 4 This is a diagram illustrating the frame format configuration provided in an embodiment of the present invention.

[0053] Figure 5 The flowchart for host computer parsing provided in the embodiments of the present invention. Detailed Implementation

[0054] The following detailed description, in conjunction with the accompanying drawings and specific embodiments, provides a further detailed explanation of the embedded system hang-up debugging method and debugging system disclosed in this invention. It should be noted that the technical features or combinations of technical features described in the following embodiments should not be considered isolated; they can be combined to achieve better technical effects. In the accompanying drawings of the following embodiments, the same reference numerals in each drawing represent the same features or components, which can be applied to different embodiments. Therefore, once an item is defined in one drawing, it does not need to be further discussed in subsequent drawings.

[0055] It should be noted that the structures, proportions, sizes, etc., illustrated in the accompanying drawings are merely for illustrative purposes and to aid those skilled in the art in understanding and reading the invention. They are not intended to limit the conditions under which the invention can be implemented. Any modifications to the structure, changes in proportions, or adjustments to size, provided they do not affect the effectiveness or purpose of the invention, should fall within the scope of the technical content disclosed in the invention. The scope of the preferred embodiments of the present invention includes other implementations, wherein functions may be performed not in the order stated or discussed, including substantially simultaneously or in reverse order, depending on the functions involved. This should be understood by those skilled in the art to which the embodiments of the present invention pertain.

[0056] Techniques, methods, and apparatus known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and apparatus should be considered part of the specification. In all examples shown and discussed herein, any specific values ​​should be interpreted as merely exemplary and not as limitations. Therefore, other examples of exemplary embodiments may have different values. Example

[0057] To address the shortcomings of the system crash debugging solutions described in the background art, this invention provides a novel embedded system hang-up debugging solution. This solution effectively solves the problems of how to collect critical system information, how to send the collected critical information to the outside of the embedded system with its bus suspended, and how to quickly parse the information sent to the outside when the system bus is suspended and the CPU and DMA cannot read any content. Using this debugging solution, system information can be dumped regardless of whether the system bus is suspended, thus reducing the need for embedded internal RAM and eliminating the need to design a separate subsystem specifically for debugging. Furthermore, it can obtain critical information from the CPU's internal registers, thereby increasing debugging functionality while saving system costs.

[0058] See Figure 1 As shown, this embodiment provides a hang-up debugging system for an embedded system. The debugging system corresponds to the settings of the embedded system, which includes a system SoC chip.

[0059] The debugging system includes a debugbus module and a debugscan module configured within the SOC chip of the embedded system, as well as a host receiver configured outside the embedded system chip.

[0060] The debugbus module operates independently of the system bus and is used to collect critical system information when the system bus is suspended. Specifically, the debugbus module can collect register information from pre-defined registers that need to be observed.

[0061] In this embodiment, the Debugbus module does not rely on the system-level bus. During the chip design phase, the registers that need to be observed can be collected and stored on the Debugbus module, and each register is assigned a unique ID number. Other modules can obtain the value of the registers that need to be observed through the ID.

[0062] Specifically, a register configuration module can be set up. This module is used to: assign a unique identification number (ID) (or ID number, for example...) to each register to be observed, based on the registers selected by the user during the chip design phase. Figure 2 The register observation list is formed by using 0, 1, 2, ..., N, etc., which record the names of the registers to be observed and the IDs corresponding to each register; and the register observation list is stored in the Debugbus module.

[0063] An observation signal selection module can also be set up, which allows users to select the name of the register to be observed during the chip design stage.

[0064] At this time, the register configuration module is configured to: obtain all registers selected by the observation signal selection module, sort the registers according to preset rules, and then configure an ID for each register in order of register sorting.

[0065] See Figure 2 The diagram illustrates the typical structure and working principle of a Debugbus module. The Debugbus module may include a Master Port and a Slave Port. The Master Port is used to connect to a Master device (e.g.,...). Figure 2 (This includes IP modules such as Jtag, CPU, and DMA). The other end of the master device is connected to the aforementioned receiver. The slave port is used to connect to the slave device and configure the registers to be observed as slave devices.

[0066] The Master Port receives the register ID sent by the Master device and sends the register ID to the Slave Port. The Slave Port, based on the received register ID, locates the corresponding Slave register from the connected Slave device, obtains the register value (Register Value), and returns it to the Master Port. The Master Port then sends the obtained register value (Register Value) back to the corresponding Master to complete the register information collection.

[0067] In this embodiment, each master device can send an ID to the Slave Port through the Master Port of the Debugbus module. The Slave Port returns the value of the corresponding Slave register to the Master Port based on the received ID. The Master Port then sends the obtained value back to the corresponding master to complete a complete register information acquisition process.

[0068] The Debugscan module is connected to the Debugbus module and is used only to access the Debugbus module to send the register information collected by the Debugbus module to the host receiver outside the embedded system.

[0069] The Debugscan module only needs to be turned on and off; its other functions are independent of whether the software can still run. Specifically, the Debugscan module can be configured to have an on state and a off state; in the on state, Debugscan starts working, obtaining register information from the Debugbus module and transmitting the register information to the host receiver; in the off state, the Debugscan module does not transmit information.

[0070] In this embodiment, the Debugscan module transmits register information to the host receiver via a single wire (or one line), and the single-wire transmission physical layer protocol is compatible with the serial bus protocol; the host computer uses a general serial port tool to receive the information.

[0071] See also Figure 1 As shown, the Debugscan module can be equipped with a serial shift register. When the system bus is suspended, the Debugscan module can be triggered to enter the open state. The Debugscan module accesses the Debugbus module through the ID, obtains the value of the register to be observed from the Debugbus module, and puts the ID and the corresponding value into the internal serial shift register. According to the single-wire protocol, the value is then transmitted to the host receiver via the chip pin.

[0072] In this embodiment, in the register observation list, the ID of the first register is set to 0, and the ID of subsequent registers is the ID of the previous register plus 1. At this time, the Debugscan module is implemented by hardware logic; the operating principle of the Debugscan module can be found in [link to documentation]. Figure 3 As shown: After opening the Debugscan module (the Debugscan module is now open), perform the following steps:

[0073] S100, module initialization ID=0;

[0074] S200, send the current ID to the Debugbus module;

[0075] S300 receives the value of the register corresponding to the aforementioned ID from the Debugbus module;

[0076] S400 places the ID and its corresponding value into a serial shift register and transmits it to the chip pins according to the single-wire protocol.

[0077] S500 increments ID by 1 (i.e., ID++) to prepare the register for the next ID;

[0078] S600, determine whether all registers have been traversed; if not, return to step S200; if yes, end and return to step S100. At this point, the IDs (0,1,2,...,N) of all registers that need to be observed and their corresponding values ​​have been transmitted.

[0079] In this embodiment, the Debugscan module is entirely implemented in hardware logic, independent of software, and boasts high reliability. Furthermore, it employs a single-wire protocol, simplifying implementation; only one wire is needed to complete the debugging task, minimizing embedded resource consumption. Simultaneously, during online real-time debugging, problems can be analyzed without disrupting the environment as long as there is power. Moreover, because it continuously monitors the system status in a loop, debugging can be performed at any time as long as the status is consistently "yes" (determined to be "yes").

[0080] To quickly parse the collected critical system information, this invention designs a simple and efficient protocol. The Debugscan module automatically transmits the ID and its corresponding value (return value) to the host receiver via a single wire for parsing. To ensure compatibility with serial bus protocols, the baud rate of this single-wire transmission physical layer protocol is preferably 115200, using an 8N1 transmission mode. This allows the host receiver to directly use general-purpose serial port tools to receive data frames without needing to develop additional physical layer receiving tools, and then simply parse the received data. The general-purpose serial bus protocol is already widely accepted and will not be elaborated upon further here, referring to existing technologies.

[0081] In this embodiment, the data frame format has been optimized. Specifically, the ID and its corresponding value are placed in the internal serial shift register as follows: according to the pre-configured frame format, the ID and its corresponding value are placed in the internal serial shift register, and the preferred data format of the frame format is [START] [ID] [LEN] [PAYLOAD] [CRC] .

[0082] The START field is used to configure the frame start flag, which can be a preset fixed number of bytes, and the length of the START field can be configured to 1 byte; the ID field is used to configure the module ID of the register, and the length of the ID field can be configured to multiple bytes; the LEN field is used to configure the payload length, and the payload length can be a fixed value between 0 and 255 bytes, and the length of the LEN field can be configured to 1 byte; the PAYLOAD field is used to configure the specific data content; the CRC field is used to configure CRC-8 check information, which covers the [ID] to [PAYLOAD] information, and the length of the CRC field can be configured to 1; the END field is used to configure the frame end flag, which can be a preset fixed number of bytes, and the length of the END field can be configured to 1.

[0083] This is an example of a typical approach, not a limitation. Figure 4 The example demonstrates the configuration information for each field of the frame format. The START field uses a fixed byte of 0xAA and has a length of 1 byte; the ID field has an ID range of 0x00000000 to 0xFFFFFFFF and a length of 4 bytes; the LEN field configures the payload length, which is fixed at 4 bytes here, i.e., LEN=4, and the length of the LEN field is configured to be 1 byte; the PAYLOAD field is used to configure the specific data content and has a length of n bytes, n=4; the CRC field is configured with CRC-8 checksum, covering [ID..PAYLOAD]; the END field uses a fixed byte of 0x55 and has a length of 1 byte.

[0084] The receiver described above is equipped with a parsing unit, which is used to receive and parse the register information transmitted by the Debugscan module.

[0085] For details, see Figure 5 As shown, the steps for the host receiver to parse a data frame include: receiving the start byte; determining whether it is a preset frame start flag—such as 0xAA; if not, determining an abnormal situation, discarding the data, waiting to receive characters until the start byte is received again, and returning to the execution step to receive the start byte; if yes, continuing to read the ID field and LEN field of the data frame; continuing to determine whether LEN is equal to a preset fixed value—for example, the fixed value is set to 4, i.e., determining LEN! =4; If not, it is considered an abnormal situation, discard, wait to receive characters until the start byte is received again, and return to the execution step to receive the start byte; If yes, read LEN payload data - that is, 4 payload data, and then read the CRC; check if the CRC is correct; If not, it is considered an abnormal situation, discard, wait to receive characters until the start byte is received again, and return to the execution step to receive the start byte; If yes, receive the end character; check if it is the preset frame end flag 0x55; If not, it is considered an abnormal situation, discard, wait to receive characters until the start byte is received again, and return to the execution step to receive the start byte; If yes, save the ID and the corresponding return value, and return to the execution step to receive the start byte.

[0086] In this embodiment, when the system bus is suspended, the Debugscan module is configured as the master device for debugging. In this case, Debugscan, acting as the master device, can send an ID to the slave port through the master port of the Debugbus module. The slave port finds the value of the corresponding register based on the received ID and returns it to the master port. The master port then sends the obtained register value back to the Debugscan module.

[0087] When the non-system bus is not suspended, one or more IP modules in the embedded system's SOC chip are configured as Master devices for debugging. In this case, for any IP module, acting as the Master, it can send its ID to the Slave Port via the Master Port of the Debugbus module. The Slave Port finds the corresponding register value based on the received ID and returns it to the Master Port. The Master Port then sends the obtained register value back to the IP module, which in turn sends the register information to the aforementioned host receiver for parsing.

[0088] The system hang debugging scheme provided by this invention features a Debugbus module that is completely independent of the system bus. Hanging the embedded system bus has no impact on the Debugbus; as long as CPU / DMA access to the Debugbus is not used, the Debugbus will not hang. Simultaneously, the Debugscan module is only used to access the Debugbus and does not participate in system operation, therefore it will not hang due to a hang in the system bus. This debugging scheme offers high flexibility, applicable not only to debugging under bus hang conditions (with the Debugscan module as the master device) but also to debugging other master devices (with Jtag / CPU / DMA modules as master devices) in non-bus hang conditions. Furthermore, the Debugbus has high diffusion capability; to observe more signals, simply add new IDs during the chip design phase and connect the signals to the registers of the new IDs.

[0089] This invention enables system debugging at any time (without restriction on the timing of debugging) even when the embedded system bus is suspended. This overcomes the shortcomings of previous solutions, solves the problem of not being able to debug after the bus is suspended, and achieves a highly reliable debugging solution at minimal cost.

[0090] In the above description, the disclosure of this invention is not intended to limit itself to these aspects. Rather, within the scope of the objectives of this disclosure, components can be selectively and operationally combined in any number. Furthermore, terms such as “comprising,” “encompassing,” and “having” should be interpreted by default as inclusive or open-ended, rather than exclusive or closed, unless explicitly defined as such. All technical, scientific, or other terms are to be understood by those skilled in the art, unless defined as such. Public terms found in dictionaries should not be interpreted in the context of the relevant technical documents in an overly idealistic or impractical manner, unless explicitly defined as such in this disclosure. Any modifications or alterations made by those skilled in the art based on the foregoing disclosure are within the scope of the claims.

Claims

1. A method for debugging a stuck embedded system, characterized in that: Configure a debugbus module and a debugscan module within the SOC chip of the embedded system, and configure a host receiver outside the embedded system chip; The Debugbus module operates independently of the system bus and is used to collect register information from preset registers that need to be observed when the system bus is suspended. The Debugbus module includes a Master Port and a Slave Port. The Master Port connects to the Master device, and the other end of the Master device connects to a host receiver. The Slave Port connects to the Slave devices, configuring the registers to be observed as slaves. The Master Port receives register IDs from the Master and sends these register IDs to the Slave Port. The Slave Port, based on the received register ID, locates the corresponding Slave register from the connected Slave, retrieves the value of the Slave register, and returns it to the Master Port. The Master Port then returns the retrieved register value as a return value to the corresponding Master to complete the register information collection. The Debugscan module connects to the Debugbus module and is used only to access the Debugbus module to send the register information collected by the Debugbus module to an external host receiver of the embedded system. The Debugscan module is configured with an on state and a off state. In the on state, Debugscan starts working, obtains register information from the Debugbus module, and transmits the register information to the host receiver. In the off state, the Debugscan module does not transmit information. When the system bus is suspended, the Debugscan module is configured as the master device for debugging. In this case, Debugscan, as the master device, can send an ID to the slave port through the master port of the Debugbus module. The slave port finds the value of the corresponding register based on the received ID and returns it to the master port. The master port then sends the obtained register value back to the Debugscan module. The host receiver is equipped with a parsing unit, which is used to receive and parse the register information transmitted by the Debugscan module.

2. The method according to claim 1, characterized in that, The Debugscan module transmits register information to the host receiver via a single-wire transmission, and the single-wire transmission physical layer protocol is compatible with the serial bus protocol; the host computer uses a general serial port tool to receive the information.

3. The method according to claim 2, characterized in that, It also includes a register configuration module, which assigns a unique identification number (ID) to each register to be observed based on the registers selected by the user during the chip design phase to form a register observation list. The register observation list records the names of the registers to be observed and the IDs corresponding to each register. It also stores the register observation list in the Debugbus module. The Debugscan module is equipped with a serial shift register. When the system bus is suspended, the Debugscan module is triggered to enter the open state. The Debugscan module accesses the Debugbus module through the ID, obtains the value of the register to be observed from the Debugbus module, and puts the ID and the corresponding value into the internal serial shift register and transmits it to the chip pin according to the single-wire protocol to the host receiver.

4. The method according to claim 3, characterized in that, The method for placing the ID and its corresponding value into the internal serial shift register is as follows: according to the pre-configured frame format, the ID and its corresponding value are placed into the internal serial shift register, and the data format of the frame format is [START] [ID] [LEN] [PAYLOAD] [CRC] .

5. The method according to claim 4, characterized in that, The START field is used to configure the frame start flag, using a preset fixed number of bytes, and the length of the START field is configured to be 1 byte; the ID field is used to configure the module ID of the register, and the length of the ID field is configured to be multiple bytes; the LEN field is used to configure the payload length, and the payload length takes a fixed value between 0 and 255 bytes, and the length of the LEN field is configured to be 1 byte; the PAYLOAD field is used to configure the specific data content; the CRC field is used to configure the CRC-8 check information, and the check covers the [ID] [LEN] [PAYLOAD] information, and the length of the CRC field is configured to be 1; the END field is used to configure the frame end flag, using a preset fixed number of bytes, and the length of the END field is configured to be 1. The steps for the host receiver to parse data frames include: Start byte received; Determine if it is the preset frame start flag; if not, determine an abnormal situation, discard the data, wait to receive characters until the start byte is received again, and return to the execution step to receive the start byte; if yes, read the ID field and LEN field. Continue to check if LEN is equal to the preset fixed value; if not, it is determined to be an abnormal situation, discarded, and wait to receive characters until the start byte is received again, then return to the execution step to receive the start byte; if yes, read LEN PAYLOAD data, and then read the CRC. Check if the CRC is correct; if not, determine an abnormal situation, discard the character, wait to receive characters until the start byte is received again, and return to the execution step to receive the start byte; if yes, receive the end character. Determine if it is the preset end-of-frame marker; if not, determine an abnormal situation, discard the data, wait to receive characters until the start byte is received again, and return to the execution step to receive the start byte; if yes, save the ID and the corresponding return value, and return to the execution step to receive the start byte.

6. The method according to claim 3, characterized in that, In the register observation list, the ID of the first register is 0, and the ID of the subsequent registers is the ID of the previous register plus 1; At this point, after the Debugscan module is opened, the following steps are performed: S100, module initialization ID=0; S200, send the current ID to the Debugbus module; S300 receives the value of the register corresponding to the aforementioned ID from the Debugbus module; S400 places the ID and its corresponding value into a serial shift register and transmits it to the chip pins according to the single-wire protocol. S500 increments the ID by 1 to prepare the register for the next ID; S600: Determine whether all registers have been traversed; if not, return to step S200; if yes, end and return to step S100. At this point, the IDs and corresponding values ​​of all registers that need to be observed have been transmitted.

7. The method according to any one of claims 1-6, characterized in that, In the case of non-system bus hangup, configure one or more IP modules in the SOC chip of the embedded system as the master device for debugging of the IP module; At this point, for any IP module, acting as the master device, it can send its ID to the slave port through the master port of the debugbus module. The slave port finds the value of the corresponding register based on the received ID and returns it to the master port. The master port then sends the obtained register value back to the IP module, which in turn sends the register information to the aforementioned host receiver for parsing.

8. A hang-up debugging system for an embedded system, characterized in that: This includes the Debugbus module and Debugscan module configured within the SOC chip of the embedded system, as well as the host receiver configured outside the embedded system. The debugbus module is independent of the system bus and is configured to: collect register information of registers to be observed according to preset registers when the system bus is suspended; the debugbus module includes a master port and a slave port. The master port is used to connect to the master device, and the other end of the master device is connected to a host receiver; the slave port is used to connect to the slave device, and the registers to be observed are configured as slaves; the master port is used to receive the register ID sent by the master and send the register ID to the slave port; the slave port is used to find the corresponding slave register from the connected slave based on the received register ID, obtain the value of the slave register, and return it to the master port; the master... The Port returns the acquired register values ​​as a return value to the corresponding Master to complete the register information collection. The Debugscan module, connected to the Debugbus module, is configured to access the Debugbus module only and send the register information collected by the Debugbus module to the host receiver outside the embedded system. The Debugscan module has an open state and a closed state. In the open state, Debugscan starts working, acquires register information from the Debugbus module, and transmits the register information to the host receiver. In the closed state, the Debugscan module does not transmit information. When the system bus is suspended, the Debugscan module is configured as the Master device for debugging. In this case, Debugscan, as the Master device, can send an ID to the Slave Port through the Master Port of the Debugbus module. The Slave Port finds the corresponding register value based on the received ID and returns it to the Master Port. The Master Port then returns the acquired register value to the Debugscan module. The host receiver is equipped with a parsing unit, which is configured to receive and parse the register information transmitted by the Debugscan module.

Images