Debugging method and device for digital signal processing chip and medium
By obtaining the DSP chip's mapping file and binding the transmission channel, the physical address and real-time variable values can be read directly, solving the problem of CPU pause during DSP debugging. This enables efficient and interference-free debugging operations and ensures business continuity.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SRNE SOLAR CO LTD
- Filing Date
- 2025-12-30
- Publication Date
- 2026-05-12
AI Technical Summary
Existing DSP debugging techniques require pausing CPU operation, which compromises real-time response requirements and may mask potential system problems, making it difficult to reproduce and troubleshoot faults during continuous operation.
By obtaining the mapping file and binding the correspondence between the variables to be read and the transmission channel, the physical address and real-time value of the variables can be read directly based on the communication protocol, avoiding CPU pause and enabling parallel debugging operations and business execution.
Significantly shorten debugging preparation time, ensure business continuity, avoid modification of DSP chip running code, and achieve efficient and accurate debugging operations.
Smart Images
Figure CN122019460A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of digital signal processing technology, and in particular to a debugging method, device and medium for a digital signal processing chip. Background Technology
[0002] Digital signal processors (DSPs), as microprocessors designed specifically for high-speed digital signal processing, are widely used in critical fields such as industrial control, automotive electronics, aerospace, and audio processing. DSP debugging technology, as a key means to ensure its functional correctness and troubleshoot operational faults, has always been a core requirement in the industry's research and development and application processes.
[0003] Currently, DSP debugging methods are mainly divided into several types, one of which is the on-chip debug interface, which is supported by almost all modern DSP chips. Through a debugger and the JTAG / SWD hardware interface (which requires an emulator / debug probe), it is possible to connect to the debug access port inside the DSP chip for debugging.
[0004] However, this technology has unavoidable limitations in practical applications: On the one hand, its debugging process relies on the core mechanism of pausing CPU operation. Whether setting breakpoints to view variables or reading real-time memory data, it is necessary to briefly or continuously interrupt the normal task scheduling of the DSP chip. This will directly undermine the requirement of "microsecond / millisecond real-time response" for the application scenarios of the DSP chip (such as in real-time motor control and high-frequency signal filtering scenarios, CPU pausing may lead to loss of control signals and data acquisition gaps). On the other hand, interrupt-based debugging may mask potential problems in the system. Some occasional faults (such as real-time task scheduling conflicts and instantaneous data overflows) will only be triggered when the DSP chip is running continuously. However, the CPU pausing caused by the debugger will break the timing conditions for fault triggering, making such problems difficult to reproduce and troubleshoot. Summary of the Invention
[0005] This invention provides a debugging method, device, and medium for digital signal processing chips to solve the problem of needing to pause the CPU when debugging DSP chips.
[0006] This invention discloses a debugging method for a digital signal processing chip, comprising: Obtain the mapping file of the chip to be debugged, obtain the variables to be read, and select the number of transmission channels based on the available memory of the chip to be debugged; Bind the correspondence between the variable to be read and the transmission channel, and configure the parsing ratio of each transmission channel based on the correspondence; Obtain the physical address corresponding to the variable to be read based on the mapping file; The physical address and resolution ratio of each transmission channel are combined into a data packet according to a preset communication protocol, and the data packet is sent to the chip under test so that the chip under test can perform a parsing operation based on the data packet; A read instruction is sent to the chip under test, the read instruction including a target variable, and the real-time value of the variable corresponding to each variable to be read provided by the chip under test is obtained.
[0007] Optionally, the step of retrieving the real-time value of the variable corresponding to each physical address provided by the chip to be debugged includes: Obtain multiple real-time values of the same variable to be read; plot the variable value change curve corresponding to each variable to be read based on the multiple real-time values.
[0008] Optionally, the step of obtaining the real-time values of the multiple variables includes: The read command is sent to the chip under test according to a preset acquisition cycle to obtain the real-time values of multiple variables; or For each variable to be read, a collection trigger parameter is set, and the collection trigger parameter is sent to the chip to be debugged, so that the chip to be debugged can collect multiple real-time values of the variables corresponding to the physical address according to the collection trigger parameter, and form a variable value array. Get the array of variable values; The acquisition triggering parameters include at least one of the following: trigger source, trigger type, trigger threshold, trigger location, total number of points, and interval number of points.
[0009] Optionally, the trigger position includes any one of the beginning, middle, and end; The step of enabling the chip under test to acquire multiple real-time values of the variables corresponding to the physical address according to the acquisition trigger parameters includes: A data buffer is preset in the chip to be debugged, so that the chip to be debugged can continuously collect data based on the interval points and store the real-time value of the variable in the data buffer; And so that when the chip under test detects that the latest real-time value of the variable meets the trigger type and trigger position, the latest real-time value of the variable is used as the trigger point; Based on the trigger point and the trigger position, a certain number of real-time variable values are obtained from the data buffer and / or several more real-time variable values are collected.
[0010] Optionally, the step of obtaining the physical address corresponding to the variable to be read based on the mapping file includes: Obtain the variable type of the variable to be read; If the variable type is a regular variable, the physical address is obtained directly from the mapping file based on the variable to be read; If the variable type is an array variable, then obtain the starting address and total number of bytes corresponding to the variable to be read from the mapping file, obtain the byte offset based on the total number of bytes, and obtain the physical address based on the starting address and the byte offset; If the variable type is a structure variable, then obtain the base address corresponding to the variable to be read from the mapping file, obtain the member offset, and obtain the physical address based on the base address and the member offset.
[0011] Optionally, the step of binding the correspondence between the variable to be read and the transmission channel includes: Obtain the data type corresponding to the variable to be read, wherein the data type includes 16-bit integer and / or 32-bit floating-point; If the data type is a 16-bit integer, then one of the transmission channels is selected and bound to the variable to be read. If the data type is a 32-bit floating-point number, then two of the transmission channels are selected and bound to the variable to be read.
[0012] Optionally, the step of enabling the chip under test to perform parsing operations based on the data packet includes: If the data type is a 16-bit integer, then 2 bytes of data are read according to the physical address corresponding to each variable to be read, and the 2 bytes of data are concatenated to obtain the real-time value of the variable; If the data type is 32-bit floating-point, then 4 bytes of data are obtained according to the physical address corresponding to each variable to be read, and the 4 bytes of data are converted into floating-point values. The floating-point values are compressed according to the parsing ratio to obtain the real-time value of the variable, and the real-time value of the variable is stored in a fixed array.
[0013] Optionally, the step of obtaining the real-time value of the variable corresponding to each physical address provided by the chip to be debugged includes: If the data type of the variable to be read is a 16-bit integer, then the real-time value of the variable is obtained directly through the corresponding transmission channel; If the data type corresponding to the variable to be read is 32-bit floating point, then the real-time value of the variable is obtained from the fixed array through one of the transmission channels corresponding to the variable to be read, and the first 2 bytes of the 4-byte data are obtained through the other transmission channel; the real-time value of the variable is restored to the restored value based on the parsing ratio.
[0014] The present invention also discloses a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform the steps of the method described above.
[0015] The present invention also discloses a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of the method described above.
[0016] The beneficial effects of the debugging method, device, and medium for digital signal processing chips provided in this embodiment of the invention are as follows: Debugging can be performed directly using the variables to be read. The physical address corresponding to the variable is obtained based on the mapping file, avoiding tedious physical address lookup and memorization, significantly shortening the debugging preparation time, and avoiding modification of the DSP chip's running code. The transmission channel is selected based on available memory and its relationship with the variable to be read is bound. Only configuration information such as address and multiplier and reading instructions are sent through a preset communication protocol, without interfering with the execution of the chip's core business logic. The DSP chip obtains the real-time value of the variable by directly reading the physical address, without pausing or restarting the chip's running business process, realizing parallel debugging operations and business execution, thereby ensuring business continuity. Attached Figure Description
[0017] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. In the accompanying drawings: Figure 1 This is a flowchart illustrating an embodiment of the debugging method for a digital signal processing chip provided by the present invention; Figure 2 This is a schematic diagram of an embodiment of the debugging system for a digital signal processing chip provided by the present invention; Figure 3 This is a flowchart illustrating another embodiment of the debugging method for digital signal processing chips provided by the present invention. Detailed Implementation
[0018] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. The preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings.
[0019] This invention provides a debugging method for a digital signal processing chip. Please refer to the following documentation. Figure 1 and Figure 2 , Figure 1 This is a flowchart illustrating an embodiment of the debugging method for a digital signal processing chip provided by the present invention. Figure 2This is a schematic diagram of an embodiment of the debugging system for a digital signal processing chip provided by the present invention. The debugging system for the digital signal processing chip includes a host computer and a chip to be debugged (DSP chip) connected to each other. The host computer is capable of executing... Figure 1 The method shown is used to debug the chip to be debugged.
[0020] The debugging method for the digital signal processing chip provided by this invention specifically includes the following steps: S101: Obtain the mapping file of the chip to be debugged, obtain the variables to be read, and select the number of transmission channels based on the available memory of the chip to be debugged.
[0021] In a specific implementation scenario, after the DSP program is compiled (such as through TICCS or ADIVisualDSP++), a .map file (mapping file) will be generated. It is a memory allocation list that records the correspondence between the name, memory address, and number of bytes occupied by all global variables, static variables, and functions (for example, the variable fIBattReal is allocated at address 0x800120 and occupies 4 bytes; the array fInvCtrlOut
[10] starts at address 0x800200, and each element is 4 bytes, so the address of fInvCtrlOut[1] is 0x800204). Therefore, the .map file provides a dynamic mapping between variables and addresses.
[0022] The variables of the DSP chip are stored in the on-chip RAM (or external extended RAM). The program can directly read and write the value of each variable through the address. After obtaining the address through the .map file, the DSP chip can access the address of any variable as needed without defining fixed monitoring variables in the code in advance.
[0023] The process involves retrieving user-input variables to be read. These variables are defined in the DSP project and exist in the .map file after compilation, allowing the system to locate their corresponding physical addresses. Common variable types include regular variables (global variables), static variables, and array / structure variables.
[0024] Regular variables are variables defined outside of functions (such as float fIBattReal; / / real-time battery current), which are the most commonly monitored objects. The .map file will explicitly record their address and the number of bytes occupied. Static variables are variables modified by static (such as static uint16_tu16ErrorCount; / / error counter). Even if they are static variables inside functions, the .map file will record their fixed address. Array / structure variables need to be entered in the format of "variable + index / member name" (such as array fInvCtrlOut[5], structure member stBatt.voltage).
[0025] Since local variables and register variables are not recorded in the .map file, the variable to be read cannot be a local variable or register variable.
[0026] The variables to be read are different for different variable types. Regular variables can be directly input, and must be exactly the same as the spelling defined in the .map file (case-sensitive, such as fIBattReal≠FIBattReal). Array variables can contain array name + index, and the index can start from 0 (such as the index range of array fInvCtrlOut
[10] is 0~9). Structure member variables can contain base address + offset. Taking stBatt.voltage as an example, the offset of the member voltage is 42 bytes. Because the smallest addressing unit of DSP is 16-bit word, and the address of .map file is also word address, the unit of offset is "word". For structure members, the byte offset must be checked first, and then the byte offset ÷ 2 is used to get the word offset; for arrays, the number of words occupied by a single element must be determined first, and then the word offset is obtained by multiplying the element number by the number of words. Therefore, the variable to be read can be stBatt+21.
[0027] The maximum number of variables that the chip to be debugged can read simultaneously is determined based on the available memory of the chip. Too many channels will lead to insufficient resources, while too few channels will affect debugging efficiency. The most suitable number of channels is selected by combining the memory capacity of the DSP chip and the bandwidth of the communication interface to transmit the relevant data of the variables to be read.
[0028] S102: Bind the correspondence between the variable to be read and the transmission channel, and configure the parsing multiple of each transmission channel based on the correspondence.
[0029] In a specific implementation scenario, the mapping between variables to be read and transmission channels is established. The data type of the variable to be read is obtained, including 16-bit integers and / or 32-bit floating-point numbers. If the data type is a 16-bit integer, one transmission channel is selected to bind to that variable. If the data type is a 32-bit floating-point number, two transmission channels are selected to bind to that variable. For example, taking 8 transmission channels as an example, these 8 channels can be numbered 1, 2, 3…8. If all variables to be read correspond to 16-bit integers, then 8 variables can be set, each corresponding to one of the 8 transmission channels. If all variables to be read correspond to 32-bit floating-point numbers, then 4 variables can be set, with each variable corresponding to 2 transmission channels.
[0030] In other implementation scenarios, the data types of the variables to be read may include both 16-bit integers and 32-bit floating-point numbers. In such cases, the data types are allocated accordingly. For example, two transmission channels are allocated to two 16-bit integer variables to be read, and the remaining six channels are evenly distributed to three 32-bit floating-point variables to be read.
[0031] Specifically, for 32-bit floating-point variables, two parsing methods are used. One channel reads the 4 bytes (2 words, since C20001 words = 2 bytes) of data corresponding to the physical address, converts it to a floating-point value according to the IEEE 754 standard, and then scales it to a 16-bit integer value, storing it in a fixed array `uwCpuDebugData`. `uwCpuDebugData` is a 16-bit integer array defined internally by the DSP chip, used to store the valid scaled value after parsing the floating-point variable. The other channel reads the first 2 bytes (1 word) of data from the physical address, directly using it as a 16-bit value. However, because the 4-byte structure of floating-point data is incompatible with 16-bit integers, this result is usually invalid (only used as a placeholder or for verification). Therefore, valid data for 32-bit floating-point variables must be obtained by reading the fixed array `uwCpuDebugData`; 16-bit integer variables, because they match 16-bit parsing, can directly read valid data through the corresponding channel.
[0032] Assume 8 transmission channels are used to acquire 2 32-bit floating-point variables and 4 16-bit integer variables. Channels 1 and 5 are used to transmit the relevant data of the 32-bit floating-point variable flBattReal. The 4 bytes of data of the physical address of flBattReal (e.g., a floating-point value representing 12.5V) are read completely, scaled to a 16-bit value (12.5 × 1000 = 12500) by a factor of 1000, and stored in a fixed array uwCpuDebugData[0]. uwCpuDebugData[0] is read through channel 1 to obtain the value 12500, and then the real value of flBattReal is restored by "12500 ÷ 1000 = 12.5V".
[0033] Channel 5 reads only the first two bytes of flBattReal's physical address (truncated data, such as 0x3039) as the direct output of channel 5, but because the last two bytes of floating-point mantissa information are lost, this value is invalid (12.5V cannot be restored).
[0034] Channel 2 and Channel 6 transmit the 32-bit floating-point variable fVBattReal. Similar to the steps of parsing the variable flBattReal, the 4 bytes of data (e.g., representing a floating-point value of 3.3V) of the physical address of fVBattReal are read in whole, scaled to a 16-bit value (3.3×1000=3300) by a factor (e.g., 1000), and stored in the fixed array uwCpuDebugData[1]. uwCpuDebugData[1] is read through Channel 2, and the real value of fVBattReal is restored by "3300÷1000=3.3V".
[0035] However, reading only the first two bytes (truncated, invalid) of the physical address of fVBattReal through channel 6 and using them as the direct output of channel 6 is meaningless.
[0036] Channel 3 is used to read the 16-bit integer variable uwInvVoltRms4, channel 4 is used to read the 16-bit integer variable uwInvVoltRms8, channel 7 is used to read the 16-bit integer variable uwGridVoltRmsA, and channel 8 is used to read the 16-bit integer variable uwGridVoltRmsB. The 16-bit integer variables match the parsing method, and 2 bytes of data can be directly read through the corresponding transmission channel (e.g., 2280, corresponding to 228.0V, multiplier 0.1). The outputs of these channels are valid. Channels 3 / 4 / 7 / 8 directly parse the 16-bit data, outputting valid data that the host computer can directly read and display.
[0037] The core purpose of setting up channels 5 and 6 is not to transmit valid data, but to establish an intuitive mapping between raw floating-point variables and fixed array values, improve the readability of the debugging interface, and reserve functional expansion. Specifically, writing fBattReal to channel 5 and fVBattReal to channel 6 is equivalent to clearly marking the mapping relationship between uwCpuDebugData[0] and fBattReal (real-time battery voltage), and uwCpuDebugData[1] and fVBattReal (virtual battery voltage) on the host computer interface. The user's core requirement is to see the specific variable name + corresponding value (such as fBattReal: 12.5V), rather than the array name + value (such as uwCpuDebugData[0]: 12500). After retaining channels 5 and 6, the host computer interface can directly display channel 5: fBattReal (12.5V, from uwCpuDebugData[0]) and channel 6: fVBattReal (3.3V, from uwCpuDebugData[1]). The variable name and value are directly bound, without the need for additional table lookup, which conforms to the user's WYSIWYG debugging habit.
[0038] Based on the data type of the variable to be read for each transmission channel, a resolution factor is assigned to each transmission channel. For example, when a 32-bit floating-point variable needs to be converted to a 16-bit integer for transmission, the resolution factor is set to 1000, and the floating-point value is multiplied by 1000 to avoid overflow. Therefore, if the data type corresponding to the transmission channel is 32-bit floating-point, the resolution factor is set to 1000; if the data type corresponding to the transmission channel is 16-bit integer, the resolution factor is set to 1, or a smaller resolution factor.
[0039] In one implementation scenario, the resolution factor needs to be set according to the possible value range of the floating-point variable to ensure that "floating-point value × factor" falls within the 16-bit integer range (-32768~32767). For example: if the variable's value range is 0~5.0 (such as voltage), the factor is set to 1000 (maximum 5×1000=5000, less than 32767); if the variable's value range is -10~10 (such as current), the factor is set to 3000 (maximum 10×3000=30000, less than 32767). In other implementation scenarios, the resolution factor can be a value less than 1. When the value range of a 32-bit floating-point variable exceeds the upper limit of a 16-bit integer, the data needs to be reduced by a factor less than 1, combined with unit conversion, to ensure that the scaled value falls within the 16-bit range. For example, if the power value to be monitored is 100000W (floating-point), storing it directly as a 16-bit integer will cause an overflow because 100000 > 32767; in this case, if the resolution factor is set to 0.001 (i.e. 1 / 1000), then 100000W × 0.001 = 100, and this value can be stored normally as a 16-bit integer, which corresponds to a physical meaning of 100KW.
[0040] S103: Obtain the physical address corresponding to the variable to be read based on the mapping file.
[0041] In a specific implementation scenario, each variable in the .map file has a unique physical address in the RAM / ROM of the DSP chip (e.g., fIBattReal is at 0x800120). Therefore, the host computer can independently resolve the variable address for each channel through the .map file. The .map file can be loaded as a variable-address dictionary (e.g., {"fIBattReal": "0x800120", "fInvCtrlOut": "0x800124"}) for easier subsequent lookup.
[0042] Because different types of variables have different memory layouts (regular variables are single, independent addresses, arrays are contiguous address blocks, and structures are nested address blocks), the host computer needs to use different indexing rules to ensure accurate address calculations. For example, when the variable to be read is a regular variable, since regular variables have a one-to-one variable-address mapping in the .map file, meaning each variable corresponds to a unique physical address, no additional calculation is needed; the physical address can be obtained directly through variable matching. Specifically, the host computer searches for completely identical entries in the variable fields of the .map file based on the variable to be read (e.g., fIBattReal) (strict case matching is required, e.g., fIBattReal ≠ FIBattReal; spelling errors will cause matching failures). After finding a matching entry, the physical address field of that entry (e.g., 0x800120) is directly read to complete the indexing.
[0043] If the variable type is an array variable, the array is a block of addresses stored in memory. The .map file only records the starting address (the address of the first element) of the array variable. The address of a certain element in the array needs to be calculated by the starting address + offset. The offset = element index × number of bytes of a single element (the element index starts from 0). Specifically, the array variable (fInvCtrlOut) is extracted from the variable to be read (e.g., fInvCtrlOut[1]). The array name is searched in the .map file to obtain the starting address (e.g., 0x800124) and the total number of bytes occupied by the array variable (e.g., 0x28 = 40 bytes, corresponding to 10 4-byte float elements). Extract the index from the variable to be read (e.g., the index of fInvCtrlOut[1] is 1); infer the number of bytes of a single element by the total number of bytes occupied by the array and the number of elements (e.g., the total number of bytes 40 ÷ 10 elements = 4 bytes / element, i.e., float type), offset = element index × number of bytes of a single element (e.g., 1 × 4 = 4 bytes); target element address (physical address of the variable to be read) = array start address + offset (e.g., 0x800124 + 4 = 0x800128).
[0044] If the variable type is a structure variable, the structure variable is a nested contiguous block of addresses in memory. The .map file only records the base address of the structure variable (the address of the first member of the structure). The address of a member within the structure needs to be calculated by adding the base address to the member offset. The offset is the byte distance of the member relative to the structure's base address. Extract the structure name (stBatt) from the variable to be read (e.g., stBatt+42), search for the structure variable in the .map file, obtain the base address (e.g., 0x80014C) and the total number of bytes occupied by the structure (e.g., 0x2A=42 bytes), and extract the offset of 42 bytes from the variable to be read (stBatt+42). Alternatively, if the variable to be read is stBatt.voltage, find the offset (e.g., 42 bytes) of the voltage member under the stBatt structure from the structure member offset table. Member address (physical address of the variable to be read) = structure base address + member offset (e.g., 0x80014C+42=0x800176).
[0045] S104: Combine the physical address and resolution rate of each transmission channel into a data packet according to a preset communication protocol, and send the data packet to the chip under test so that the chip under test can perform parsing operations based on the data packet.
[0046] In a specific implementation scenario, a pre-defined communication protocol is used for subsequent data interaction between the host computer and the chip under test. The communication protocol can be SCI. The physical address and resolution multiplier of each transmission channel obtained in the preceding steps are packaged into data packets according to the frame format supported by the SCI protocol before transmission. For example, the data packet format includes: Frame header (0xAA): a fixed start identifier that tells the DSP chip that valid data begins here, avoiding the reception of random noise; Address field (8×4 bytes): 32-bit physical addresses for 8 channels (e.g., 0x800120 split into bytes for transmission: 0x20, 0x01, 0x80, 0x00; endianness must be ensured to match the DSP's byte order); Multiplier field (8×2 bytes): 16-bit resolution multipliers for 8 channels (e.g., multiplier 1000 corresponds to hexadecimal 0x03E8); Check bit: used to verify data integrity; Frame tail (0x55): a fixed end identifier that tells the DSP chip that the data packet ends here.
[0047] In one implementation scenario, the DSP chip extracts the physical address and parsing ratio corresponding to each transmission channel from the data packet according to the SCI frame structure. The parsed physical address and parsing ratio are stored in a preset buffer for later direct retrieval. A data type identifier can be added to the data packet, allowing the DSP chip to obtain the data type (16-bit integer or 32-bit floating-point) corresponding to each transmission channel from the data type identifier.
[0048] If a channel corresponds to a 16-bit integer data type, the DSP chip reads 2 bytes (16 bits) of data from memory based on the physical address corresponding to that transmission channel (e.g., 0x800100), and concatenates these 2 bytes to obtain the real-time value of the variable. For example, if address 0x800100 stores bytes 0x00 and 0x64, concatenating them results in 0x0064, corresponding to decimal 100. The value range of the 16-bit integer variable (-32768~32767 or 0~65535) is consistent with the range of 16-bit data in subsequent transmission formats, and the read 16-bit value can be directly stored in a preset data output buffer for uploading.
[0049] If a channel corresponds to a 32-bit floating-point data type, the DSP chip reads 4 bytes (32 bits) of data from memory based on the physical address corresponding to that transmission channel (e.g., 0x800120), and converts it to a floating-point value according to the IEEE 754 standard. For example, 4 bytes 0x41400000 corresponds to the floating-point value 10.0. The value range of a 32-bit floating-point type is approximately ±3.4 × 10⁻⁶. 38 The range of 32-bit floating-point numbers is much larger than that of 16-bit integers, and direct transmission will cause overflow (e.g., the floating-point value 100000.0 cannot be represented by 16 bits). Therefore, it is necessary to scale the data using the parsing factor in the data packet. The scaled value = original floating-point value × parsing factor (round the result to ensure it is within the range of -32768 to 32767). The scaled 16-bit integer value is stored in a fixed array. For example, the floating-point value 2.345 × factor 1000 = 2345 is stored in the fixed array [i] = 2345. 32-bit floating-point numbers are converted to 16-bit for transmission by scaling, reducing the data volume by half (4 floating-point variables only require 8 bytes instead of 16 bytes), reducing the pressure on SCI communication, and making it suitable for high-frequency reading (such as high-speed oscilloscope functions).
[0050] In other implementation scenarios, if the scaled value exceeds the range (e.g., 100.0 × 1000 = 100000 > 32767), the DSP chip needs to truncate it to the maximum value (e.g., 32767) and mark it as "overflow" when displayed on the host computer to avoid erroneous data misleading debugging.
[0051] In this embodiment, a fixed channel division scheme allows n of the multiple transmission channels to be used for transmitting 16-bit integer variables to be read, while the remaining m transmission channels are used for transmitting 32-bit floating-point variables to be read, where m is an even number. This supports simultaneous monitoring of variables of both data types, meeting the needs of complex debugging scenarios (such as simultaneously monitoring current (floating-point) and error codes (integer)). Type identification or channel division ensures that different types of variables are correctly parsed, and scaling allows a wide range of floating-point values to be adapted to the 16-bit transmission channels, preventing overflow.
[0052] S105: Send a read command to the chip under test to obtain the real-time value of each variable to be read provided by the chip under test.
[0053] In a specific implementation scenario, the host computer sends a read command to the chip to be debugged. After receiving the read command, the DSP chip transmits the real-time value of each variable to be read to the host computer through the corresponding transmission channel.
[0054] If the data type of the variable to be read is a 16-bit integer, no special processing is required. The real-time value of the variable is directly obtained through the transmission channel bound to the variable and displayed directly. For example, if the variable to be read in channel 3 is var_count, and 2 bytes of data are read, they are directly concatenated into a 16-bit integer (int16_t). Reading 0x00 (low byte) and 0x64 (high byte), the concatenation is 0x0064 = 100. Since the real-time value of the variable in channel 3 is 100, the display will show var_count: 100.
[0055] If the data type of the variable to be read is 32-bit floating-point, obtain the two transmission channels corresponding to the variable to be read, assuming they are channels A and B. Channel A is used to transmit the data of the fixed array (the 16-bit mapped value of the floating-point variable after scaling, i.e., the real-time value of the variable), and channel B is used to transmit the first 2 bytes of the floating-point variable, i.e., half of the original 32-bit value, but this value is usually not used in actual display (only as a verification basis), because channel A has already transmitted valid information from the fixed array. The fixed array is specifically used to store the 16-bit value of the floating-point variable after scaling. For example, the original value of f_voltage is 3.3V, the scaling factor is 1000, and the scaled value of 3300 will be stored in float_map[0]. Channel 1 and channel 5 both correspond to the variable to be read f_voltage. The real-time value of the variable in channel 1 is 3300, and the data transmitted in channel 5 is invalid. In this embodiment, the closed loop of type judgment → channel binding → scaling mapping → restoration display not only solves the problem that 32-bit floating-point variables are difficult to transmit directly through 16-bit channels, but also ensures the traceability of data through the correspondence between the preceding and following channels, thus achieving efficient and accurate monitoring of variables of different types.
[0056] As described above, this embodiment directly uses the variable to be read for debugging, obtains the physical address corresponding to the variable based on the mapping file, avoids tedious physical address lookup and memorization, significantly shortens debugging preparation time, and avoids modification of the DSP chip's running code; selects a transmission channel based on available memory and binds its relationship with the variable to be read, and sends configuration information such as address and multiplier and reading instructions only through a preset communication protocol, without interfering with the execution of the chip's core business logic. The DSP chip obtains the real-time value of the variable by directly reading the physical address, without pausing or restarting the chip's running business process, realizing parallel debugging operations and business execution, thereby ensuring business continuity.
[0057] Please refer to the following: Figure 3 , Figure 3 This is a flowchart illustrating another embodiment of the debugging method for a digital signal processing chip provided by the present invention. The debugging method for a digital signal processing chip provided by the present invention specifically includes the following steps: S201: Obtain the mapping file of the chip to be debugged, obtain the variables to be read, and select the number of transmission channels based on the available memory of the chip to be debugged.
[0058] S202: Bind the correspondence between the variables to be read and the transmission channels, and configure the parsing rate of each transmission channel based on the correspondence; S203: Obtain the physical address corresponding to the variable to be read based on the mapping file; S204: Combine the physical address and resolution rate of each transmission channel into a data packet according to a preset communication protocol, and send the data packet to the chip under test so that the chip under test can perform parsing operations based on the data packet; S205: Send a read command to the chip under test. The read command includes the target variable and obtains the real-time value of each variable to be read provided by the chip under test.
[0059] In a specific implementation scenario, steps S201-S205 are basically the same as steps S101-S105 of an embodiment of the debugging method for digital signal processing chips provided by the present invention, and will not be described again here.
[0060] S206: Obtain the real-time values of multiple variables for the same variable to be read; plot the variable value change curve corresponding to each variable to be read based on the real-time values of multiple variables.
[0061] In a specific implementation scenario, multiple real-time values of the same variable to be read are obtained; based on the multiple real-time values, a variable value change curve corresponding to each variable to be read is plotted, transforming discrete real-time monitoring data into a continuous visual trend.
[0062] The host computer automatically sends read commands at preset intervals (e.g., 10ms / 100ms, selected according to the frequency of variable changes), triggering the chip under test (DSP chip) to upload the real-time values of all variables to be read through the corresponding transmission channel according to the pre-bound correspondence between the variables to be read and the transmission channel.
[0063] Each time the host computer receives the real-time variable values returned by the DSP chip through each transmission channel, it immediately records the current system timestamp (accurate to the millisecond level) and stores it in the format of timestamp + channel value + real-time variable value. For example, it can be recorded as t=1620000000100ms, channel 1=100, channel 2=3300, ..., channel 8=2500. Similarly, for the real-time values of floating-point variables, they need to be restored to their original values according to the resolution factor (e.g., the 16-bit value of channel 1, 3300 ÷ resolution factor 1000 = 3.3V) to ensure that the data has actual physical meaning.
[0064] Data from each transmission channel, based on time-series storage, is mapped using coordinates and dynamically refreshed to transform the trend of each variable into a curve. The X-axis is the time axis, with the first data acquisition timestamp as the origin (t=0). Subsequent times are calculated as the relative time by subtracting the origin timestamp from the current timestamp (e.g., t=10ms, 20ms, etc.). The axis length is configurable (e.g., displaying data from the last 10 seconds, with the X-axis range from 0 to 10000ms) to ensure uniform time scale. The Y-axis is the numerical axis, with an independently calculated range for each variable. Boundaries can be set with a historical maximum value + 10% margin and a historical minimum value -10% margin (e.g., for a variable voltage with a historical range of 0 to 5V, the Y-axis is set to -0.5 to 5.5V) to prevent data from exceeding the display range.
[0065] You can set a curve for each variable to be read, distinguished by color and / or line type. For example, channel 1 (current) is a solid red line and channel 5 (voltage) is a dashed blue line. The variable name and physical unit (such as "current (A)" and "voltage (V)") can be labeled in the legend.
[0066] For slowly changing variables (such as temperature), the curve can intuitively show its gradual change over time, such as linear increase or periodic fluctuation. For rapidly changing variables (such as motor starting current), the curve can capture transient responses, such as peak values and decay rates. When multiple variable curves are displayed simultaneously, the correlation between variables can be intuitively analyzed (such as whether the voltage drops synchronously when the current suddenly increases), providing a global perspective of the "dynamic process" for debugging and significantly improving the efficiency of problem localization.
[0067] Furthermore, users can set acquisition trigger parameters on the host computer interface. These parameters include at least one of the following: trigger source, trigger type, trigger threshold, trigger location, total number of points, and interval number of points. This specifies which signal to monitor, under what conditions to trigger, how much data to store after triggering, and how to display the data.
[0068] Specifically, the trigger source is the transmission channel corresponding to the variable to be monitored selected by the user, clarifying which variable the DSP chip needs to monitor. For example, motor current corresponds to channel 3. The trigger type is the specific trigger condition, including greater than (>), less than (<), equal to (=), greater than or equal to (≥), and less than or equal to (≤), defining when to trigger. For example, triggering occurs when the motor current in channel 3 exceeds 10A. The trigger threshold is a value matching the trigger type, such as 10A or 3.3V. It needs to be entered according to the variable type; 16-bit integers are entered directly, and 32-bit floating-point values require the original value. It is the critical value of the trigger condition; for example, 10A is the criterion for judging excessive current.
[0069] The trigger position refers to the location of the trigger point in the final displayed data. This includes centering (trigger point in the middle of the data segment), beginning (trigger point at the start of the data segment), and end (trigger point at the end of the data segment). It determines the amount of data stored before and after the trigger. For example, centering requires storing 50% of the data before the trigger plus 50% after the trigger. The total number of points is the total number of data points to be stored after the trigger, such as 1000 or 2000 points. It must be an even number to facilitate centering and is used to control the length of the data segment (e.g., 1000 points, collected at 10ms intervals, can display a 10s waveform). The interval number is the time interval between two adjacent data points, such as 1ms or 10ms. It needs to match the frequency of the variable change; high-frequency variables use smaller intervals to ensure the time resolution of the data. For example, monitoring current fluctuations at 1kHz requires an interval ≤1ms to avoid waveform distortion.
[0070] The host computer needs to package the trigger parameters into a trigger configuration frame and send it to the DSP chip via SCI. Upon receiving the trigger configuration frame, the DSP chip needs to associate the physical address, resolution multiplier, and data type of the trigger source channel to ensure data type matching during threshold comparison. If the trigger source corresponds to a 32-bit floating-point type, the threshold divided by the resolution multiplier needs to be converted back to a floating-point value before comparison. The DSP chip allocates a trigger data buffer to store continuous data before and after the trigger. The data buffer uses a circular queue design, continuously writing the latest data (collected periodically at intervals). When full, it overwrites the oldest data, ensuring that the most recent N points of data (N = total number of points) are always stored, waiting for the trigger condition to be met.
[0071] The size of the data buffer is determined by the total number of points and the number of channels. For example, if the total number of points is 1000 and the 8-channel mode is used, the buffer size is 1000 points × 8 channels × 2 bytes (16-bit value) = 16000 bytes (16KB), which is usually stored in on-chip RAM (fast speed, suitable for high-frequency writing).
[0072] The DSP chip configures timers at intervals (e.g., triggering once every 10ms). For each trigger source channel, the current value is extracted and compared with the trigger threshold. The trigger type is then used to determine if the trigger condition is met. Specifically, if the trigger source is a 16-bit integer channel, the original value `current_val` is directly compared with the threshold (e.g., `current_val > threshold`). If the trigger source is a 32-bit floating-point channel, the current value (floating-point value) is compared with the threshold divided by a factor (e.g., `(current_val) > (threshold / 1000)`). If the current value meets the trigger condition corresponding to the acquired trigger parameters, then the current value is used as the trigger point.
[0073] After the trigger point is captured, the DSP chip needs to decide whether to continue storing data based on the trigger position to ensure that the trigger point's position in the data segment matches the configuration. Taking a total of 1000 points as an example: When the trigger position is at the beginning, the trigger point is point 1. 999 more points need to be collected and stored, stopping once the buffer is full. The trigger point is fixed at the beginning of the data segment (X=0 position). When the trigger position is in the middle, the trigger point is point 500. 500 more points need to be stored. At the time of triggering, the data buffer already contains the previous 499 points plus the trigger point. 500 more points are collected, stopping once 1000 points are full. The trigger point is located in the middle (X=500 position). When the trigger position is at the end, the trigger point is point 1000. 999 points have already been stored. At the time of triggering, the data buffer already contains 999 points. The trigger point is stored as point 1000, and the process stops immediately. The trigger point is fixed at the end of the data segment (X=999 position).
[0074] After the data segment is stored, the DSP chip sets and sends a trigger completion flag to the host computer and stops the timer interrupt to prevent further data writing from corrupting the locked buffer. Upon receiving the trigger completion flag, the host computer sends a read command to the DSP chip. In response, the DSP chip packages the real-time values of multiple variables corresponding to each physical address into a corresponding variable value array and sends it to the host computer. After receiving the variable value array, the host computer plots the waveforms for each corresponding transmission channel based on the array. The waveform plotting method is basically the same as described above and will not be repeated here.
[0075] Using this method, for occasional events (such as randomly occurring overcurrent faults), there is no need to manually monitor the waveform and wait; the triggering function can automatically capture them. For transient events (such as voltage spikes within 10ms), the cause and effect of the event can be completely reconstructed by using data before and after the trigger (such as current changes before the spike and protection actions after the spike). The trigger position configuration ensures that key information is not truncated (such as center triggering, which allows simultaneous viewing of the cause before the trigger and the result after the trigger).
[0076] As described above, this embodiment supports continuous acquisition of real-time variable values at fixed intervals, ensuring complete capture of the variable's regular trends and temporal characteristics. It also allows for precise capture of variable dynamics under specific conditions (such as outliers and transient events) by configuring trigger sources and thresholds, avoiding redundant and invalid data, thus balancing the comprehensiveness and specificity of data acquisition. This flexible acquisition mechanism can adapt to the characteristics of different variables (such as the speed of change or whether conditional triggering is required), ensuring that the acquired data not only fully reflects the dynamic patterns of the variables but also focuses on key information. This provides a high-quality, highly relevant data source for subsequent curve plotting and debugging analysis, effectively improving debugging efficiency and accuracy.
[0077] This invention provides a computer device. The computer device includes a processor and a memory. The processor is coupled to the memory. The memory stores a computer program, which the processor executes during operation to implement the method described above. Detailed steps are described above and will not be repeated here.
[0078] This invention provides a computer-readable storage medium. The computer-readable storage medium stores at least one computer program, which is executed by a processor to implement the method described above. Detailed steps are described above and will not be repeated here. In one embodiment, the computer-readable storage medium may be a storage chip in a terminal, a hard disk, or other readable and writable storage tools such as a portable hard disk, USB flash drive, or optical disc, or it may be a server, etc.
[0079] Those skilled in the art will understand that implementing all or part of the processes in the above embodiments can be accomplished by a computer program instructing related hardware. The program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM), etc.
[0080] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.
[0081] It should be understood that the above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit them. Those skilled in the art can modify the technical solutions described in the above embodiments, or make equivalent substitutions for some of the technical features; and all such modifications and substitutions should fall within the protection scope of the appended claims of the present invention.
Claims
1. A debugging method for a digital signal processing chip, characterized in that, include: Obtain the mapping file of the chip to be debugged, obtain the variables to be read, and select the number of transmission channels based on the available memory of the chip to be debugged; Bind the correspondence between the variable to be read and the transmission channel, and configure the parsing ratio of each transmission channel based on the correspondence; Obtain the physical address corresponding to the variable to be read based on the mapping file; The physical address and resolution ratio of each transmission channel are combined into a data packet according to a preset communication protocol, and the data packet is sent to the chip under test so that the chip under test can perform a parsing operation based on the data packet; A read instruction is sent to the chip under test, the read instruction including a target variable, and the real-time value of the variable corresponding to each variable to be read provided by the chip under test is obtained.
2. The debugging method for a digital signal processing chip according to claim 1, characterized in that, The step of retrieving the real-time value of the variable corresponding to each physical address provided by the chip to be debugged includes: Obtain multiple real-time values of the same variable to be read; plot the variable value change curve corresponding to each variable to be read based on the multiple real-time values.
3. The debugging method for a digital signal processing chip according to claim 2, characterized in that, The step of obtaining the real-time values of the multiple variables includes: The read command is sent to the chip under test according to a preset acquisition cycle to obtain the real-time values of multiple variables; or For each variable to be read, a collection trigger parameter is set, and the collection trigger parameter is sent to the chip to be debugged, so that the chip to be debugged can collect multiple real-time values of the variables corresponding to the physical address according to the collection trigger parameter, and form a variable value array. Get the array of variable values; The acquisition triggering parameters include at least one of the following: trigger source, trigger type, trigger threshold, trigger location, total number of points, and interval number of points.
4. The debugging method for a digital signal processing chip according to claim 3, characterized in that, The trigger position includes any one of the beginning, middle, and end positions; The step of enabling the chip under test to acquire multiple real-time values of the variables corresponding to the physical address according to the acquisition trigger parameters includes: A data buffer is preset in the chip to be debugged, so that the chip to be debugged can continuously collect data based on the interval points and store the real-time value of the variable in the data buffer; And so that when the chip under test detects that the latest real-time value of the variable meets the trigger type and trigger position, the latest real-time value of the variable is used as the trigger point; Based on the trigger point and the trigger position, a certain number of real-time variable values are obtained from the data buffer and / or several more real-time variable values are collected.
5. The debugging method for a digital signal processing chip according to claim 1, characterized in that, The step of obtaining the physical address corresponding to the variable to be read based on the mapping file includes: Obtain the variable type of the variable to be read; If the variable type is a regular variable, the physical address is obtained directly from the mapping file based on the variable to be read; If the variable type is an array variable, then obtain the starting address and total number of bytes corresponding to the variable to be read from the mapping file, obtain the byte offset based on the total number of bytes, and obtain the physical address based on the starting address and the byte offset; If the variable type is a structure variable, then obtain the base address corresponding to the variable to be read from the mapping file, obtain the member offset, and obtain the physical address based on the base address and the member offset.
6. The debugging method for a digital signal processing chip according to claim 1, characterized in that, The step of binding the correspondence between the variable to be read and the transmission channel includes: Obtain the data type corresponding to the variable to be read, wherein the data type includes 16-bit integer and / or 32-bit floating-point; If the data type is a 16-bit integer, then one of the transmission channels is selected and bound to the variable to be read. If the data type is a 32-bit floating-point number, then two of the transmission channels are selected and bound to the variable to be read.
7. The debugging method for a digital signal processing chip according to claim 6, characterized in that, The step of enabling the chip under test to perform parsing operations based on the data packet includes: If the data type is a 16-bit integer, then 2 bytes of data are read according to the physical address corresponding to each variable to be read, and the 2 bytes of data are concatenated to obtain the real-time value of the variable; If the data type is 32-bit floating-point, then 4 bytes of data are obtained according to the physical address corresponding to each variable to be read, and the 4 bytes of data are converted into floating-point values. The floating-point values are compressed according to the parsing ratio to obtain the real-time value of the variable, and the real-time value of the variable is stored in a fixed array.
8. The debugging method for a digital signal processing chip according to claim 7, characterized in that, The step of obtaining the real-time value of the variable corresponding to each physical address provided by the chip to be debugged includes: If the data type of the variable to be read is a 16-bit integer, then the real-time value of the variable is obtained directly through the corresponding transmission channel; If the data type corresponding to the variable to be read is 32-bit floating point, then the real-time value of the variable is obtained from the fixed array through one of the transmission channels corresponding to the variable to be read, and the first 2 bytes of the 4-byte data are obtained through the other transmission channel; the real-time value of the variable is restored to the restored value based on the parsing ratio.
9. A computer-readable storage medium, characterized in that, The device stores a computer program that, when executed by a processor, causes the processor to perform the steps of the method as described in any one of claims 1 to 8.
10. A computer device, characterized in that, It includes a memory and a processor, the memory storing a computer program that, when executed by the processor, causes the processor to perform the steps of the method as described in any one of claims 1 to 8.