Data frame processing method, apparatus and test equipment

Abstract

The embodiment of the application provides a data frame processing method, device and test equipment, comprising: receiving an extended UART frame sent by a chip through a UART interface, wherein the extended UART frame comprises a frame type bit, and the frame type bit is embedded in a physical layer data frame; determining a data frame type of the extended UART frame according to identification information corresponding to the frame type bit in the extended UART frame, wherein the data frame type comprises a user data frame or a debugging data frame; and performing classified processing on each extended UART frame according to the data frame type of the extended UART frame, that is, sending the user data frame to a user terminal and executing a corresponding test operation by using the debugging data frame, so as to realize service multiplexing on the same UART physical link on the chip.

Description

Technical Field

[0001] This application relates to the field of communication technology, and more specifically, to a data frame processing method, apparatus, and testing equipment. Background Technology

[0002] Chips typically have a UART port, through which they can connect to debuggers to perform debugging tasks and exchange service data packets with other devices. For example, during chip debugging, a debugger (such as a JTAG / SWD debugger) connects to the target chip via a dedicated debug pin; during chip service processing, the chip communicates service data packets with other devices via UART pins. However, current chips only support debugging or service processing at a time. To perform both operations simultaneously, more UART pins need to be provided on the chip, but some chips do not provide enough. If the same UART pin is used to switch between debugging and service processing, there will be switching delays, resulting in data loss. Summary of the Invention

[0003] The purpose of this application is to provide a data frame processing method, apparatus, and testing equipment, so as to enable the chip to simultaneously perform debugging operations and business data.

[0004] In a first aspect, embodiments of this application provide a data frame processing method, including: The UART interface receives extended UART frames sent by the chip. The extended UART frames include frame type bits, which are embedded in the physical layer data frames. The data frame type of the extended UART frame is determined based on the identification information corresponding to the frame type bit in the extended UART frame, wherein the data frame type includes user data frame or debug data frame; Each extended UART frame is classified and processed according to its data frame type.

[0005] In this embodiment, by adding a frame type bit to the physical layer of the UART frame and setting different identification information in the frame type bit, with different identification information corresponding to different data frame types, the debugger determines the corresponding data frame type by judging the identification information. The data frame type includes user data frames or debug data frames. According to the data frame types of different extended UART frames, each extended UART frame is classified and processed, that is, the user data frame is sent to the user terminal, and the debug data frame is used to perform the corresponding test operation, thereby realizing the service multiplexing on the same UART physical link on the chip.

[0006] Optionally, determining the data frame type of the extended UART frame based on the identifier information corresponding to the frame type bit in the extended UART frame includes: If the identification information is a first identifier, the data frame type of the extended UART frame is determined to be a user data frame; If the identification information is the second identifier, the data frame type of the extended UART frame is determined to be a debug data frame.

[0007] In this embodiment, by setting a frame type bit, different identification information is set for the frame type bit, and data frames are classified by distinguishing them through the frame type bit, thereby realizing the service reuse of the same UART.

[0008] Optionally, classifying each extended UART frame according to its data frame type includes: If the data frame type of the extended UART frame is a user data frame, the extended UART frame is encapsulated according to the protocol format of the user terminal to obtain an encapsulated data packet, and the encapsulated data packet is sent to the user terminal. If the data frame type of the extended UART frame is a debug data frame, the debug data frame is encapsulated to obtain a test data packet, which is used to execute the test function.

[0009] In this embodiment, user data frames and debug data frames are distinguished according to different identifiers of frame type bits. The acquired user data frames are sent to the user terminal, the debug data frames are processed, and the processed data packets are used to perform test functions, thereby realizing the service reuse of the same UART.

[0010] Optionally, if the data frame type of the extended UART frame is a debug data frame, the debug data frame is encapsulated to obtain a test data packet, which is used to execute test functions, including: The debug data frame is parsed to obtain the data content in the debug data frame; The data content is encapsulated according to the format of target synchronization word, length, payload and first checksum to obtain the test data packet. The synchronization word is a frame header identifier. The test data packet is used to perform test functions.

[0011] Optionally, the data content is encapsulated according to the format of target synchronization word, target length, payload, and first checksum to obtain the test data packet, including: The data content is matched with the preset synchronization word to determine the target synchronization word; The target length is determined based on the target synchronization word and the preset bytes; The target synchronization word, the target length, the payload, and the first checksum are encapsulated to obtain the test data packet. The first checksum is calculated by the chip using a preset checksum algorithm on the data of the target length and the payload.

[0012] In this embodiment, the physical layer carries debugging data through debugging data frames, and the link layer performs framing based on the debugging data frames using synchronization words, length, and CRC checksums. The two layers work together to achieve the unity of zero intrusion into the user channel and transparent transmission of debugging data.

[0013] Optionally, the method further includes: The preset verification algorithm is used to calculate the target length data and the payload to obtain a second verification code, wherein the preset verification algorithm includes CRC; Compare the first checksum and the second checksum; If the first check code and the second check code are the same, a test data packet is generated based on the physical layer data frame, and the test data packet is used to execute the corresponding test function.

[0014] In this embodiment, execution is performed after double confirmation by synchronization word locking and CRC check to prevent accidental termination due to data content.

[0015] Optionally, the method further includes: The chip is controlled to exit the debug state using the following control methods: chip hardware reset, setting the flag bit of the configuration register to the off state, and sending an exit command frame to the chip.

[0016] In this embodiment, the exit command is executed as a link layer frame after being double-confirmed by synchronization word locking and CRC check, to prevent data content from accidentally triggering the exit.

[0017] Optionally, the extended UART frame further includes a connection authentication bit, which is embedded in the physical layer data frame. Prior to receiving the extended UART frame via the UART interface receiving chip, the method further includes: Send a connection request to the chip, the connection request including a connection identifier with a connection verification bit; When the chip receives the connection identifier and sets the connection verification bit of the extended UART frame to the connection identifier, the chip receives connection response information returned by the chip, the connection response information including the connection identifier.

[0018] In this embodiment, the connection verification bit (EXT bit) of all transmitted frames is forcibly set to a preset value by hardware, so that the debugger can identify the connection status by monitoring the EXT bit characteristics, and the hardware automatically distinguishes between the debugging active state and the normal state.

[0019] Optionally, the method further includes: Without transmitting extended UART frames, the chip receives heartbeat data frames via the UART interface. These heartbeat data frames are used by the chip and the debugger to maintain a communication connection.

[0020] In this embodiment, when both the user and the debugging channel are idle, the chip automatically sends heartbeat debugging frames to maintain the physical characteristics of the line maintaining communication without software intervention.

[0021] Secondly, embodiments of this application provide a data frame processing apparatus, including: The receiving module is used to receive extended UART frames sent by the chip through the UART interface. The extended UART frames include frame type bits, which are embedded in the physical layer data frames. The determination module is used to determine the data frame type of the extended UART frame based on the identification information corresponding to the frame type bit in the extended UART frame, wherein the data frame type includes user data frame or debug data frame; The processing module is used to classify and process each of the extended UART frames according to the data frame type of the extended UART frames.

[0022] In this embodiment, by adding a frame type bit to the physical layer of the UART frame and setting different identification information in the frame type bit, with different identification information corresponding to different data frame types, the debugger determines the corresponding data frame type by judging the identification information. The data frame type includes user data frames or debug data frames. According to the data frame types of different extended UART frames, each extended UART frame is classified and processed, that is, the user data frame is sent to the user terminal, and the debug data frame is used to perform the corresponding test operation, thereby realizing the service multiplexing on the same UART physical link on the chip.

[0023] Optionally, the determining module is configured to: If the identification information is a first identifier, the data frame type of the extended UART frame is determined to be a user data frame; If the identification information is the second identifier, the data frame type of the extended UART frame is determined to be a debug data frame.

[0024] In this embodiment, by setting a frame type bit, different identification information is set for the frame type bit, and data frames are classified by distinguishing them through the frame type bit, thereby realizing the service reuse of the same UART.

[0025] Optionally, the processing module is configured to: If the data frame type of the extended UART frame is a user data frame, the extended UART frame is encapsulated according to the protocol format of the user terminal to obtain an encapsulated data packet, and the encapsulated data packet is sent to the user terminal. If the data frame type of the extended UART frame is a debug data frame, the debug data frame is encapsulated to obtain a test data packet, which is used to execute the test function.

[0026] In this embodiment, user data frames and debug data frames are distinguished according to different identifiers of frame type bits. The acquired user data frames are sent to the user terminal, the debug data frames are processed, and the processed data packets are used to perform test functions, thereby realizing the service reuse of the same UART.

[0027] Optionally, the processing module is configured to: The debug data frame is parsed to obtain the data content in the debug data frame; The data content is encapsulated according to the format of target synchronization word, length, payload and first checksum to obtain the test data packet. The synchronization word is a frame header identifier. The test data packet is used to perform test functions.

[0028] Optionally, the processing module is configured to: The data content is matched with the preset synchronization word to determine the target synchronization word; The target length is determined based on the target synchronization word and the preset bytes; The target synchronization word, the target length, the payload, and the first checksum are encapsulated to obtain the test data packet. The first checksum is calculated by the chip using a preset checksum algorithm on the data of the target length and the payload.

[0029] In this embodiment, the physical layer carries debugging data through debugging data frames, and the link layer performs framing based on the debugging data frames using synchronization words, length, and CRC checksums. The two layers work together to achieve the unity of zero intrusion into the user channel and transparent transmission of debugging data.

[0030] Optionally, the processing module is configured to: The preset verification algorithm is used to calculate the target length data and the payload to obtain a second verification code, wherein the preset verification algorithm includes CRC; Compare the first checksum and the second checksum; If the first check code and the second check code are the same, a test data packet is generated based on the physical layer data frame, and the test data packet is used to execute the corresponding test function.

[0031] In this embodiment, execution is performed after double confirmation by synchronization word locking and CRC check to prevent accidental termination due to data content.

[0032] Optionally, the processing module is configured to: The chip is controlled to exit the debug state using the following control methods: chip hardware reset, setting the flag bit of the configuration register to the off state, and sending an exit command frame to the chip.

[0033] In this embodiment, the exit command is executed as a link layer frame after being double-confirmed by synchronization word locking and CRC check, to prevent data content from accidentally triggering the exit.

[0034] Optionally, the extended UART frame further includes a connection authentication bit, which is embedded in the physical layer data frame. The receiving module is configured to: Send a connection request to the chip, the connection request including a connection identifier with a connection verification bit; When the chip receives the connection identifier and sets the connection verification bit of the extended UART frame to the connection identifier, the chip receives connection response information returned by the chip, the connection response information including the connection identifier.

[0035] In this embodiment, the connection verification bit (EXT bit) of all transmitted frames is forcibly set to a preset value by hardware, so that the debugger can identify the connection status by monitoring the EXT bit characteristics, and the hardware automatically distinguishes between the debugging active state and the normal state.

[0036] Optionally, the receiving module is configured to: Without transmitting extended UART frames, the chip receives heartbeat data frames via the UART interface. These heartbeat data frames are used by the chip and the debugger to maintain a communication connection.

[0037] In this embodiment, when both the user and the debugging channel are idle, the chip automatically sends heartbeat debugging frames to maintain the physical characteristics of the line maintaining communication without software intervention.

[0038] Thirdly, embodiments of this application provide a test device for performing the data frame processing method as described in any of the first aspects. Attached Figure Description

[0039] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0040] Figure 1 A flowchart illustrating a data frame processing method provided in an embodiment of this application; Figure 2 A schematic diagram of an extended UART frame provided in an embodiment of this application; Figure 3 A schematic diagram of a chip package extended UART frame provided in an embodiment of this application; Figure 4 A schematic diagram illustrating the process of a debugger parsing an extended UART frame according to an embodiment of this application; Figure 5 A schematic diagram illustrating the process of reassembling extended UART frames using a debugger provided in an embodiment of this application; Figure 6 This is a schematic diagram of a data frame processing device provided in an embodiment of this application. Detailed Implementation

[0041] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0042] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0043] Chips typically have a UART port, through which they can connect to debuggers to perform debugging tasks and exchange service data packets with other devices. For example, during chip debugging, a debugger (such as a JTAG / SWD debugger) connects to the target chip via a dedicated debug pin; during chip service processing, the chip communicates service data packets with other devices via UART pins. However, current chips only support debugging or service processing at a time. To perform both operations simultaneously, more UART pins need to be provided on the chip, but some chips do not provide enough. If the same UART pin is used to switch between debugging and service processing, there will be switching delays, resulting in data loss.

[0044] Based on this, embodiments of this application provide a data frame processing method, including receiving extended UART frames sent by a chip through a UART interface. The extended UART frame includes a frame type bit embedded in a physical layer data frame. The method determines the data frame type of the extended UART frame based on the identification information corresponding to the frame type bit, wherein the data frame type includes user data frames or debug data frames. The method then classifies each extended UART frame according to its data frame type. By adding a frame type bit to the physical layer of the UART frame and setting different identification information in the frame type bit, with different identification information corresponding to different data frame types, the debugger determines the corresponding data frame type by judging the identification information. This data frame type includes user data frames or debug data frames. Based on the different data frame types of the extended UART frames, the method classifies each extended UART frame, sending user data frames to the user terminal and using debug data frames to perform corresponding test operations, thus achieving service multiplexing on the same UART physical link on the chip.

[0045] like Figure 1 As shown, this application provides a data frame processing method, which may include the following steps: S101. Receive extended UART frames sent by the chip through the UART interface. The extended UART frame includes a frame type bit, which is embedded in the physical layer data frame. Specifically, the debugger (i.e., test device) is connected to the chip via a UART interface. The debugger can be a JTAG / SWD debugger. In order to achieve service reuse using the same UART interface, this application embodiment adds a frame type bit to the physical layer of the UART protocol to generate an extended UART frame. That is, the protocol format of the extended UART frame includes a start bit, D0-D7 data content, frame type bit, and stop bit.

[0046] In some application scenarios, the chip needs to perform debugging tasks while executing business operations. Therefore, the chip generates user data frames from business data content, specifically with a start bit, D0-D7 business data content, frame type bits, and stop bits; and generates debug data frames from debug data, specifically with a start bit, D0-D7 business data content, frame type bits, and stop bits. The identification information set in the frame type bits of user data frames and debug data frames is different.

[0047] During operation, the chip sends extended UART frames to the debugger. These extended UART frames include user data frames and debug data frames, which are sent randomly.

[0048] S102. Determine the data frame type of the extended UART frame according to the identification information corresponding to the frame type bit in the extended UART frame, wherein the data frame type includes user data frame or debug data frame. Specifically, after receiving an extended UART frame, the debugger parses the extended UART frame to obtain the identification information corresponding to the frame type bit in each extended UART frame. Then, based on the different identification information, it determines the corresponding data type. For example, if the identification information is 1, the corresponding data type is a user data frame; if the identification information is 0, the corresponding data type is a debug data frame.

[0049] S103. According to the data frame type of the extended UART frame, classify and process each extended UART frame.

[0050] Specifically, the debugger classifies user data frames and debug data frames according to different types of data frames. It converts the received user data frames, encapsulates them into user data packets that conform to the user terminal's protocol, and sends the user data packets to the user terminal to complete the transmission of service data. At the same time, it converts the received debug data frames into link layer debug data packets and performs debugging operations on the debug data packets to complete the debugging work. In this way, it realizes service multiplexing on the same UART physical link on the chip.

[0051] In this embodiment, by adding a frame type bit to the physical layer of the UART frame and setting different identification information in the frame type bit, with different identification information corresponding to different data frame types, the debugger determines the corresponding data frame type by judging the identification information. The data frame type includes user data frames or debug data frames. According to the data frame types of different extended UART frames, each extended UART frame is classified and processed, that is, the user data frame is sent to the user terminal, and the debug data frame is used to perform the corresponding test operation, thereby realizing the service multiplexing on the same UART physical link on the chip.

[0052] Another embodiment of this application further supplements the description of the data frame processing method provided in the above embodiments.

[0053] Optionally, determining the data frame type of the extended UART frame based on the identifier information corresponding to the frame type bit in the extended UART frame includes: If the identification information is a first identifier, the data frame type of the extended UART frame is determined to be a user data frame; If the identification information is the second identifier, the data frame type of the extended UART frame is determined to be a debug data frame.

[0054] Specifically, such as Figure 2As shown, this application embodiment extends the physical layer of the UART frame by inserting 1 extra data bit (EXT) and 1 frame type bit (FT) after the 8 data bits and before the stop bit of the standard UART frame to form an extended frame format. The EXT bit is not only a connection verification bit, but can also be bound to the debug_active state as a global mode indicator.

[0055] If FT=0, the identification information is the first identifier, the 8-bit data field is the service data, and the EXT bit is determined by hardware behavior, thus determining that the data frame type of the extended UART frame is a user data frame.

[0056] If FT=1, the identification information is the second identifier: debug data frame. The 8-bit data field is debug protocol data, which is organized according to the link layer frame format. This determines that the data frame type of the extended UART frame is a debug data frame.

[0057] In this embodiment, by setting a frame type bit and assigning different identification information to it, data frames are classified and distinguished, thereby enabling service multiplexing within the same UART. The physical layer uses the FT bit to achieve real-time splitting of user frames and debug frames, ensuring seamless and transparent user data path transmission. The link layer, based on a continuous FT=1 frame stream, reassembles it into a complete debug data packet through synchronization word positioning, length field definition, and CRC check protection. The two-level structure works collaboratively, achieving both service concurrency and reliable transmission of debug data.

[0058] Optionally, classifying each extended UART frame according to its data frame type includes: If the data frame type of the extended UART frame is a user data frame, the extended UART frame is encapsulated according to the protocol format of the user terminal to obtain an encapsulated data packet, and the encapsulated data packet is sent to the user terminal. If the data frame type of the extended UART frame is a debug data frame, the debug data frame is encapsulated to obtain a test data packet, which is used to execute the test function.

[0059] like Figure 4 As shown, the debugger receives extended UART frames sent by the chip through the RX pin and parses the extended UART frames to obtain the start bit, EXT bit, and FT bit (frame type bit). Based on the FT bit, the received extended UART frames are split. If FT=0, it means that the extended UART frame is a user frame, and the user frame is stored in the user FIFO, i.e., the user buffer queue. According to the protocol format of the user terminal, the extended UART frame is encapsulated to obtain the encapsulated data packet, and the encapsulated data packet is sent to the user terminal (i.e., the user system). If FT=1, it indicates that the data frame type of this extended UART frame is a debug data frame. The debug data frame is encapsulated to obtain a test data packet, which is used to execute test functions. Specific operations are as follows: Figure 5 As shown.

[0060] In this embodiment, user data frames and debug data frames are distinguished according to different identifiers of frame type bits. The acquired user data frames are sent to the user terminal, the debug data frames are processed, and the processed data packets are used to perform test functions, thereby realizing the service reuse of the same UART.

[0061] Optionally, if the data frame type of the extended UART frame is a debug data frame, the debug data frame is encapsulated to obtain a test data packet, which is used to execute test functions, including: The debug data frame is parsed to obtain the data content in the debug data frame; The data content is encapsulated according to the format of target synchronization word, length, payload and first checksum to obtain the test data packet. The synchronization word is a frame header identifier. The test data packet is used to perform test functions.

[0062] Specifically, in the debug data frame received by the debugger, FT=1, and the 8-bit data field carries one byte of the link layer frame. Multiple consecutive debug data frames (FT=1) are combined to form the data. The format of the generated test data packet is shown in Table 1.

[0063] Table 1 The debugger parses each received debug data frame to obtain the start bit, data bits D0-D7, EXT bit, FT frame type, and stop bit. It then removes the start bit, EXT bit, FT frame type, and stop bit, retaining only the data bits D0-D7. The data bits from each debug data frame are concatenated to form a data sequence, which is the data content of the debug data frame. This data content is then encapsulated according to the format of the target synchronization word, length, payload, and first checksum to obtain the test data packet. The synchronization word serves as the frame header identifier, and the test data packet is used to execute test functions.

[0064] In this embodiment, the data link layer explicitly specifies the number of bytes to be received through the length field. The payload can carry any number of bytes without escaping or the risk of accidentally triggering an exit command. The debug data payload is completely transparent.

[0065] Optionally, the data content is encapsulated according to the format of target synchronization word, target length, payload, and first checksum to obtain the test data packet, including: The data content is matched with the preset synchronization word to determine the target synchronization word; The target length is determined based on the target synchronization word and the preset bytes; The target synchronization word, the target length, the payload, and the first checksum are encapsulated to obtain the test data packet. The first checksum is calculated by the chip using a preset checksum algorithm on the data of the target length and the payload.

[0066] like Figure 5 As shown, the chip enables the extended frame activation mode. That is, the chip enters the extended frame mode after detecting a specific activation sequence through hardware or configuring relevant registers in the kernel. The debug_active signal is set, and the activation sequence can be defined as receiving a number of extended frames that conform to a specific format consecutively.

[0067] When debug_active is active, the chip is in an active state, and the EXT bit of all transmitted frames is forcibly set to 1 by hardware. One byte is retrieved from the user buffer queue FIFO, loaded into an 8-bit data field, FT=0, EXT=1, forming a user extended frame. The debug data is packetized according to the link layer frame format (first sending the synchronization word 0xF0F0, then the length byte, then the payload byte, and finally the 2-byte CRC), with each byte loaded into an FT=1 extended frame and sent sequentially. If both the user FIFO and debug FIFO are idle, the hardware can automatically insert a heartbeat debug frame (FT=1, fixed synchronization word in the link layer frame, length=0, CRC of a pre-defined value) to maintain the continuous presence of EXT=1 on the line, facilitating the debugger's identification of the connection's active state.

[0068] The debugger automatically splits the data based on the FT frame type bit in the received extended UART frame: If FT=0 frame: the EXT bit is stripped and 8 bits of data are stored in the user FIFO. The user data path is completely undetectable, achieving zero intrusion and complete transparency: the EXT and FT bits of the FT=0 frame are automatically stripped by hardware, and the data received by the user FIFO is completely consistent with the standard UART.

[0069] If FT=1 frame: send 8 bits of data into the debugger's shift register.

[0070] like Figure 5 As shown, the debugger internally performs link layer frame synchronization and extraction: Search mode: The debugger continuously monitors the input byte stream, i.e., the data sequence, and matches the data sequence with a preset 16-bit synchronization word. The data sequence that completely matches the preset 16-bit synchronization word is selected as the target synchronization word.

[0071] Locked state: After the debugger determines the target synchronization word, it reads the next byte as the length field L, which is the target length.

[0072] Receive state: Receive L bytes of payload and 2 bytes of CRC (first checksum) sequentially. During this period, no synchronization word is detected to ensure that the data is completely transparent.

[0073] Verification state: CRC, or second checksum, is calculated in real time for the target length and payload. The second checksum is compared with the first checksum. If they are connected, the debug data packet is uploaded to the upper layer to perform the test function. If they are not the same, the debug data packet is discarded and the search state is returned.

[0074] Timeout Protection: If an unexpected timeout occurs during the lock and receive phases of the debugger, the state is automatically reset to the search state to avoid deadlock. As long as the chip is in debug mode, it will periodically send heartbeat frames with the EXT=1 feature. If the debugger does not receive any EXT=1 frames or fails to complete link layer synchronization within the set time, it will determine that the link is abnormal, actively reset the receive state machine, and re-enter the frame synchronization search state, thereby achieving self-recovery from disconnection and improving system robustness.

[0075] In this embodiment, the physical layer carries debugging data through debugging data frames, and the link layer performs framing based on the debugging data frames using synchronization words, length, and CRC checksums. The two layers work together to achieve the unity of zero intrusion into the user channel and transparent transmission of debugging data.

[0076] Optionally, the method further includes: The preset verification algorithm is used to calculate the target length data and the payload to obtain a second verification code, wherein the preset verification algorithm includes CRC; Compare the first checksum and the second checksum; If the first check code and the second check code are the same, a test data packet is generated based on the physical layer data frame, and the test data packet is used to execute the corresponding test function.

[0077] Specifically, the debug frame has 16-bit synchronization word and 16-bit CRC protection, which can quickly restore frame synchronization from the bit stream. The exit debug command is checked by CRC to prevent accidental exit due to coincidence in data content.

[0078] In this embodiment, execution is performed after double confirmation by synchronization word locking and CRC check to prevent accidental termination due to data content.

[0079] Optionally, the method further includes: The chip is controlled to exit the debug state using the following control methods: chip hardware reset, setting the flag bit of the configuration register to the off state, and sending an exit command frame to the chip.

[0080] Specifically, to exit debug mode, the chip can be reset via hardware, configured through the debugger by clearing the debug_active flag, or a pre-defined exit command frame can be sent to the debugger. This frame is a specific link-layer frame (e.g., synchronization word 0xF0F0, length = 0, CRC = a specific value). After the debugger's CRC check passes, debug_active is cleared. After exiting debug mode, the EXT bit reverts to its original behavior (EXT = 0), and the debugger detects the disappearance of the EXT feature and disconnects.

[0081] In this embodiment, the exit command is executed as a link layer frame after being double-confirmed by synchronization word locking and CRC check, to prevent data content from accidentally triggering the exit.

[0082] Optionally, the extended UART frame further includes a connection authentication bit, which is embedded in the physical layer data frame. Prior to receiving the extended UART frame via the UART interface receiving chip, the method further includes: Send a connection request to the chip, the connection request including a connection identifier with a connection verification bit; When the chip receives the connection identifier and sets the connection verification bit of the extended UART frame to the connection identifier, the chip receives connection response information returned by the chip, the connection response information including the connection identifier.

[0083] Specifically, this application inserts a frame type bit (FT) and a connection verification bit (EXT) into a standard UART frame. The FT bit is used to distinguish between user data frames and debug data frames, and the EXT bit is used to determine the connection status between the debugger and the chip, thereby realizing service multiplexing on the same UART physical link.

[0084] In this embodiment, the connection verification bit, i.e. the extra data bit (EXT bit), of all transmitted frames is forcibly set to a preset value by the hardware, so that the debugger can identify the connection status by monitoring the EXT bit characteristics, and the hardware automatically distinguishes between the active debugging state and the normal state.

[0085] Optionally, the method further includes: Without transmitting extended UART frames, the chip receives heartbeat data frames via the UART interface. These heartbeat data frames are used by the chip and the debugger to maintain a communication connection.

[0086] like Figure 3As shown, the chip retrieves user data from the user buffer queue, sets the frame type bit (FT) to 0 and EXT=1, and assembles user data frames. The chip retrieves debug data from the debug buffer queue, sets the frame type bit (FT) to 1 and EXT=1, and assembles debug data frames. The data selector in the chip can send debug data frames first, or send debug data frames and user data frames in a round-robin fashion. The chip assembles user data frames and debug data frames according to the start bit, data content, EXT, FT and stop bits of each frame.

[0087] If no data is transmitted between the chip and the debugger, and the connection is maintained, the chip sends heartbeat data frames to the debugger. In other words, when both the user and the debug channel are idle, the chip automatically sends heartbeat debug frames to maintain the physical characteristics of the line communication without software intervention. The debugger keeps the link active by continuously sending heartbeat frames, and the receiving end avoids deadlock through a timeout mechanism, making the system highly robust.

[0088] This application proposes a UART multiplexing communication method based on frame type extension. It uses only the original TX / RX signal lines of the UART, eliminating the need for additional debug pins, and can simultaneously carry user data and debug data, reducing chip pin usage and packaging costs. Only a small number of state machines, comparators, counters, and registers need to be added to the UART transmit / receive logic, making it easy to integrate into the MCU's UART peripheral without adding external components. The frame format is extended at the UART physical layer by inserting frame type bits (FT) and extra data bits (EXT). The FT bit is used to distinguish between user data frames and debug data frames. Simultaneously, within the debug data frame, a link-layer framing format based on synchronization words and length is further adopted to achieve transparent and reliable transmission of debug data.

[0089] It should be noted that each of the implementable methods in this embodiment can be implemented individually or in any combination without conflict. This application does not limit this.

[0090] Please refer to Figure 6 , Figure 6 A block diagram illustrating the composition of a data frame processing apparatus provided in some embodiments of this application is shown. It should be understood that this data frame processing apparatus is similar to the one described above. Figure 1 Corresponding to the method embodiments, it is able to perform each step involved in the above method embodiments. The specific functions of the data frame processing device can be found in the description above. To avoid repetition, detailed descriptions are appropriately omitted here.

[0091] Figure 6The data frame processing apparatus includes at least one software functional module that can be stored in a memory or embedded in the data frame processing apparatus in the form of software or firmware. The data frame processing apparatus includes: The receiving module 601 is used to receive extended UART frames sent by the chip through the UART interface. The extended UART frame includes a frame type bit, which is embedded in the physical layer data frame. The determining module 602 is used to determine the data frame type of the extended UART frame based on the identification information corresponding to the frame type bit in the extended UART frame, wherein the data frame type includes user data frame or debug data frame; The processing module 603 is used to classify and process each of the extended UART frames according to the data frame type of the extended UART frames.

[0092] In this embodiment, by adding a frame type bit to the physical layer of the UART frame and setting different identification information in the frame type bit, with different identification information corresponding to different data frame types, the debugger determines the corresponding data frame type by judging the identification information. The data frame type includes user data frames or debug data frames. According to the data frame types of different extended UART frames, each extended UART frame is classified and processed, that is, the user data frame is sent to the user terminal, and the debug data frame is used to perform the corresponding test operation, thereby realizing the service multiplexing on the same UART physical link on the chip.

[0093] Optionally, the determining module is configured to: If the identification information is a first identifier, the data frame type of the extended UART frame is determined to be a user data frame; If the identification information is the second identifier, the data frame type of the extended UART frame is determined to be a debug data frame.

[0094] In this embodiment, by setting a frame type bit, different identification information is set for the frame type bit, and data frames are classified by distinguishing them through the frame type bit, thereby realizing the service reuse of the same UART.

[0095] Optionally, the processing module is configured to: If the data frame type of the extended UART frame is a user data frame, the extended UART frame is encapsulated according to the protocol format of the user terminal to obtain an encapsulated data packet, and the encapsulated data packet is sent to the user terminal. If the data frame type of the extended UART frame is a debug data frame, the debug data frame is encapsulated to obtain a test data packet, which is used to execute the test function.

[0096] In this embodiment, user data frames and debug data frames are distinguished according to different identifiers of frame type bits. The acquired user data frames are sent to the user terminal, the debug data frames are processed, and the processed data packets are used to perform test functions, thereby realizing the service reuse of the same UART.

[0097] Optionally, the processing module is configured to: The debug data frame is parsed to obtain the data content in the debug data frame; The data content is encapsulated according to the format of target synchronization word, length, payload and first checksum to obtain the test data packet. The synchronization word is a frame header identifier. The test data packet is used to perform test functions.

[0098] Optionally, the processing module is configured to: The data content is matched with the preset synchronization word to determine the target synchronization word; The target length is determined based on the target synchronization word and the preset bytes; The target synchronization word, the target length, the payload, and the first checksum are encapsulated to obtain the test data packet. The first checksum is calculated by the chip using a preset checksum algorithm on the data of the target length and the payload.

[0099] In this embodiment, the physical layer carries debugging data through debugging data frames, and the link layer performs framing based on the debugging data frames using synchronization words, length, and CRC checksums. The two layers work together to achieve the unity of zero intrusion into the user channel and transparent transmission of debugging data.

[0100] Optionally, the processing module is configured to: The preset verification algorithm is used to calculate the target length data and the payload to obtain a second verification code, wherein the preset verification algorithm includes CRC; Compare the first checksum and the second checksum; If the first check code and the second check code are the same, a test data packet is generated based on the physical layer data frame, and the test data packet is used to execute the corresponding test function.

[0101] In this embodiment, execution is performed after double confirmation by synchronization word locking and CRC check to prevent accidental termination due to data content.

[0102] Optionally, the processing module is configured to: The chip is controlled to exit the debug state using the following control methods: chip hardware reset, setting the flag bit of the configuration register to the off state, and sending an exit command frame to the chip.

[0103] In this embodiment, the exit command is executed as a link layer frame after being double-confirmed by synchronization word locking and CRC check, to prevent data content from accidentally triggering the exit.

[0104] Optionally, the extended UART frame further includes a connection authentication bit, which is embedded in the physical layer data frame. The receiving module is configured to: Send a connection request to the chip, the connection request including a connection identifier with a connection verification bit; When the chip receives the connection identifier and sets the connection verification bit of the extended UART frame to the connection identifier, the chip receives connection response information returned by the chip, the connection response information including the connection identifier.

[0105] In this embodiment, the connection verification bit (EXT bit) of all transmitted frames is forcibly set to a preset value by hardware, so that the debugger can identify the connection status by monitoring the EXT bit characteristics, and the hardware automatically distinguishes between the debugging active state and the normal state.

[0106] Optionally, the receiving module is configured to: Without transmitting extended UART frames, the chip receives heartbeat data frames via the UART interface. These heartbeat data frames are used by the chip and the debugger to maintain a communication connection.

[0107] In this embodiment, when both the user and the debugging channel are idle, the chip automatically sends heartbeat debugging frames to maintain the physical characteristics of the line maintaining communication without software intervention.

[0108] It is understood that the above-described device embodiments correspond to the method embodiments of the present invention. The data frame processing device provided by the embodiments of the present invention can implement the data frame processing method provided by any one of the method embodiments of the present invention.

[0109] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the device described above can be referred to the corresponding process in the aforementioned method, and will not be elaborated further here.

[0110] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For apparatus embodiments, since they are basically similar to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0111] It should be understood, in the several embodiments provided in this application, that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative; for example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0112] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0113] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0114] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application. It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0115] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0116] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A data frame processing method, characterized in that, The method includes: The UART interface receives extended UART frames sent by the chip. The extended UART frames include frame type bits, which are embedded in the physical layer data frames. The data frame type of the extended UART frame is determined based on the identification information corresponding to the frame type bit in the extended UART frame, wherein the data frame type includes user data frame or debug data frame; Each extended UART frame is classified and processed according to its data frame type.

2. The data frame processing method according to claim 1, characterized in that, The step of determining the data frame type of the extended UART frame based on the identifier information corresponding to the frame type bit in the extended UART frame includes: If the identification information is a first identifier, the data frame type of the extended UART frame is determined to be a user data frame; If the identification information is the second identifier, the data frame type of the extended UART frame is determined to be a debug data frame.

3. The data frame processing method according to claim 2, characterized in that, The step of classifying each extended UART frame according to its data frame type includes: If the data frame type of the extended UART frame is a user data frame, the extended UART frame is encapsulated according to the protocol format of the user terminal to obtain an encapsulated data packet, and the encapsulated data packet is sent to the user terminal. If the data frame type of the extended UART frame is a debug data frame, the debug data frame is encapsulated to obtain a test data packet, which is used to execute the test function.

4. The data frame processing method according to claim 3, characterized in that, If the data frame type of the extended UART frame is a debug data frame, the debug data frame is encapsulated to obtain a test data packet, which is used to execute test functions, including: The debug data frame is parsed to obtain the data content in the debug data frame; The data content is encapsulated according to the format of target synchronization word, length, payload and first checksum to obtain the test data packet. The synchronization word is a frame header identifier. The test data packet is used to perform test functions.

5. The data frame processing method according to claim 4, characterized in that, The data content is encapsulated according to the format of target synchronization word, target length, payload, and first checksum to obtain the test data packet, which includes: The data content is matched with the preset synchronization word to determine the target synchronization word; The target length is determined based on the target synchronization word and the preset bytes; The target synchronization word, the target length, the payload, and the first checksum are encapsulated to obtain the test data packet. The first checksum is calculated by the chip using a preset checksum algorithm on the data of the target length and the payload.

6. The data frame processing method according to claim 5, characterized in that, The method further includes: The preset verification algorithm is used to calculate the target length data and the payload to obtain a second verification code, wherein the preset verification algorithm includes CRC; Compare the first checksum and the second checksum; If the first check code and the second check code are the same, a test data packet is generated based on the physical layer data frame, and the test data packet is used to execute the corresponding test function.

7. The data frame processing method according to claim 1, characterized in that, The method further includes: The chip is controlled to exit the debug state using the following control methods: chip hardware reset, setting the flag bit of the configuration register to the off state, and sending an exit command frame to the chip.

8. The data frame processing method according to claim 1, characterized in that, The extended UART frame also includes a connection authentication bit, which is embedded in the physical layer data frame. Prior to receiving the extended UART frame via the UART interface receiving chip, the method further includes: Send a connection request to the chip, the connection request including a connection identifier with a connection verification bit; When the chip receives the connection identifier and sets the connection verification bit of the extended UART frame to the connection identifier, the chip receives connection response information returned by the chip, the connection response information including the connection identifier.

9. The data frame processing method according to claim 1, characterized in that, The method further includes: Without transmitting extended UART frames, the chip receives heartbeat data frames via the UART interface. These heartbeat data frames are used by the chip and the debugger to maintain a communication connection.

10. A data frame processing apparatus, characterized in that, The device includes: The receiving module is used to receive extended UART frames sent by the chip through the UART interface. The extended UART frames include frame type bits, which are embedded in the physical layer data frames. The determination module is used to determine the data frame type of the extended UART frame based on the identification information corresponding to the frame type bit in the extended UART frame, wherein the data frame type includes user data frame or debug data frame; The processing module is used to classify and process each of the extended UART frames according to the data frame type of the extended UART frames.

11. A testing device, characterized in that, Used to perform the data frame processing method as described in any one of claims 1-9.

Images