Dead hanging debugging method and debugging system of embedded system

Abstract

The invention discloses a hanging debugging method and debugging system for an embedded system, and relates to the technical field of embedded systems. According to the method, a Debugbus module and a Debugscan module are configured in an SOC chip of the embedded system, and an upper receiver is configured outside the chip; the Debugbus module is independent of a system bus and is used for collecting register information needing to be observed when the system bus is suspended; the Debugscan module is used for sending the register information collected by the Debugscan module to the upper receiver; the Debugscan module only needs to be opened and closed, and when the Debugscan module is opened, register information is obtained from the Debugbus module and transmitted to an upper receiver to be analyzed; and information is not transmitted during closing. According to the invention, the system information can be dumped when the bus is hung, so that the requirement on an internal RAM (Random Access Memory) of the embedded system is reduced, and the system cost is saved while a debugging function is provided.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of embedded systems, and particularly relates to a hanging debugging method and a debugging system for an embedded system. BACKGROUND

[0002] An embedded device usually adopts a highly integrated special-purpose chip and a simplified architecture. Unlike general-purpose computers (such as personal computers and servers), an embedded device is not designed to run various application programs installed by users, and its functions and operations are usually fixed in the device. A typical embedded device includes both hardware and software.

[0003] To adapt to specific scene requirements (such as industrial control, automotive electronics, and intelligent terminals), hardware resources (including processor computing power, memory capacity, and peripheral interfaces) are usually customized and allocated, and to ensure stability and cost control, redundant debugging hardware channels are often not reserved. In terms of function positioning, an embedded device aims to complete specific core tasks, and the core logic is highly focused on exclusive business (such as sensor data acquisition, device state control, and real-time signal processing). The system software (including the operating system and the driver program) in the embedded device is also lightened and trimmed around the task, and general debugging modules (such as complex log monitoring and multi-node state feedback functions) are often simplified or omitted. In terms of working environment, an embedded device is usually deployed in industrial sites, vehicle-mounted environments, outdoor terminals, and other non-ideal scenes, and may be subject to external disturbances such as electromagnetic interference, voltage fluctuation, and drastic changes in temperature and humidity. These disturbances can easily cause hardware-level abnormalities. These characteristics make the embedded device run in a completely stalled state once it is "hung" due to external disturbances, hardware failures, software logic conflicts, and other factors.

[0004] That is, the system bus of the embedded device may be hung during operation, and as the key channel connecting various components of the embedded device, once the system bus is hung, the device cannot access any system information normally. This is because the architecture of the embedded device is usually compact, and the communication between components is highly dependent on the system bus. When the bus is hung, the processor cannot interact with the memory, peripherals, etc. to exchange data, so that the device is in a paralyzed state, resulting in device function failure. Specifically, on the one hand, due to the simplified hardware architecture and the lack of redundant debugging channels, the traditional access path relying on external hardware debuggers (such as JTAG, SWD) will be interrupted due to the bus being hung, resulting in the inability to read the processor register, memory data and other underlying hardware information. On the other hand, when monitoring and feeding back the system state through the log module of the lightweight designed software, the real-time monitoring process, the software needs to rely on the system bus. Once the bus is hung, these monitoring modules will also be disabled, and they cannot output key information such as system running, task scheduling, peripheral interaction before the fault occurs. These two aspects lead to the fact that the developer cannot determine whether the fault is caused by the physical damage of the bus at the hardware level, or the abnormal triggering of the peripheral, or the software level driver vulnerability, task priority conflict; also cannot trace the system running track before the fault occurs, and thus falls into the dilemma of "difficulty in fault reproduction, difficulty in root cause positioning, and difficulty in problem solving".

[0005] For system crash debugging, the commonly used solutions include: Solution one, similar to the sysdump debugging function of the Linux kernel, dumps the current information to the RAM, and then saves the dumped information to the medium for analysis after resetting.

[0006] Solution two, add dot information on the critical path. These dot information are placed on the internal RAM of the embedded system, and when the system is hung, the dot information is printed out by resetting the embedded system.

[0007] Solution three, make a security island system independent of the embedded system. When the embedded system fails, the security island system is notified by the watchdog module to record the abnormal scene.

[0008] The above solutions have the following disadvantages: if the system bus is dead in the first solution, the whole system cannot run and cannot dump information. In the second solution, although the system bus can be dumped when it is dead, based on the performance of the system, all suspected points cannot be added to the information when designing, and if the suspected points are not added to the information, important debugging information can be missed; and the configuration of the suspected points is limited by the size and cost of the internal RAM. In the third solution, the system bus can be dumped when it is dead, but a subsystem (the safe island system) is designed separately, which has a great impact on the cost, and because it is two systems, the safe island system cannot obtain the CPU internal register information, and the two systems are connected by the bus, if the bus is also dead, the system information cannot be obtained; most importantly, if the system bus is dead, the safe island system will also be dead when reading the information of the embedded system, and then it will be in a similar situation as the first solution, and cannot solve the problem of the bus level being dead.

[0009] In summary, how to use the characteristics of the embedded device to solve the problem that the embedded system bus is dead and cannot access system information, leading to blocked debugging, is a technical problem that needs to be solved at present. SUMMARY

[0010] The present application aims at overcoming the deficiencies of the prior art, and provides a low-cost embedded system dead debugging method and a debugging system. The present application can dump system information when the bus is dead, not only reduces the demand for internal RAM of the embedded system, but also does not need to set up a subsystem for debugging, and can obtain the CPU internal register key information, thereby providing the debugging function and saving the system cost.

[0011] To achieve the above object, the present application provides the following technical solutions: A dead debugging method of an embedded system, which comprises the following steps: The Debugbus module is independent of the system bus, and is used to collect the register information of the registers to be observed according to a preset requirement when the system bus is dead. The Debugscan module is connected to the Debugbus module and is only used to access the Debugbus module to send the register information collected by the Debugbus module to an upper receiver outside the embedded system; the Debugscan module is configured with an open state and a closed state, in the open state, the Debugscan starts to work to obtain the register information from the Debugbus module and transmit the register information to the upper receiver; in the closed state, the Debugscan module does not transmit information. The above receiver is provided with an analysis unit to analyze the register information transmitted by the Debugscan module after receiving the register information.

[0012] Further, the Debugscan module transmits the register information to the upper receiver through a single line, the single line transmission physical layer protocol is compatible with a serial bus protocol; the upper computer uses a general serial port tool to receive.

[0013] Further, the application further comprises a register configuration module, which is used to assign a unique identity ID to each register to be observed to form a register observation list according to the registers to be observed selected by the user in the chip design stage, the register observation list records the register names to be observed and the IDs corresponding to the registers; and the register observation list is stored into the Debugbus module. The Debugscan module is provided with a serial shift register; In the case of system bus hang, after the Debugscan module is triggered to enter the open state, the Debugscan module accesses the Debugbus module through the ID to obtain the values of the registers to be observed from the Debugbus module, and puts the ID and the corresponding values into the internal serial shift register and transmits to the upper receiver through the chip pin according to the single line protocol.

[0014] Further, the way of putting the ID and the corresponding values into the internal serial shift register is as follows: the ID and the corresponding values are put into the internal serial shift register according to a preconfigured frame format, the data format of the frame format is [START][ID][LEN][PAYLOAD][CRC] ; 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.

[0015] Furthermore, the steps for the host receiver to parse the data frame 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.

[0016] 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; At this time, the Debugscan module is implemented by hardware logic. After the Debugscan module enters the open state, it performs the following steps: 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.

[0017] 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. 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. The Master Port will return the acquired register values ​​as a return value to the corresponding Master to complete the register information collection.

[0018] 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; 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.

[0019] 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. 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.

[0020] 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. 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. 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. 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.

[0021] 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

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

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

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

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

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

[0027] 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.

[0028] 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.

[0029] 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

[0030] 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.

[0031] 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.

[0032] 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.

[0033] 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.

[0034] 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.

[0035] 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.

[0036] 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.

[0037] 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.

[0038] 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.

[0039] 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.

[0040] 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.

[0041] 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.

[0042] 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.

[0043] 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.

[0044] 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.

[0045] 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: 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 ID by 1 (i.e., ID++) 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 (0,1,2,...,N) of all registers that need to be observed and their corresponding values ​​have been transmitted.

[0046] 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").

[0047] 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.

[0048] 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] .

[0049] 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.

[0050] This is an example of a typical approach, not a limitation. Figure 4The 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.

[0051] 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.

[0052] 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.

[0053] 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.

[0054] 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.

[0055] 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.

[0056] 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.

[0057] 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 too idealistically or impractically in the context of the relevant technical documents, 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 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. 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. 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.

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] . 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.

5. The method according to claim 4, characterized in that, 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, 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 receiver mentioned above. The Slave Port is used to connect to the Slave device and configure the registers to be observed as slave devices. The Master Port is used to receive the register ID sent by the Master and send the register ID to the SlavePort; 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. The Master Port will return the acquired register values ​​as a return value to the corresponding Master to complete the register information collection.

8. The method according to claim 7, characterized in that, In the event that the system bus is suspended, configure the Debugscan module as the master device to perform debugging through the Debugscan module; 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.

9. The method according to claim 7, 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.

10. 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 that need to be observed according to preset parameters when the system bus is suspended. 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. 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.

Images