Commissioning data processing method, optical module and storage medium

Abstract

The embodiment of the application provides a kind of commissioning data processing method, optical module and storage medium, including but not limited to optical communication technical field;The method comprises that MCU is detected to satisfy the commissioning starting condition of pre-set, at least part continuous physical space in SRAM is divided, obtains first buffer page group and second buffer page group, and after receiving DSP write request from DSP, first target buffer page group is determined from first buffer page group and second buffer page, and DSP commissioning data in DSP write request is written in first target buffer page group;And from second target buffer page group, cached DSP commissioning data is read and sent to external terminal equipment;Second target buffer page group and first target buffer page group are different at the same time;The data operation attribute of each Page page in the same second target buffer page group is same, to be able to give consideration to test efficiency and production cost under the scene of optical module batch application.

Description

Technical Field

[0001] This application relates to the field of optical communication technology, and in particular to a data processing method for adjustment, an optical module, and a storage medium. Background Technology

[0002] Digital Signal Processors (DSPs) are core components of optical modules in fiber optic communication systems. They perform PAM4 signal modulation and demodulation, adaptive equalization, forward error correction (FEC), and clock recovery to ensure the stability of the optical module's performance and functions. Therefore, to ensure the performance and functional stability of the optical module, the testing and maintenance of the DSP inevitably involves its commissioning and maintenance. However, in practical applications, the commissioning and maintenance of DSP-integrated optical modules typically employs several methods: first, a Microcontroller Unit (MCU) smart gateway solution; second, a dedicated debugging interface solution; and third, a customized solution from the DSP manufacturer. However, none of these methods can simultaneously balance testing efficiency and production costs in scenarios involving mass production of optical modules. Summary of the Invention

[0003] The main objective of this application is to propose a testing data processing method, an optical module, and a storage medium that can balance testing efficiency and production costs in scenarios where optical modules are used in large quantities.

[0004] To achieve the above objectives, a first aspect of this application proposes a debugging data processing method applied to a microcontroller (MCU), wherein the MCU is used to install in an optical module; the method includes: In response to the detection that the preset debugging start conditions are met, at least a portion of the continuous physical space in the static random access memory (SRAM) is divided to obtain a first buffer page group and a second buffer page group. In response to receiving a DSP write request from a digital signal processor (DSP), a first target buffer page group is determined from the first buffer page group and the second buffer page group, and the DSP debugging data in the DSP write request is written into the first target buffer page group; Read the cached DSP debugging data from the second target buffer page group and send it to the external terminal device; the second target buffer page group is one of the first buffer page group and the second buffer page group. At any given time, the second target buffer page group and the first target buffer page group are different; the data operation attributes of each page in the same second target buffer page group are the same, and the data operation attributes of each page in the same first target buffer page group are the same.

[0005] To achieve the above objectives, a second aspect of this application proposes a tuning data processing method applied to a digital signal processor (DSP), wherein the DSP is used to install in an optical module; the method includes: According to the test request, DSP debugging data is obtained and encapsulated into DSP data packets according to a preset protocol format; the test request is a request forwarded by the microcontroller MCU connected to the DSP and originates from an external terminal device. According to the DSP data packet, a DSP write request is initiated to the MCU, so that when the MCU receives the DSP write request, it determines the first target buffer page group from the first buffer page group and the second buffer page group, and writes the DSP debugging data in the DSP write request into the first target buffer page group; The first buffer page group and the second buffer page group are obtained by dividing at least a portion of the continuous physical space in the static random access memory (SRAM) when the MCU detects that the preset debugging start conditions are met. The second target buffer page group, excluding the first target buffer page group, is used to provide cached DSP debugging data to external terminal devices. At the same time, the second target buffer page group and the first target buffer page group are different. The data operation attributes of each page in the same second target buffer page group are the same, and the data operation attributes of each page in the same first target buffer page group are the same.

[0006] To achieve the above objectives, a third aspect of this application provides an optical module, comprising: A microcontroller processor (MCU), wherein the MCU is provided with a second serial communication bus interface and a first serial communication bus interface; A digital signal processor (DSP), wherein the DSP is connected to the MCU via the first serial communication bus interface; The MCU executes the debugging data processing method as described in any one of the first aspects; The DSP performs the debugging data processing method as described in any of the second aspects.

[0007] To achieve the above objectives, a fourth aspect of the present application provides a computer-readable storage medium storing computer-executable instructions, which are configured to be executed by a processor as described in any one of the first and / or second aspects of the debugging data processing method.

[0008] The proposed debugging data processing method, optical module, and storage medium divide the continuous physical space of the SRAM in the MCU into a first buffer page group and a second buffer page group, each consisting of at least one page. When the MCU receives a DSP write request, it directly writes the corresponding DSP test data to the first target buffer page group. Simultaneously, it reads data from the second target buffer page group and sends it to an external terminal device. Since the first and second target buffer page groups are different at any given time, the external terminal device and the DSP can simultaneously perform read and write operations on different buffer page groups, decoupling the operations between the MCU and the external terminal device / DSP. This ensures that the DSP test data is transmitted to the MCU with higher transmission efficiency. Furthermore, because both the first and second buffer page groups consist of at least one page, both reading and writing data are performed in page-by-page units, limiting the maximum amount of SRAM occupied in a single operation, reducing the risk of overflow, and ensuring the integrity of the DSP debugging data transmitted securely from the MCU to the external terminal device. Compared with related technologies, the embodiments of this application do not require the MCU to parse data from the DSP, nor do they require customization of the optical module or DSP, resulting in lower production costs. Furthermore, since the DSP debugging and data transmission efficiency of a single optical module is higher and the debugging process is independent of the MCU, the testing efficiency in batch application scenarios of optical modules can be improved. Attached Figure Description

[0009] Figure 1 This is a flowchart illustrating an embodiment of the debugging data processing method provided in this application applied to the MCU side; Figure 2 This is a flowchart illustrating an embodiment of the debugging data processing method provided in this application applied to the DSP side; Figure 3 This is a schematic diagram of the application flow of an embodiment of the commissioning data processing method provided in this application; Figure 4 This is a schematic diagram of the module structure of the optical module corresponding to the commissioning data processing method provided in this application; Figure 5 This is a schematic diagram of the structure of a commissioning system for which the commissioning data processing method provided in this application is applied; Figure 6 This is a schematic diagram of the debugging process in an embodiment of the debugging data processing method provided in this application. Detailed Implementation

[0010] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0011] It should be noted that although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, and the aforementioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0012] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0013] Digital Signal Processors (DSPs), as core components of optical modules in fiber optic communication systems, perform PAM4 signal modulation and demodulation, adaptive equalization, forward error correction (FEC), and clock recovery to ensure the stability of the optical module's performance and functions. However, in practical applications, although DSP chips are delivered with complete debugging interfaces and toolchains for chip verification, performance optimization, and fault diagnosis, these debugging capabilities are shielded by the physical packaging and internal architecture of the optical module after integration. This prevents DSP vendors' debugging tools from penetrating the optical module to access the DSP's internal components, necessitating the provision of new debugging strategies for the DSP within the optical module. While various solutions have been proposed for DSP debugging and maintenance of optical modules with integrated DSPs, none are adequate for the debugging requirements of mass-produced optical modules. The first approach involves an MCU smart gateway solution. This solution relies on the MCU to parse the DSP's proprietary protocol and convert the parsed debugging data into a standard format before providing it to the host. DSP debugging depends on the MCU's firmware; therefore, upgrading the DSP debugging protocol requires simultaneous firmware updates to the MCU, resulting in time-consuming debugging and relatively high maintenance costs. Furthermore, the first solution suffers from compatibility issues between the MCU's parsing and the DSP's debugging protocol, increasing debugging difficulty and reducing testing efficiency. The second approach uses a dedicated debugging interface, setting up independent test interfaces (such as JTAG, SWD, or UART) on the optical module. Terminal devices directly debug and maintain the DSP through this interface. However, this second approach is only suitable for the R&D phase, cannot be used for deployed optical modules, and cannot achieve mass production, thus failing to adapt to the testing of batch optical modules. The third approach is a customized solution from the DSP manufacturer. This solution embeds debugging capabilities into the customized DSP for debugging and maintenance. However, because this third approach requires customization, the hardware development cost of a single DSP increases, leading to high costs in batch optical module applications. Meanwhile, as speeds evolve from 100G to 400G, 800G, and even 1.6T, the DSPs integrated within optical modules become increasingly complex. The aforementioned methods all require the optical modules themselves to adjust accordingly to match the DSPs, further increasing the impact on cost and efficiency. Therefore, none of these methods can balance testing efficiency and production costs in scenarios involving mass application of optical modules. Based on this, embodiments of this application provide a testing data processing method, an optical module, and a storage medium that can balance testing efficiency and production costs in scenarios involving mass application of optical modules.

[0014] Understandably, referring to Figure 1As shown, a test data processing method according to an embodiment of this application is applied to a microcontroller (MCU), which is installed in an optical module; the method includes: Step S110: In response to detecting that the preset debugging start conditions are met, at least a portion of the continuous physical space in the static random access memory (SRAM) is divided to obtain a first buffer page group and a second buffer page group. Step S120: In response to receiving a DSP write request from a digital signal processor (DSP), determine the first target buffer page group from the first buffer page group and the second buffer page group, and write the DSP debugging data in the DSP write request into the first target buffer page group. Step S130: Read the cached DSP debugging data from the second target buffer page group and send it to the external terminal device; the second target buffer page group is one of the first buffer page group and the second buffer page group; At the same time, the second target buffer page group and the first target buffer page group are different; the data operation attributes of each page in the same second target buffer page group are the same, and the data operation attributes of each page in the same first target buffer page group are the same.

[0015] By dividing the contiguous physical space of the SRAM in the MCU into a first buffer page group and a second buffer page group, each of the first and second buffer page groups consists of at least one page. When the MCU receives a DSP write request, the DSP test data corresponding to the DSP write request is directly written to the first target buffer page group. Correspondingly, data is directly read from the second target buffer page group and sent to the external terminal device. At this time, since the first and second target buffer page groups are different at the same time, that is, at the same time, the external terminal device and the DSP can simultaneously perform read and write operations on different buffer page groups, thereby decoupling the operations between the MCU and the external terminal device and the DSP, ensuring that the DSP test data is transmitted to the MCU with higher transmission efficiency. At the same time, since the first and second buffer page groups consist of at least one page, both reading and writing data are performed in units of pages, which can limit the maximum amount of data occupied in SRAM at one time, reduce the risk of overflow, and thus ensure the integrity of the DSP debugging data being safely transmitted from the MCU to the external terminal device. This application embodiment does not require the MCU to parse data from the DSP, nor does it require customization of the optical module or DSP, resulting in lower production costs. Furthermore, since the DSP debugging and data transmission efficiency of a single optical module is higher and the debugging process is independent of the MCU, the testing efficiency in batch application scenarios of optical modules can be improved.

[0016] SRAM is a memory integrated within the MCU and can be a single-port SRAM. For optical modules, the SRAM capacity within the MCU is typically only a few KB to tens of KB, with a low clock frequency. When caching large amounts of data, it is more prone to memory overflow. Therefore, for devices like MCUs with limited storage resources, using pages as the unit can reduce memory overflow. Furthermore, when the MCU is used in an optical module, it also undertakes various real-time tasks. Using pages in this embodiment can also reduce the impact on real-time tasks such as temperature control and alarms that might be blocked by the MCU, thereby reducing the probability of the optical module "crashing" and ensuring that DSP test data can be written to the MCU at high speed and stably.

[0017] The DSP side generates data at a fast rate (due to its wide internal bus), while the external terminal device (i.e., the host side) typically reads data at a slower rate (400kHz / 1MHz). Therefore, the rate at which the DSP writes data to the MCU is higher than the rate at which the external terminal device reads data from the MCU. This embodiment of the application, through the first and second buffer page groups, enables even low-performance MCUs to handle high-speed debug data streams without requiring hardware expansion.

[0018] This application does not limit the method by which the DSP and external terminal devices connect to the MCU. In some embodiments, the DSP connects to the MCU through a first serial communication bus interface, which may be I2C or SPI, etc. In some embodiments, the external terminal device connects to the MCU through a second serial communication bus interface. The types of the first and second serial communication bus interfaces may be the same or different, which will not be elaborated in detail in this application.

[0019] This application does not impose restrictions on the debugging start conditions. For example, the debugging start conditions may be that the DSP debugging is enabled (i.e., the DSP is in debugging mode), or the DSP supports debugging and is in working state. This application will not elaborate on these conditions one by one. Those skilled in the art can selectively set them according to the actual situation.

[0020] This application does not limit the size of each page contained in the first and second buffer page groups; in practical applications, this size can be selectively set according to the available SRAM space. The number of pages contained in each of the first and second buffer page groups is also not limited. In some embodiments, each page has the same storage capacity. At least two pages are partitioned from at least partially contiguous physical space within the SRAM.

[0021] Both the first and second buffer page groups correspond to contiguous storage space. This application embodiment does not limit the number of pages contained in each of the first and second buffer page groups, only ensuring that the difference between the longest operation time for reading by the terminal device and writing by the DSP does not exceed a preset performance threshold. In some embodiments, the number of pages contained in each of the first and second buffer page groups is the same. In some embodiments, the number of pages contained in each of the first and second buffer page groups may also be different, but the difference in the number of pages contained in the two buffer page groups is within a preset difference threshold. This ensures that when the host side reads a buffer page group with a larger number of pages through the second serial communication bus interface, the performance requirements will not be unmet due to excessively long reading times for all data in that buffer page group. For example, if the difference threshold is 1, it means that a difference in the number of buffer pages greater than 1 will result in a longer average time for the terminal side to obtain test data from the DSP, and the test efficiency will not meet the performance requirements. Therefore, if the first buffer page group contains 3 pages, the number of pages contained in the second buffer page group will range from 2 to 4. This application embodiment will not elaborate further on this.

[0022] This application embodiment does not limit what the test request is. It can be a request for the DSP to periodically upload test result data, or a test request to query specific diagnostic information in real time. This application embodiment will not elaborate on these specific requests. Enabling write caching means that data packets from the first serial communication bus interface are directly cached and written starting from the first target page.

[0023] The first target buffer page group and the second target buffer page group are logical buffer page groups, and the first buffer page group and the second buffer page group are physical buffer page groups. The first target buffer page group indicates that the data operation attribute of the corresponding buffer page group is write attribute, so as to cache the data written by the DSP. The second target buffer page group indicates that the data operation attribute of the corresponding buffer page group is read attribute, so as to provide the cached DSP debugging data to the external terminal device.

[0024] The first target page refers to the page in the first target buffer page group that has not yet been written with data.

[0025] This application does not limit when the read operation is triggered. In some embodiments, it may be triggered automatically when the first target buffer page group is full. In other embodiments, it may be triggered in real time based on a test request. This application will not elaborate on these points.

[0026] DSP debugging data is written to free pages in the first target buffer page group. External terminal devices read data from pages in the second target buffer page group that contain valid DSP data. This application embodiment does not restrict how the first target buffer page group determines free pages.

[0027] The data operation attribute indicates whether the corresponding buffer page group is used for writing data to the DSP or for reading data from external terminal devices.

[0028] Therefore, in the method of the above embodiments of this application, the MCU constructs a transparent transmission channel through the first buffer page group and the second buffer page group. It can directly bridge the first buffer page group and the second buffer page group without parsing, converting or modifying the content of the debugging data, so that the DSP and the external terminal device can directly transmit DSP test data.

[0029] For example, assume the first buffer page group is Buffer_A and the second buffer page group is Buffer_B. In the case of the optical module's first startup test, the first target buffer page group is Buffer_A, directly mapped to the DSP-side interface (in practical applications, the address mapping of Buffer_A to the DSP can be achieved through direct connection of register pointers). Assume that at time t, the test data generated by the DSP is directly written to Buffer_A (at this time, since the MCU does not intervene, Buffer_A is equivalent to a DSP register); then at time t1, when Buffer_A is redefined as the second target buffer page group as a "read buffer," Buffer_B is remapped to the DSP-side interface to continue data writing. Correspondingly, the data in Buffer_A can be read by an external terminal device through the second serial communication bus interface. Here, time t1 could be the time when Buffer_A, as the first target buffer page group, is full, or the time when a read request is received from an external terminal device after at least one single page has been completed, or the time when there is no unread data in the second target buffer page group after the first target buffer page group has completed a single page write operation, etc. In practical applications, Buffer_B and Buffer_A can be operated by the DSP and the external terminal device respectively at any other time. Therefore, in this embodiment of the application, the external terminal device can extract the DSP debugging data written historically by the DSP through the second target buffer page group, while the first target buffer page group can write the data sent by the DSP to the external terminal device in real time.

[0030] In summary, the read and write operations of the first buffer page group and the second buffer page group in this embodiment of the application only require remapping to the corresponding serial communication bus interface. Therefore, in this embodiment of the application, the MCU does not need to execute the memcpy instruction to move data, but only switches the pointer address, which can realize zero memory copy, thereby reducing the CPU load of the MCU and enabling low-performance MCUs to handle high-speed debugging data streams.

[0031] Understandably, writing the DSP debugging data from the DSP write request into the first target buffer page group includes: Search for free pages in the first target buffer page group; When there are no free pages in the first target buffer page group and the data in the second target buffer page group has been read, swap the buffer page groups corresponding to the first target buffer page group and the buffer page groups mapped by the second target buffer page group respectively, and clear the buffer page group after the swap of the first target buffer page group; Starting from the first page address of the first page of the first target buffer page group, cache the DSP debugging data in the DSP write request.

[0032] After the buffer page group is cleared and swapped from the first target buffer page group, the first page is the free page of the first target buffer page group.

[0033] In some embodiments, when valid data still exists in the second target buffer page group, if there are no free pages in the first target buffer page group, or if the read duration of valid data still existing in the second target buffer page group is greater than the write duration of free pages and the number of free pages is less than a preset redundancy threshold, the rate of the first serial communication bus interface can be adjusted to reduce the probability of DSP debugging data being discarded. In other embodiments, when there are no free pages in the first target buffer page group and valid data still exists in the second target buffer page group, the DSP can be notified through the first serial communication bus interface to pause sending DSP debugging data until there is no valid data in the second target buffer page group. In this case, it can be ensured that every piece of DSP debugging data written can be read by the external terminal device. This application will not elaborate on these points in detail, and those skilled in the art can selectively configure them according to actual conditions.

[0034] Swapping the buffer page groups mapped to the first and second target buffer page groups signifies redefining the buffer page group corresponding to the first target buffer page group as the logical second target buffer page group, and redefining the buffer page group corresponding to the second target buffer page group as the logical first target buffer page group. For example, suppose the first buffer page group is Buffer_A and the second buffer page group is Buffer_B. At time t1, the first target buffer page group is Buffer_A and the second target buffer page group is Buffer_B. After swapping the buffer page groups mapped to the first and second target buffer page groups, the first target buffer page group becomes Buffer_B, and the second target buffer page group becomes Buffer_A.

[0035] By swapping the buffer page groups corresponding to the first target buffer page group and the buffer page groups mapped to the second target buffer page group, and then clearing the buffer page groups after the swap, it is possible to reduce the amount of information required for maintaining the buffer page groups, and thus reduce the load on the MCU, when the first target buffer page group is switched to the second target buffer page group before it is full. At this point, the MCU only needs to record the number of data operations, the starting address, the currently operated page, and the address offset of each page for each buffer page group to achieve mutual exclusion control of operations between the first and second buffer page groups during data processing.

[0036] Understandably, the method also includes: When an unprocessed switching instruction is detected, the buffer page groups mapped to the first target buffer page group and the second target buffer page group are swapped.

[0037] This application does not limit the source of the switching command. In some embodiments, the switching command may be triggered actively when the second target buffer page group has completed reading all data, that is, triggered in real time when there is no valid data in the second target buffer page group. In other embodiments, it may also be triggered in real time after receiving a query command from an external terminal device after the second target buffer page group has completed reading all data, thereby allowing the external terminal device to continuously perform data reading operations and improve testing efficiency. This application will not elaborate on these points further.

[0038] Understandably, the DSP communicates with the MCU via a first serial communication bus interface, which is used to carry the DSP's CMIS management data and DSP debugging data; it receives a DSP write request from the digital signal processor (DSP), including: Receive DSP data packets from the first serial communication bus interface and determine the data type of the DSP data packets; When the data type is test data, it is confirmed that a DSP write request has been received from the DSP.

[0039] By using a reuse method, the physical connection between the DSP and MCU can be maintained without changing it.

[0040] Understandably, the data type of the DSP data packet is determined to include at least one of the following: When the protocol address carried in the DSP data packet matches the preset debugging address, the data type is determined to be test data; When the data packet format of the DSP data packet matches the preset debugging format, the data type is determined to be test data.

[0041] In some embodiments, both the protocol address and the data packet format can be verified. In other embodiments, only one of them can be verified. For example, if the protocol address and the debugging address match, the data type is directly determined to be test data. If the data packet format matches the debugging format, the data type is directly determined to be test data.

[0042] It is understood that the calibration data processing method provided according to the embodiments of this application is applied to a digital signal processor (DSP), which is used to install in an optical module; see reference Figure 2 As shown, the method includes: Step S210: According to the test request, obtain the DSP debugging data and encapsulate the DSP debugging data into a DSP data packet according to the preset protocol format; the test request is a request forwarded by the microcontroller MCU connected to the DSP and originating from an external terminal device. Step S220: Based on the DSP data packet, initiate a DSP write request to the MCU, so that when the MCU receives the DSP write request, it determines the first target buffer page group from the first buffer page group and the second buffer page group, and writes the DSP debugging data in the DSP write request into the first target buffer page group. The first buffer page group and the second buffer page group are obtained by dividing at least a portion of the continuous physical space in the static random access memory (SRAM) when the MCU detects that the preset debugging start conditions are met. The second target buffer page group, excluding the first target buffer page group, is used to provide cached DSP debugging data to external terminal devices. At the same time, the second target buffer page group and the first target buffer page group are different. The data operation attributes of each page in the same second target buffer page group are the same, and the data operation attributes of each page in the same first target buffer page group are also the same.

[0043] By dividing the contiguous physical space of the SRAM in the MCU into a first buffer page group and a second buffer page group, each of the first and second buffer page groups consists of at least one page. When the MCU receives a DSP write request, the DSP test data corresponding to the DSP write request is directly written to the first target buffer page group. Correspondingly, data is directly read from the second target buffer page group and sent to the external terminal device. At this time, since the first and second target buffer page groups are different at the same time, that is, at the same time, the external terminal device and the DSP can simultaneously perform read and write operations on different buffer page groups, thereby decoupling the operations between the MCU and the external terminal device and the DSP, ensuring that the DSP test data is transmitted to the MCU with higher transmission efficiency. At the same time, since the first and second buffer page groups consist of at least one page, both reading and writing data are performed in units of pages, which can limit the maximum amount of data occupied in SRAM at one time, reduce the risk of overflow, and thus ensure the integrity of the DSP debugging data being safely transmitted from the MCU to the external terminal device. This application embodiment does not require the MCU to parse data from the DSP, nor does it require customization of the optical module or DSP, resulting in lower production costs. Furthermore, since the DSP debugging and data transmission efficiency of a single optical module is higher and the debugging process is independent of the MCU, the testing efficiency in batch application scenarios of optical modules can be improved.

[0044] In some embodiments, a test request is used to indicate the test items for the DSP, and the specific test logic is integrated into the DSP. The DSP debugging data is test data generated based on the test request. This DSP debugging data can correspond one-to-one with the test request, or it can be generated based on the test request cycle. This application embodiment does not impose any restrictions on this.

[0045] Understandably, the DSP debugging data is encapsulated according to a preset protocol format to obtain a DSP data packet, which includes: Parameter type identification of DSP debugging data; When the DSP debugging data includes a first parameter of the core parameter type, the first parameter is processed according to the pre-configured access permission parameters to obtain the second parameter; The second and / or third parameters are encapsulated according to the protocol format to obtain the DSP data packet, where the third parameter is a non-core parameter type.

[0046] By classifying and managing DSP commissioning data according to parameters, it is possible to more quickly identify and locate different types of parameters, thereby improving the convenience of optical module commissioning and the efficiency of DSP commissioning after the deployment of optical modules. This application does not limit the parameter types. In some embodiments, core parameter types and non-core parameter types can be further subdivided; however, this application will not elaborate on these details.

[0047] In some embodiments, the permission requirements for core parameter types are greater than those for non-core parameter types. The degree of control over accessing users and tools differs between core and non-core parameter types. Access permission parameters can be encryption keys or access permission information. In this case, for key-based parameters, the external terminal device needs the corresponding decryption key to decrypt and view the information. For permission information, the external terminal device verifies the permission information before displaying it. In some embodiments, encryption can be applied to both core and non-core parameter types. Different parameter types use different encryption methods and key distribution methods, thereby achieving different levels of control over different parameter types. This application will not elaborate on these details in its embodiments; those skilled in the art can selectively configure them according to actual circumstances.

[0048] For DSP data packets, a DSP data packet may include only the second parameter, only the third parameter, or both the second and third parameters. This application will not elaborate on these points in its embodiments.

[0049] For example, as shown in the parameter type definitions in Table 1 below, this application embodiment divides DSP debugging data into two main categories:

[0050] Table 1 Understandably, parameter type identification of DSP debugging data includes at least one of the following: Algorithm parameter identification is performed on DSP debugging data; Physical coding sublayer (PCS) data identification is performed on DSP commissioning data; The DSP debugging data is used to identify performance parameters, including at least one of the following: equalization convergence time, transmitter signal integrity parameters, chip temperature, and firmware version parameters.

[0051] Algorithm parameters refer to the algorithm parameters involved in fault diagnosis in the private algorithm defined inside the DSP.

[0052] PCS data refers to data generated by the PCS layer.

[0053] Performance parameters are used to indicate relevant parameters involved in performance diagnostics in non-private algorithms.

[0054] For example, the following example shows the DSP actively reporting DSP debugging data after starting the debugging process. Figure 3 Taking the optical module's slot-hopping data processing method as an example from an embodiment of this application, the specific process is as follows: S1. DSP generates DSP debugging data: In some embodiments, the DSP chip automatically generates debugging information including at least one of the following parameters: register value snapshot, state machine state transition, FEC statistical counter, equalizer coefficient, runtime log, etc.

[0055] S2. DSP Writes to the First Target Buffer Page Group: The MCU writes the DSP debugging data to the buffer of the free page in the first target buffer page group of the MCU through the first serial communication bus interface. The DSP debugging data is a raw byte stream and does not require protocol negotiation. The address of the free page is a standardized page address, that is, a page number / page base address with fixed bit field division as specified in the device datasheet.

[0056] S3, The host reads directly from the second target buffer page group: The host device (i.e., the external terminal device) reads the valid page of the MCU through the second serial communication interface bus. The valid page indicates that it contains DSP debugging data and has not been read before. At this point, the external terminal device can obtain the DSP raw data stream through the second target buffer page group, and parse and visualize the DSP raw data stream using a dedicated tool.

[0057] Therefore, as can be seen from the above embodiments, the MCU, acting as a transparent bridge, can receive DSP data and directly write it to the page buffer without parsing DSP test data or modifying any bytes in the DSP test data. Since the MCU, acting as a transparent bridge, uses double-buffered ping-pong and zero-copy technology, its memory usage can be controlled at the KB level, reducing CPU usage by more than 80%, thus making it suitable for more low-cost optical module MCUs. Correspondingly, the DSP's debugging capabilities do not depend on the MCU but rather on the parsing capabilities of the external terminal device and the DSP's own firmware version. Furthermore, by identifying different parameter types, the types and information of diagnostic information can be customized, improving the efficiency and convenience of DSP debugging. Especially in the scenario of batch testing of optical modules, this embodiment allows one external terminal device to simultaneously perform remote or direct debugging of multiple optical modules, thereby improving the debugging efficiency supported by FAE on-site. Simultaneously, since the MCU does not need to parse DSP debugging data, the MCU and DSP can be completely decoupled, reducing the DSP's dependence on the MCU's protocol parsing and lowering the development threshold. Therefore, this embodiment can further improve the testing efficiency of optical modules and reduce management costs.

[0058] Understandably, referring to Figure 4 As shown, an optical module according to an embodiment of this application includes: The microcontroller processor (MCU) is equipped with a second serial communication bus interface and a first serial communication bus interface. The digital signal processor (DSP) communicates with the MCU via a first serial communication bus interface. The DSP is used to perform the following steps: According to the test request, the DSP debugging data is obtained and encapsulated into a DSP data packet according to the preset protocol format; the test request is received from the external terminal device through the second serial communication bus interface; Based on the DSP data packet, initiate a DSP write request to the MCU; The MCU is used to perform the following steps: In response to the detection that the preset debugging start conditions are met, at least a portion of the continuous physical space in the static random access memory (SRAM) is divided to obtain a first buffer page group and a second buffer page group. In response to receiving a DSP write request from a digital signal processor (DSP), a first target buffer page group is determined from the first buffer page group and the second buffer page group, and the DSP debugging data in the DSP write request is written into the first target buffer page group; The cached DSP debugging data will be read from the second target buffer page group and sent to the external terminal device; the second target buffer page group is one of the first buffer page group and the second buffer page group. At the same time, the second target buffer page group and the first target buffer page group are different; the data operation attributes of each page in the same second target buffer page group are the same, and the data operation attributes of each page in the same first target buffer page group are the same.

[0059] For example, taking a scenario where both the first and second serial communication bus interfaces are I2C, such as... Figure 5 As shown, this application embodiment provides a commissioning system, which includes a Host terminal (i.e., the aforementioned external terminal device) and an optical module; The optical module and host terminal are connected via an I2CA bus. The optical module integrates an MCU and a DSP, which are connected via an I2CB bus. The host terminal is equipped with debugging tools for visualizing and statistically analyzing DSP performance, algorithms, and PCS data. Performance parameters include TX Fir, chip temperature, RX parameter information, bit error rate, chip ID, and version information. Algorithm parameters include register information, and PCS data includes PCS information. The MCU uses pages to store DSP test data as diagnostic information, preserving the DSP's raw diagnostic information. A monitoring module is included in the DSP to monitor test requests transmitted through the MCU and packages the DSP test data as diagnostic information, storing it in the MCU's pages via I2CB.

[0060] For example, see below. Figure 5 and Figure 6 The debugging process based on the debugging system in this application embodiment is described below, with specific steps as follows: S1. MCU power-on initialization: This application embodiment does not limit the content of MCU power-on initialization. It can refer to the MCU initialization process of optical modules in the prior art. This application embodiment will not elaborate on this point.

[0061] S2: Configure the second serial communication bus interface: For example, such as Figure 5 As shown, the Host terminal is configured as the master of the MCU, and the MCU is the slave of the Host terminal, so that one Host terminal can simultaneously debug multiple MCUs.

[0062] S3. Configure the first serial communication bus interface: For example, such as... Figure 5 As shown, the DSP is configured as the slave of the MCU and the MCU is the master of the host. This enables the transparent transmission of DSP test data between the DSP and the host terminal in scenarios where one MCU corresponds to one DSP or one MCU corresponds to multiple DSPs.

[0063] S4. Initialize Page Buffer: For example, if the received instruction to initialize the Page buffer is taken as a preset debugging start condition, then at least a portion of the continuous physical space in the SRAM is divided into multiple Pages, and the multiple Pages are divided into a first buffer page group and a second buffer page group, and the first buffer page group and the second buffer page group are cleared.

[0064] S5. After the first serial communication bus interface is configured, the DSP is powered on.

[0065] S6. Initialize the I2CB interface on the DSP side: For example, such as Figure 5 As shown, the DSP configures the interface connected to the I2CB as a slave.

[0066] S7. DSP Real-time Update Diagnostic Information: The DSP real-time update diagnostic information is an operation performed when the Host terminal actively issues a test start command or when the DSP reads the configuration file and determines that it is in debugging mode.

[0067] S8. Pack diagnostic information: When the DSP determines that the Host terminal has initiated a test request, the current diagnostic information is packaged as DSP test data and sent to the MCU. S9, Page buffer DSP test data: The MCU saves the DSP's DSP test data to the first target buffer page group.

[0068] S10. When the MCU determines that the Host terminal has initiated a test request and the DSP has written test data, it performs a read operation on the second target buffer page group and sends it to the Host terminal so that the Host terminal can receive the DSP test data and display it in the tool.

[0069] Therefore, based on the above Figure 6As can be seen from the examples, since the debugging data in S1~S10 of this application embodiment is generated by the DSP, the debugging data can be self-describing. In the FAE test scenario, the data type can be automatically identified by the host general parsing software, realizing the protection of the DSP's internal algorithm while performing testing. Moreover, since this application embodiment adopts a dual buffering mechanism that uses the first target buffer page group and the second target buffer page group to jointly realize the DSP's write and the Host terminal's read, it can support multi-rate adaptation of 100KHz / 400KHz / 1MHz. The DSP-side rate and the host-side rate are decoupled, so that the DSP can realize the transmission of high-number data streams even in the Host terminal's low-number mode, ensuring test efficiency. In some embodiments, in step S8 of the above embodiment of this application, public debugging information (read-only) and private debugging information (requiring authorization) can be distinguished, and access permissions for sensitive algorithm parameters (such as equalizer coefficients, FEC configuration) can be controlled, thereby achieving the security maintenance of the DSP itself and the rapid classification and location of debugging while satisfying fault diagnosis.

[0070] The first serial communication bus interface and the second serial communication bus interface in the above embodiments of this application can be set to any one of I2C, SPI or MDIO.

[0071] This application also provides a computer-readable storage medium that stores a computer program that, when executed by a processor, implements the above-described debugging data processing method.

[0072] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0073] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0074] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0075] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0076] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0077] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0078] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0079] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0080] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0081] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0082] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it 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 all or part 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 multiple 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 of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0083] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A method for processing commissioning data, characterized in that, The method is applied to a microcontroller unit (MCU), which is used to be installed in an optical module; the method includes: In response to the detection that the preset debugging start conditions are met, at least a portion of the continuous physical space in the static random access memory (SRAM) is divided to obtain a first buffer page group and a second buffer page group. In response to receiving a DSP write request from a digital signal processor (DSP), a first target buffer page group is determined from the first buffer page group and the second buffer page group, and the DSP debugging data in the DSP write request is written into the first target buffer page group; Read the cached DSP debugging data from the second target buffer page group and send it to the external terminal device; the second target buffer page group is one of the first buffer page group and the second buffer page group. At any given time, the second target buffer page group and the first target buffer page group are different; the data operation attributes of each page in the same second target buffer page group are the same, and the data operation attributes of each page in the same first target buffer page group are the same.

2. The data processing method according to claim 1, characterized in that, The step of writing the DSP debugging data in the DSP write request into the first target buffer page group includes: Search for free Pages in the first target buffer page group; When there are no free Pages in the first target buffer page group and the data in the second target buffer page group has been read, the buffer page groups corresponding to the first target buffer page group and the buffer page groups mapped by the second target buffer page group are swapped and the swapped buffer page groups of the first target buffer page group are cleared. Starting from the first page address of the first page of the first target buffer page group, the DSP debugging data in the DSP write request is cached.

3. The data processing method according to claim 1 or 2, characterized in that, The method further includes: When an unprocessed switching instruction is detected, the buffer page groups mapped to the first target buffer page group and the second target buffer page group are swapped.

4. The data processing method according to claim 1, characterized in that, The DSP communicates with the MCU through a first serial communication bus interface, and the first serial communication bus interface is used to carry the CMIS management data of the DSP and the debugging data of the DSP. The receipt of a DSP write request from a digital signal processor (DSP) includes: Receive DSP data packets from the first serial communication bus interface and determine the data type of the DSP data packets; When the data type is test data, it is determined that a DSP write request has been received from the DSP.

5. The data processing method according to claim 4, characterized in that, Determining the data type of the DSP data packet includes at least one of the following: When the protocol address carried in the DSP data packet matches the preset debugging address, the data type is determined to be test data; When the data packet format of the DSP data packet matches the preset debugging format, the data type is determined to be test data.

6. A method for processing commissioning data, characterized in that, The method is applied to a digital signal processor (DSP), which is used to be installed in an optical module; the method includes: According to the test request, DSP debugging data is obtained and encapsulated into DSP data packets according to a preset protocol format; the test request is a request forwarded by the microcontroller MCU connected to the DSP and originates from an external terminal device. According to the DSP data packet, a DSP write request is initiated to the MCU, so that when the MCU receives the DSP write request, it determines the first target buffer page group from the first buffer page group and the second buffer page group, and writes the DSP debugging data in the DSP write request into the first target buffer page group; The first buffer page group and the second buffer page group are obtained by dividing at least a portion of the continuous physical space in the static random access memory (SRAM) when the MCU detects that the preset debugging start conditions are met. The second target buffer page group, excluding the first target buffer page group, is used to provide cached DSP debugging data to external terminal devices. At the same time, the second target buffer page group and the first target buffer page group are different. The data operation attributes of each page in the same second target buffer page group are the same, and the data operation attributes of each page in the same first target buffer page group are the same.

7. The data processing method according to claim 6, characterized in that, The process of encapsulating the DSP testing data according to a preset protocol format to obtain a DSP data packet includes: Parameter type identification is performed on the DSP debugging data; When the DSP debugging data includes a first parameter of the core parameter type, the first parameter is processed according to the pre-configured access permission parameter to obtain the second parameter; The second parameter and / or the third parameter are encapsulated according to the protocol format to obtain a DSP data packet, wherein the third parameter is a non-core parameter type parameter.

8. The data processing method according to claim 7, characterized in that, The parameter type identification of the DSP debugging data includes at least one of the following: Algorithm parameter identification is performed on the DSP debugging data; The DSP debugging data is used for physical coding sublayer PCS data identification; The DSP debugging data is used to identify performance parameters, which include at least one of the following: equalization convergence time, transmitter signal integrity parameters, chip temperature, and firmware version parameters.

9. An optical module, characterized in that, include: A microcontroller processor (MCU), wherein the MCU is provided with a second serial communication bus interface and a first serial communication bus interface; A digital signal processor (DSP), wherein the DSP is connected to the MCU via the first serial communication bus interface; The MCU executes the debugging data processing method as described in any one of claims 1 to 5; The DSP performs the debugging data processing method as described in any one of claims 6 to 8.

10. A computer-readable storage medium storing computer-executable instructions, characterized in that, The computer-executable instructions are used by a processor to execute the debugging data processing method as described in any one of claims 1 to 8.

Images