Debugging apparatus and debugging method for audio-video equipment
By reusing the CEC protocol and UART baud rate timing identification signal of audio and video equipment, and using the debugging adapter and host for bidirectional monitoring, the problem of missing UART interface in audio and video equipment debugging is solved, and efficient debugging without disassembling the equipment is achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-04-24
- Publication Date
- 2026-06-26
Smart Images

Figure CN122293847A_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the field of audio and video equipment technology, and in particular relates to a debugging device and debugging method for audio and video equipment. Background Technology
[0002] Audio-visual equipment typically includes devices such as televisions and audio equipment, and set-top boxes. Televisions and audio equipment interact to enable sound playback. Set-top boxes act as translators and gateways connecting televisions to external signals. Their core function is to receive, decode, and convert television signals from different channels, and then convert them into standard audio-visual formats that televisions can recognize and play.
[0003] In the development and after-sales service of high-definition multimedia interface (HDMI) devices such as TV audio equipment and set-top boxes, there is a limitation imposed by physical interfaces: mass-produced machines generally omit the Universal Asynchronous Receiver / Transmitter (UART) interface by default, making it difficult to obtain internal logs of HDMI interface devices. After-sales machines cannot analyze problems without disassembling the machine, resulting in low efficiency in troubleshooting or debugging. Summary of the Invention
[0004] This application provides a debugging device and method for audio and video equipment. By reusing the first preset pin connected to the device under test, the debugging and maintenance of audio and video equipment can be achieved without disassembling the device.
[0005] In a first aspect, embodiments of this application provide a debugging apparatus for an audio-visual device, the audio-visual device including a device under test and a display terminal, the debugging apparatus comprising: A debug adapter is connected in series in the HDMI link between the device under test (DUT) and the display terminal. The debug adapter includes a connector and a controller. The connector has a first preset pin that interfaces with the DUT. The controller has a high-impedance input capture pin and a UART transmit pin. The first preset pin is electrically connected to the high-impedance input capture pin via a first branch and to the UART transmit pin via a second branch. The controller is used to classify the signal on the first preset pin into a first type of signal conforming to CEC protocol timing and a second type of signal conforming to UART baud rate timing, based on the pulse width of the first preset pin identified by the first branch. The debugging host is electrically connected to the controller. The debugging host is used to receive the operation log data of the device under test when the controller identifies it as the first type of signal. The debugging host is also used to send a debugging command to the controller to debug the device under test via the second branch and the first preset pin when the controller identifies it as the second type of signal.
[0006] Optionally, the connector also has a transmission pin, and the controller also has a UART receiving pin. The transmission pin is connected to the UART receiving pin, and the signal path connecting the transmission pin and the UART receiving pin is used to upload the operation log data of the device under test to the debugging host via the controller when the controller identifies it as the first type of signal.
[0007] Optionally, one of the first preset pin and the transmission pin is a CEC pin, and the other is a configurable general-purpose input / output pin.
[0008] Optionally, when the controller identifies the signal as the second type, the controller drives the UART transmit pin to a low level when the debugging host issues a debugging command; otherwise, the UART transmit pin is in a high-impedance state by default.
[0009] Optionally, the debug adapter includes: The first resistor or controllable switch is connected in series to the second branch.
[0010] Optionally, the debugging host and the controller are connected via a USB link.
[0011] Secondly, embodiments of this application also provide a debugging method for an audio-visual device, the audio-visual device including a device under test and a display terminal, the debugging method including: In response to powering the audio / video device, the pulse width at the first preset pin level transition of the debug adapter adapted to the device under test and the display terminal is obtained; Based on the pulse width, the signals of the first preset pin are divided into a first type of signal conforming to the CEC protocol timing and a second type of signal conforming to the UART baud rate timing. When the signal is identified as the first type, the operating log data of the device under test is received; When the signal is identified as the second type, a debugging command is sent to debug the device under test.
[0012] Optionally, the step of classifying the signal of the first preset pin into a first type of signal conforming to the CEC protocol timing and a second type of signal conforming to the UART baud rate timing based on the pulse width includes: If the pulse width is detected to be the first pulse width, it is determined to be a first type of signal that conforms to the CEC protocol timing. If the pulse width is detected to be the second pulse width, it is determined to be a second type of signal that conforms to the UART baud rate timing, wherein the second pulse width is less than the first pulse width.
[0013] Optionally, when the signal is identified as the second type, sending a debugging command to debug the device under test includes: Monitor the first duration for which the first preset pin remains at a high level; When the first duration is greater than or equal to the safety threshold, the level of the first preset pin is pulled low to send a debugging command to the device under test.
[0014] Optionally, after pulling the level of the first preset pin low to send a debugging command to the device under test when the first duration is greater than or equal to the safety threshold, the debugging method further includes: Once the debugging command has been sent, adjust the level of the first preset pin to a high impedance state.
[0015] In the debugging apparatus and debugging method of audio and video equipment in the embodiments of this application, by reusing the first preset pin that is connected to the device under test, the identification and detection of two different rate signals can be realized. During the operation of the audio and video equipment according to the CEC protocol, both operation log data can be obtained and debugging instructions can be sent to the device under test. By adopting bidirectional monitoring and time-sharing scheduling, the debugging and maintenance of audio and video equipment can be realized without disassembling the equipment. Attached Figure Description
[0016] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0017] To gain a more complete understanding of this application and its beneficial effects, the following description will be provided in conjunction with the accompanying drawings. In the following description, the same reference numerals denote the same parts.
[0018] Figure 1 A schematic diagram of the structure of the debugging device for audio and video equipment provided in the embodiments of this application.
[0019] Figure 2 This is another schematic diagram of the debugging device for audio and video equipment provided in the embodiments of this application.
[0020] Figure 3This is another schematic diagram of the debugging device for audio and video equipment provided in the embodiments of this application.
[0021] Figure 4 This is a flowchart illustrating a debugging method for an audio / video device provided in an embodiment of this application. Detailed Implementation
[0022] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.
[0023] Audio-visual equipment is an electronic device capable of processing, generating, storing, transmitting, receiving, or playing audio and / or video signals. Its core lies in its comprehensive processing capability for both audio and video information media. Audio-visual equipment can include display terminals and devices under test (DUTs), such as a television as the display terminal and speakers or a set-top box as the DUT. Of course, display terminals can also include mobile phones, tablets, computers, in-vehicle TVs, and in-vehicle video equipment.
[0024] Taking televisions as an example, in the development and after-sales service of HDMI devices with high-definition multimedia interfaces such as TV speakers and set-top boxes, there are limitations due to physical interfaces. Mass-produced machines generally remove the Universal Asynchronous Receiver / Transmitter (UART) interface by default, making it difficult to obtain the internal logs of HDMI interface devices. After-sales machines cannot analyze problems without disassembling the machine, resulting in low troubleshooting or debugging efficiency.
[0025] In view of the above problems, this application provides a debugging device and debugging method for audio and video equipment, which will be described below with reference to the accompanying drawings.
[0026] Please see Figure 1 As shown, Figure 1 This is a schematic diagram of a debugging apparatus for audio-visual equipment provided in an embodiment of this application. This application provides a debugging apparatus 200 for an audio-visual device 100, which includes a device under test 110 and a display terminal 120. The device under test 110 may be, for example, an audio system or a set-top box, and the display terminal 120 may be, for example, a television. For ease of understanding, this application embodiment uses an audio system as the device under test and a television as the display terminal 120 as an example for explanation.
[0027] The debugging device 200 is mainly used for debugging and repairing the device under test 110. For example, the debugging device 200 includes a debugging adapter 210 and a debugging host 220.
[0028] It should be noted that the Consumer Electronics Control (CEC) protocol, also known as the CEC protocol, is a protocol in the HDMI standard. It allows users to control multiple devices connected to the HDMI link, such as televisions, set-top boxes, and audio equipment, using a single remote control. This signal typically operates on pin 13 of the HDMI interface at a low baud rate. The HDMI interface is a high-definition multimedia interface, a fully digital video and audio transmission interface capable of sending uncompressed audio and video signals. This application embodiment primarily utilizes its physical layer interface and specific pins for non-standard debugging communication. UART (Universal Asynchronous Receiver / Transmitter) is a universal asynchronous receiver / transmitter, a common serial communication protocol often used for debugging and control in embedded systems. This application embodiment utilizes it to carry high-baud-rate debugging commands and log data.
[0029] Please see Figure 2 As shown, Figure 2 This is another schematic diagram of the debugging device for audio and video equipment provided in the embodiments of this application. The debugging adapter 210 is connected in series in the HDMI link between the device under test 110 and the display terminal 120. That is, the device under test 110 can communicate with the display terminal 120 according to the CEC protocol. The debugging adapter 210 acts as an "intermediary" between the device under test 110 and the display terminal 120, which enables the debugging adapter 210 to intercept signals while maintaining the integrity of the physical link.
[0030] For example, the debug adapter 210 includes a connector 212 and a controller 214. The connector 212 has a first preset pin P1 that mates with the device under test 110. The controller 214 has a high-impedance input capture pin S1 and a UART transmit pin TX1. The first preset pin P1 is connected to the high-impedance input capture pin S1 via a first branch, and is also connected to the UART transmit pin TX1 via a second branch. The controller 214 is used to classify the signal on the first preset pin P1 into a first type of signal conforming to the CEC protocol timing, and a second type of signal conforming to the UART baud rate timing, based on the pulse width of the first preset pin P1 identified by the first branch. The first type of signal can be understood as a CEC protocol signal, and the second type of signal can be understood as a UART debug command.
[0031] Specifically, when the controller 214 identifies the signal as a first type, it decodes the CEC protocol and outputs CEC interaction information; when it needs to issue a debugging command and determines that the first preset pin P1 is in an idle state, it outputs a second type signal through the second branch via the UART transmit pin TX1; and it outputs the operation log data received via the UART receive pin RX1 to the debugging host 220.
[0032] It should be noted that the first preset pin P1 is connected to the high-impedance input capture pin S1 through the first branch, which can perform non-intrusive monitoring of the level change on the first preset pin P1. The controller 214 can measure its pulse width based on the level change of the first preset pin P1.
[0033] The debugging host 220 can be understood as a host computer or a test host. The debugging host 220 is electrically connected to the controller 214. The debugging host 220 is used to receive the operation log data from the device under test 110 and the display terminal 120 when the controller 214 identifies it as a first type of signal. The debugging host 220 is also used to send debugging commands to the controller 214 to debug the device under test 110 via the second branch and the first preset pin P1 when the controller 214 identifies it as a second type of signal. Alternatively, the debugging host 220 is used to receive CEC interaction signals and the operation log data of the device under test 110, and to send debugging commands to the controller 214 to debug the device under test 110 via the first preset pin P1.
[0034] In the debugging device 200 of the audio-visual device 100 provided in this application embodiment, by multiplexing the first preset pin P1 that is connected to the device under test 110, the identification and detection of two different rate signals can be realized. During the operation of the audio-visual device 100 according to the CEC protocol, both operation log data can be obtained and debugging commands can be sent to the device under test 110. By adopting bidirectional monitoring and time-sharing scheduling, the debugging and maintenance of the audio-visual device 100 can be realized without disassembling the device.
[0035] Please refer to Figure 3 As shown, Figure 3 This is another schematic diagram of the debugging apparatus for audio and video equipment provided in the embodiments of this application. Connector 212 also has a transmission pin P2, and controller 214 also has a UART receive pin RX1. Transmission pin P2 is connected to UART receive pin RX1. The signal path connecting transmission pin P2 and UART receive pin RX1 is used to upload the operation log data of the device under test 110 and display terminal 120 to the debugging host 220 via controller 214 when the controller 214 identifies it as a first type of signal.
[0036] For example, when the controller 214 identifies the signal as a second type, the controller 214 drives the UART transmit pin TX1 to a low level when the debugging host 220 issues a debugging command. Otherwise, the UART transmit pin TX1 is in a high-impedance state by default.
[0037] For example, the debugging adapter 210 also includes a first resistor or a controllable switch, which is connected in series to the second branch.
[0038] It should be noted that the first branch can be understood as a listening path. The first preset pin P1 is connected to the high-impedance input capture pin S1 of the controller 214. This branch does not consume current and is used to monitor changes in the bus level in real time. The second branch can be understood as an injection path. The first preset pin P1 is connected to the UART transmit pin TX1 of the controller 214 through a first resistor, i.e., a current-limiting resistor or a controllable switch. The controller 214 only drives the UART transmit pin TX1 to a low level when a debug command needs to be sent; otherwise, it maintains a high-impedance state. Alternatively, the second branch is used to output UART debug data to the first preset pin P1 when the bus is idle.
[0039] In existing technologies, devices that reuse HDMI port I / O for UART serial ports, such as those that reuse Pin 2 (Shield) of an HDMI interface device, are prone to causing signal short circuits and damaging the video shielding layer. Reusing Pin 19 (HPD) of an HDMI interface device poses a risk of bus conflict with the high-level drive on the TV, potentially leading to video interruption. Furthermore, reusing Pin 15 / 16 (DDC) of an HDMI interface device can interfere with HDCP handshakes, resulting in the inability to play encrypted content. Moreover, there are debugging blind spots: existing serial port debugging can only view the internal status of the device and cannot directly see the HDMI CEC (Consumer Electronics Control) interaction commands between the TV and the device. Engineers often need expensive dedicated protocol analyzers to determine whether the TV has sent control commands, resulting in low troubleshooting efficiency.
[0040] Based on the above problems, this application embodiment selects a first preset pin P1. This application embodiment selects a CEC pin for one of the first preset pin P1 and a configurable general-purpose input / output pin for the other. Taking the first preset pin P1 as a CEC pin and the transmission pin P2 as a configurable general-purpose input / output pin as an example, the first preset pin P1 of connector 212 is connected to the corresponding CEC pin of the device under test 110, and the debug adapter 210 is connected to the CEC pin of the display terminal 120. The transmission pin P2 is connected to the UART receive pin RX1 of controller 214. This path is independent of the CEC bus and is specifically used to carry high-throughput system operation log data, avoiding the blockage of the control bus due to the large amount of log data. That is, the transmission pin P2 and the first preset pin P1 form an independent signal path within the debug adapter 210.
[0041] The debug adapter 210 of this application embodiment also has a seamless pass-through design. Except for the first preset pin P1, i.e., Pin 13 and the transmission pin P2, i.e., Pin 14, the other pins, such as Pin 1 to Pin 12 and Pin 15 to Pin 19, are directly connected inside the debug adapter 210 through PCB traces. This ensures that the DDC handshake, i.e., HDCP encryption verification and HPD hot-plug detection, is not interfered with in any way, and realizes the function of online debugging.
[0042] This embodiment of the application selects the first preset pin P1 as the CEC pin and the transmission pin P2 as a configurable general-purpose input / output pin, which enables audio and video pass-through. The high-speed differential signal (TMDS / FRL) in the HDMI interface is transparently transmitted to the display terminal 120 via the debug adapter 210, ensuring normal video display. Furthermore, logs can be uploaded unidirectionally via the transmission pin P2, i.e., Pin 14: the system operation log data of the device under test 110 is transmitted unidirectionally at high speed to the debug adapter 210 via the 14th pin (Utility / HEAC+) of the HDMI interface, and then uploaded to the debug host 220 via the USB link. In addition, command interaction and monitoring can be achieved via the 13th pin, i.e., the CEC pin: debug commands issued by the debug host 220, and the existing CEC control commands between the display terminal 120 and the device under test 110, coexist on the 13th pin (CEC) of the HDMI interface. The debug adapter 210 performs bidirectional monitoring and time-division scheduling on this pin.
[0043] The debugging device 200 for the audio / video device 100 provided in this application avoids the high-risk Pin 2 and Pin 19 pins in the HDMI link. It reuses Pin 13, i.e., the CEC pin, using a forked multiplexing structure, forming a T-shaped topology on the circuit board. It utilizes the Open-Drain (output stage) circuit structure of the CEC pin, naturally supporting multiple master devices and providing end-to-end fault diagnosis capabilities. It is not merely a transparent serial port, but also a CEC protocol analyzer, capable of solving the problem of "TV not sending commands" or "audio not executing commands" in one stop, without requiring expensive professional equipment. During debugging, the HDMI core video link TMDS remains pass-through, the screen does not go black or flicker, achieving online debugging.
[0044] Please see Figure 4 As shown, Figure 4 This is a flowchart illustrating a debugging method for an audio / video device provided in an embodiment of this application. To more clearly illustrate the debugging of the audio / video device, this application also provides a debugging method for the audio / video device, wherein the structural composition of the audio / video device and the debugging apparatus can be referred to... Figures 1 to 3 The above explanation will not be repeated here. The debugging methods for audio and video equipment include: Step S310: In response to powering the audio / video equipment, obtain the pulse width of the first preset pin level transition of the debug adapter that adapts to the device under test and the display terminal.
[0045] After the system is powered on, it is in monitoring mode by default, and the first preset pin is set to high impedance input to avoid actively interfering with the bus.
[0046] When a level transition occurs on the first preset pin, its pulse width can be measured. The pulse width of the level transition can serve as the basis for identifying the subsequent two types of signals. For example, the signal edge on the first preset pin can be captured, and pulse width information representing the time interval between adjacent edges can be output.
[0047] Step S320: Based on the pulse width, the signals of the first preset pin are divided into a first type of signal conforming to the CEC protocol timing and a second type of signal conforming to the UART baud rate timing.
[0048] Step S330: When the signal is identified as a first type, receive the operation log data of the device under test.
[0049] Step S340: When the signal is identified as a second type, a debugging command is sent to debug the device under test.
[0050] Regarding steps S320 to S340: In order to achieve the multiplexing of the first preset pin, the embodiments of this application automatically distinguish the signal according to the pulse width, that is, distinguish it into a first type of signal that conforms to the CEC protocol timing and a second type of signal that conforms to the UART baud rate timing.
[0051] The first type of signal can be understood as a CEC protocol signal, and the second type of signal can be understood as a UART debugging command. Different signal types can achieve different debugging methods. For example, the first type of signal can be used to decode the CEC protocol to obtain CEC interaction information, and the source of the abnormality of the device under test can be found based on the CEC interaction information, that is, the operation log data of the device under test. For example, the second type of signal can be used to send debugging commands to the device under test, and the device under test can be debugged or repaired based on the received feedback signals.
[0052] Therefore, the embodiments of this application can employ bidirectional monitoring of the device under test, thereby improving the flexibility of debugging.
[0053] The debugging method for audio and video equipment provided in this application embodiment can identify and detect two different rate signals, thereby solving the problem of CEC protocol signals and UART debugging signals coexisting on the same line. During the operation of the audio and video equipment according to the CEC protocol, it can obtain operation log data and send debugging commands to the device under test. By adopting bidirectional monitoring and time-sharing scheduling, the debugging and maintenance of audio and video equipment can be achieved without disassembling the device.
[0054] The distinction between the first type of signal and the second type of signal is achieved through pulse width. In one implementation, step S320, classifying the signal of the first preset pin into a first type of signal conforming to the CEC protocol timing and a second type of signal conforming to the UART baud rate timing based on the pulse width, includes: Step S322: If the detected pulse width is the first pulse width, it is determined to be a first type of signal that conforms to the CEC protocol timing.
[0055] Step S324: If the detected pulse width is the second pulse width, it is determined to be a second type of signal that conforms to the UART baud rate timing, and the second pulse width is less than the first pulse width.
[0056] Regarding steps S322 and S324: If a pulse width of the first pulse width is detected, such as a data bit of approximately 2.4 milliseconds or a start bit of approximately 3.7 milliseconds, it is determined to be a first-type signal that conforms to the CEC protocol timing. Protocol decoding can be performed, and the signal can be marked and output to the host computer.
[0057] If a pulse width of the second pulse width is detected, which is a narrow pulse in the microsecond range, such as 8.68 microseconds, it is determined to be a second type of signal that conforms to the UART baud rate timing. It can be ASCII decoded and marked and output to the host computer.
[0058] The transmission of debugging commands is not direct but involves a carrier sensing stage, which avoids signal conflicts or enables signal avoidance. In one implementation, step S340, when a signal is identified as a second type, sends a debugging command to debug the device under test, including: Step S342: Monitor the first preset pin to maintain a high level for a first duration.
[0059] Step S344: When the first duration is greater than or equal to the safety threshold, pull the level of the first preset pin low to send a debugging command to the device under test.
[0060] Step S346: After the debugging command is sent, adjust the level of the first preset pin to a high impedance state.
[0061] Regarding steps S342 to S346: When the host computer needs to issue a command, it will not send it immediately, but will instead enter the carrier sensing phase. The carrier sensing phase consists of two steps: idle detection and secure transmission.
[0062] The idle detection step monitors the first preset pin maintaining a high level for a first duration and compares it with a safety threshold. When the first duration is greater than or equal to the safety threshold, it can be determined that the bus has switched from busy to idle. The safety threshold can be, for example, 10 milliseconds.
[0063] The safe transmission procedure involves activating the transmit driver only when the bus is confirmed to be idle, pulling the level of the first preset pin low to send debug commands to the device under test.
[0064] Once the debugging command is sent, immediately release the bus and return to the high-impedance state to ensure that it does not obstruct the CEC control signals of the subsequent display terminal.
[0065] In the audio / video device debugging method provided in this application embodiment, to prevent the UART from disrupting normal CEC communication when issuing commands, a "listen before sending" principle is followed. Carrier listening is established, and the level of a first preset pin is detected before sending UART debugging commands. Then, an idle state judgment is performed; only when the CEC bus is continuously idle for more than a safety threshold, such as 10 milliseconds, is the bus occupied to send debugging data. Furthermore, two different rates of signals flowing on the first preset pin can be identified. For CEC signal identification, a start bit with a pulse width of approximately 2.4 milliseconds is identified, decoded according to the CEC protocol, and marked as being reported to the host computer. For UART signal identification, a microsecond-level pulse width signal is identified and determined to be an internal device command interaction.
[0066] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.
[0067] In the description of this application, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, features defined with "first" and "second" may explicitly or implicitly include one or more features.
[0068] The debugging apparatus and debugging method for audio and video devices provided in the embodiments of this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.
Claims
1. A debugging device for audio-visual equipment, the audio-visual equipment comprising a device under test and a display terminal, characterized in that, The debugging device includes: A debug adapter is connected in series in the HDMI link between the device under test (DUT) and the display terminal. The debug adapter includes a connector and a controller. The connector has a first preset pin that interfaces with the DUT. The controller has a high-impedance input capture pin and a UART transmit pin. The first preset pin is electrically connected to the high-impedance input capture pin via a first branch and to the UART transmit pin via a second branch. The controller is used to classify the signal on the first preset pin into a first type of signal conforming to CEC protocol timing and a second type of signal conforming to UART baud rate timing, based on the pulse width of the first preset pin identified by the first branch. The debugging host is electrically connected to the controller. The debugging host is used to receive the operation log data of the device under test when the controller identifies it as the first type of signal. The debugging host is also used to send a debugging command to the controller to debug the device under test via the second branch and the first preset pin when the controller identifies it as the second type of signal.
2. The debugging device according to claim 1, characterized in that, The connector also has a transmission pin, and the controller also has a UART receiving pin. The transmission pin is connected to the UART receiving pin, and the signal path connecting the transmission pin and the UART receiving pin is used to upload the operation log data of the device under test to the debugging host via the controller when the controller identifies it as the first type of signal.
3. The debugging device according to claim 2, characterized in that, One of the first preset pin and the transmission pin is a CEC pin, and the other is a configurable general-purpose input / output pin.
4. The debugging device according to claim 1, characterized in that, When the controller identifies the signal as the second type, the controller drives the UART transmit pin to a low level when the debugging host issues a debugging command; otherwise, the UART transmit pin is in a high-impedance state by default.
5. The debugging device according to claim 4, characterized in that, The debug adapter includes: The first resistor or controllable switch is connected in series to the second branch.
6. The debugging device according to claim 1, characterized in that, The debugging host and the controller are connected via a USB link.
7. A method for debugging an audio-visual device, the audio-visual device comprising a device under test and a display terminal, characterized in that, The debugging method includes: In response to powering the audio / video device, the pulse width at the first preset pin level transition of the debug adapter adapted to the device under test and the display terminal is obtained; Based on the pulse width, the signals of the first preset pin are divided into a first type of signal conforming to the CEC protocol timing and a second type of signal conforming to the UART baud rate timing. When the signal is identified as the first type, the operating log data of the device under test is received; When the signal is identified as the second type, a debugging command is sent to debug the device under test.
8. The debugging method according to claim 7, characterized in that, The step of classifying the signals of the first preset pin into a first type of signal conforming to the CEC protocol timing and a second type of signal conforming to the UART baud rate timing based on the pulse width includes: If the pulse width is detected to be the first pulse width, it is determined to be a first type of signal that conforms to the CEC protocol timing. If the pulse width is detected to be the second pulse width, it is determined to be a second type of signal that conforms to the UART baud rate timing, wherein the second pulse width is less than the first pulse width.
9. The debugging method according to claim 7, characterized in that, When the signal is identified as the second type, sending a debugging command to debug the device under test includes: Monitor the first duration for which the first preset pin remains at a high level; When the first duration is greater than or equal to the safety threshold, the level of the first preset pin is pulled low to send a debugging command to the device under test.
10. The debugging method according to claim 9, characterized in that, After the step of pulling the level of the first preset pin low to send a debugging command to the device under test when the first duration is greater than or equal to the safety threshold, the debugging method further includes: Once the debugging command has been sent, adjust the level of the first preset pin to a high impedance state.