Multi-chip burning system and method based on wireless synchronization and data management

Abstract

According to the multi-chip burning system based on wireless synchronization and data management provided by the invention, all burning data files are uniformly placed on the remote server, and the burning equipment in the production department of each region is in communication connection with the remote server; a to-be-burnt file is obtained from a remote server based on the master control module and stored in a storage module of the burning device, a to-be-burnt chip is connected to an IO channel of the slave control module, and data burning operation on the to-be-burnt chip is achieved through the slave control module by means of the master control module. The burning data and the burning mode are unified through the cloud server, and after the model of the burnt product is specified, the main control module extracts the corresponding burning file read from the cloud server, and technical personnel do not need to manually store the data into the burning equipment, so that the efficiency is improved, the error probability is reduced, and the burning efficiency is improved. And the method is especially suitable for application scenes in which cross-regional production departments perform version updating at the same time.

Description

Technical Field

[0001] This invention relates to the field of electronic device manufacturing technology, specifically to a multi-chip programming system and method based on wireless synchronization and data management. Background Technology

[0002] Chips are widely used in electronic products. During the manufacturing process, specific firmware programs or configuration data need to be burned into the chip's internal storage to achieve predetermined functions. Traditional methods of burning internal chip data mostly involve using specific burning tools to burn the program into the chip via interfaces such as JTAG, SWD, UART, or USB. In existing technologies, the burned data is tied to specific burning equipment. When updates or additions to the burning process are needed, engineers must be physically present at the equipment site to import the burned data one by one via wired methods such as USB flash drives or serial ports. This is feasible for a small number of chips, but in modern production lines with cross-regional and multi-factory management, frequent switching of burning tasks is often required. If the existing method is used for every chip data burning, a simple data update might take several days to complete, resulting in extremely low efficiency. Furthermore, different production departments in different regions often incur significant communication costs to ensure consistent batch versions of chip data. Summary of the Invention

[0003] To address the issue that existing chip data burning methods are unsuitable for application scenarios involving large-scale, high-frequency chip data updates across regions, this invention provides a multi-chip burning system based on wireless synchronization and data management. This system provides unified management of burning data and methods, effectively improving the efficiency of data burning and enabling data synchronization between departments across regions.

[0004] The technical solution of the present invention is as follows: a multi-chip programming system based on wireless synchronization and data management, characterized in that it includes: a remote server and a programming device, wherein the remote server and the programming device are connected in communication. The remote server stores the programming data files for all models of chip products and provides file access services; The human-computer interaction module is connected to the main control module and is used to receive user commands and display device status; The programming device includes: a master control module, a slave control module, a communication module, a storage module, and a human-computer interaction module; The main control module is implemented based on a SoC chip and serves as the core management unit of the device, responsible for user interaction, network communication, data synchronization, and task scheduling. The main control module downloads the file to be burned from the remote server and stores it in the storage module. The main control module establishes a communication connection with the remote server based on the communication module. The communication module supports both wireless and wired communication. The master control module and the slave control module are connected based on a communication interface; The slave control module is based on a microcontroller with IO interface resources as its core module and is responsible for executing the programming algorithm; the number of IO interfaces is greater than 1; the programming device is installed on the production line and connects to the chip to be programmed through the IO interface of the slave control module as a programming channel.

[0005] Its further features are: The main control module is implemented based on T113 or RK3566, and the slave control module is implemented based on STM32F407 chip.

[0006] A multi-chip programming method based on wireless synchronization and data management, characterized by comprising the following steps: S1: Store the programming data files of all chip products according to the product catalog on a remote server; When storing data, each data file also stores the corresponding checksum. The files in each product directory on the remote server are kept to be the latest version. S2: After the programming device is powered on, it sends a connection request to the remote server; The remote server performs two-way encrypted authentication with the burning device that sent the request, and establishes a secure data channel with the burning device after successful authentication. S3: After authentication, the burning device requests the file directory list on the remote server and compares it with the local file directory list; if the two are inconsistent, the local file directory list is updated to make the version of the local file directory list consistent with the version of the file directory list on the remote server. S4: During the burning process, the target product catalog to be burned is specified based on the local file directory list; Once the target directory is selected, the main control module of the burning device obtains the names and sizes of all data files in the target directory on the remote server and synchronizes the data on the remote server with the local data; S5: Entering the programming process; the main control module reads the programming algorithm file and data file corresponding to the product to be programmed from local storage, and sends programming-related commands and data to the slave control module through the SPI interface; S6: The slave control module receives instructions and data from the master control module, drives the programming channels, and performs programming operations on the chips to be programmed connected to each programming channel. S7: The slave control module feeds back the real-time burning status of each channel to the main control module of the system in real time until the burning process is completed.

[0007] Its further features are: In step S4, when the burning device synchronizes the data on the remote server with the local data, it specifically includes the following steps: a1: Retrieves each data file included in the target directory on the remote server, denoted as: target file; Search the storage module of the burning device for all data files with the same name as the target file. If the file can be found, record it as a local file with the same name, and then proceed to step a2; If not found, the target file will be loaded into the storage module of the burning device; a2: Obtain the size of the target file and compare the size of the local file with the same name with the size of the target file; If the two are consistent, proceed to step a3; If the two are inconsistent, after archiving and saving the local file with the same name and creating a historical version, download the target file and replace the local file with the same name in the storage module; a3: Read the verification value corresponding to the target file, denoted as: target verification value; read the verification value of the local file with the same name in the storage module, denoted as: file with the same name verification value; compare the target verification value and the file with the same name verification value; If the two match, proceed to step a4; If the two are inconsistent, the local file with the same name will be archived and saved, and a historical version will be created. Then, the target file will be downloaded and replaced with the local file with the same name in the storage module. a4: Perform no operation on the target file and terminate the synchronization process of the target file; a5: Repeat steps a1~a4 to perform the synchronization process on all target files in the target directory on the remote server; Step S6 specifically includes the following steps: b1: Two memory regions of the same size are allocated inside the slave control module, denoted as: buffer A and buffer B; Initialize a buffer state manager, which records the state of each buffer; The buffer status includes: idle, DMA receiving, receiving completed and awaiting decryption, decrypting, decrypting completed and awaiting burning, burning, and error; The initial state of each buffer is: free; b2: Before each programming session begins, the slave control module sends a ready signal to the master control module; b3: The master control module prepares the first frame of data after receiving the slave control ready signal; A data frame includes: a frame header, a frame number, a data length, ciphertext data, and a checksum; b4: The master control module transmits data to the slave control module via SPI; The slave control module sets the state of buffer A to "DMA receiving" and configures SPI DMA control, points the receiving target address pointer to buffer A, and the DMA starts transferring data to buffer A; b5: After the slave DMA finishes filling buffer A with data, the state of buffer A is changed to: reception complete, awaiting decryption; at the same time, the slave module sends a ready signal to the master module. b6: After receiving the ready signal from the slave module, the master control module determines whether the data transmission for this programming is complete; If the data transmission is complete, the master controller will not perform any operation and will execute step b17; If data transmission is not completed, send the next frame of data and proceed to step b7; b7: The slave module sets the state of buffer B to DMA receiving and configures the DMA to point the target address pointer of the next frame of data to buffer B; the slave DMA starts to move the data from the slave module to buffer B in the background. At the same time, the CPU of the slave module starts to perform decryption operation on buffer A, which is in the state of receiving completed and waiting to be decrypted. The state of buffer A changes to decryption. b8: When the decryption of buffer A is completed, its status is changed to decryption complete and ready for programming; the programming controller of the slave module starts to program the plaintext data in buffer A to the chip to be programmed, and changes the status of buffer A to programming. Simultaneously with the operation of buffer A, after the slave DMA has moved all the data for this time to buffer B, the state of buffer B is changed to receive complete and awaiting decryption; b9: After buffer A is programmed, the state of buffer A is reset to idle; the idle buffer is reused by DMA for subsequent data frames; at the same time as the state of buffer A is reset to idle, the slave controller sends a ready signal to the master controller. b10: After receiving the slave ready signal, the master control module determines whether the data transmission for this programming is complete; If the data transmission is complete, the master controller will not perform any operation and will execute step b17; If data transmission is not completed, send the next frame of data and execute step b11; b11: The slave control module sets the state of buffer A to DMA receiving and configures SPI DMA control, points the receiving target address pointer to buffer A, and the DMA starts transferring data to buffer A in the background; Simultaneously with the operation of buffer A, the slave CPU begins the decryption operation on buffer B, which is in the state of receiving completed and awaiting decryption, and the state of buffer B changes to decryption in progress; b12: When the decryption of buffer B is completed, its status changes to decryption complete and ready for programming; the programming controller of the slave module starts to program the plaintext data in buffer B to the target chip, and changes the status of buffer B to programming in progress. Simultaneously with the operation in buffer B, the DMA has already moved the data to buffer A, and the state of buffer A changes to "received and awaiting decryption". b13: When buffer B is burned, its state is reset to idle, and the idle buffer is reused by DMA for subsequent data frames; at the same time that the state of buffer B becomes idle, the slave control module sends a ready signal to the master control module. b14: ​​After receiving the slave ready signal, the master control module determines whether the data transmission for this programming is complete; If the data transmission is complete, the master controller will not perform any operation and will execute step b17; If data transmission is not complete, send the next frame of data and execute b15; b15: The slave control module sets the state of buffer B to DMA receiving and configures SPI DMA control. It points the receiving target address pointer to buffer B, and the DMA starts transferring data to buffer B in the background. At this time, the slave control CPU starts decrypting buffer A, which is in the state of receiving completed and waiting to be decrypted. The state of buffer A changes to decrypting. b16: Repeat steps b8~b15; b17: The controller determines the status of the two buffers, finds the buffer whose status is "received complete and awaiting decryption", names it buffer X; performs decryption operation on buffer X, and changes the status of buffer X to "decrypting". b18: After buffer X is decrypted, the plaintext data in buffer X is burned to the target chip and its status is changed to burning; after buffer X is burned, its status is reset to idle and the idle buffer is reused by DMA for subsequent data frames. This burning process is now complete; The verification value includes: a CRC check value or a hash value; In step S1, when the programming data files of all chip products of all models are stored on the remote server according to the product catalog, the remote server also saves the catalog digest hash value for all files in the product catalog of each chip product model. The method for generating the directory digest hash value includes the following steps: c1: Read all data files in the target directory and obtain the file metadata set for each data file; The file metadata set includes: the filenames of all files in the directory, the size of each file, and the last modification time of each file; The size of each file is accurate to bytes, and the modification time of each file is accurate to seconds; c2: Sort all files alphabetically by filename; c3: For the sorted file list, retrieve the files one by one in reverse order, denoted as: files to be processed; perform the following processing on the files to be processed: Convert the filename to a UTF-8 byte sequence; Convert the file size into an 8-byte sequence; Convert the last modification time of the file to be processed into an 8-byte sequence; c4: Concatenate the three-byte sequence corresponding to the file to be processed in the order of filename, file size and modification time, and record it as: file description byte stream; c5: Concatenate the file description byte streams corresponding to all data files in the target directory according to the file name order to form a complete description byte stream of the target directory; c6: Calculate the SHA256 hash value for the complete description byte stream of the target directory to obtain the directory digest hash value; c7: Whenever any file included in a product catalog changes, execute steps c1 to c6 in a loop to update the catalog digest hash value corresponding to the product catalog; In step S4, before the programming device synchronizes the data on the remote server with the local data, it first performs the following steps: d1: For the target directory, the main control module of the burning device sends a directory summary request to the remote server; d2: Upon receiving the request, the remote server queries the database to obtain the latest directory digest hash value corresponding to the target directory and sends it to the burning device; d3: The main control module compares the directory digest hash value of the server with the directory digest hash value stored in the burning device; If the digest hash values ​​of the two directories are inconsistent or there is no digest hash value locally, the latest digest hash value is stored in the local index and d4 is executed; If the hash values ​​of the two directory digests are the same, then execute d5; d4: The burning device in step S4 performs the operation of synchronizing the data on the remote server with the local data; d5: Skip the operation of synchronizing data on the remote server with local data performed by the burning device in step S4, and directly execute step S5.

[0008] This application provides a multi-chip programming system based on wireless synchronization and data management. All programming data files are uniformly placed on a remote server. Programming devices in production departments across different regions communicate with the remote server. A master control module retrieves the programming files from the remote server and stores them in the storage module of the programming device. The chip to be programmed is connected to the I / O channel of a slave control module. The master control module, through the slave control module, performs the data programming operation on the chip. A cloud server unifies the programming data and programming method. After specifying the product model to be programmed, the master control module retrieves the corresponding programming file from the cloud server. This eliminates the need for manual data storage in the programming device, improving efficiency, reducing error probability, and is particularly suitable for application scenarios where version updates are performed simultaneously across production departments in different regions. This application designs a dual-buffer mechanism, combined with Direct Memory Access (DMA) technology, to change the three main operations—data reception, decryption calculation, and data programming—from serial to parallel execution. This reduces the overall system time from the sum of the three stages to the time of the longest stage, significantly improving system efficiency. This application designs a directory digest hashing mechanism, which reduces the determination of the necessity of directory synchronization from minutes to milliseconds. Without affecting the synchronization accuracy, it greatly improves the device response speed and production efficiency, and is particularly suitable for scenarios in factory production where product catalogs are frequently switched but the catalogs are synchronized most of the time. Attached Figure Description

[0009] Figure 1 This is a hardware system block diagram of the multi-chip programming system based on wireless synchronization and data management in this application.

[0010] Figure 2 This is the overall flowchart of the multi-chip programming method based on wireless synchronization and data management in this application.

[0011] Figure 3 Flowchart for security authentication and directory-level synchronization.

[0012] Figure 4 This is a flowchart for file-level intelligent synchronization.

[0013] Figure 5 This is a flowchart of the parallel programming process for chip products. Detailed Implementation

[0014] like Figure 1As shown, this application includes a multi-chip programming system based on wireless synchronization and data management, which includes: a remote server and a programming device, and a communication connection between the remote server and the programming device.

[0015] The remote server stores the programming data files for all chip models and provides file access services. The remote server is the data hub of the entire system; engineers can access the server anytime, anywhere via the internet to upload, modify, or delete programming data files. The specific implementation method is based on existing server technology.

[0016] The human-computer interaction module is connected to the main control module and is used to receive user commands and display device status. In this embodiment, the human-computer interaction module is implemented based on a touch screen. For example, the user can select a product on the programming device and start the programming program through the touch screen.

[0017] The programming device includes: a master control module, a slave control module, a communication module, a storage module, and a human-computer interaction module.

[0018] The main control module is implemented based on a SoC (System on Chip) chip. As the core management unit of the programming device, the main control module is responsible for user interaction, network communication, data synchronization and task scheduling. The main control module downloads the file to be programmed from the remote server and stores it in the storage module.

[0019] The main control module establishes a communication connection with the remote server based on the communication module; the communication module supports both wireless and wired communication, and in this embodiment, the device is securely connected to the remote server based on the Wi-Fi module.

[0020] The master control module and the slave control module are connected through a communication interface. In this embodiment, the connection between the master control module and the slave control module is implemented based on the SPI interface.

[0021] The slave module is based on a microcontroller with I / O interface resources as its core module and is responsible for executing the programming algorithm; the number of I / O interfaces is greater than 1; the programming device is installed on the production line and connects to the chip to be programmed through the I / O interface of the slave module as the programming channel.

[0022] like Figure 2As shown, the main control module can be implemented using a chip with partial SoC functionality in existing technology. In this embodiment, the main control module is implemented using a T113 or RK3566. The slave control module is implemented using a chip with multiple I / O ports in existing technology. In this embodiment, the slave control module is implemented using an STM32F407 chip. The multiple GPIO ports of the STM32F407 are configured as 10 independent programming interfaces (such as SWD, SPI, IIC), forming a 10-channel programming interface array. Each channel is equipped with necessary level conversion and driving circuits to adapt to the level requirements of different chips. The slave control module connects to the chip to be programmed through the programming interface array. The programming interface array contains multiple independent programming channels (such as 10 channels), and each channel can connect to one target chip to achieve parallel programming. In this embodiment, the programming interface array is implemented using a TX24A-80R-LT-H1E board-to-board connector.

[0023] The slave module receives instructions and data from the system master controller via the SPI interface and then parses the instructions. Utilizing its abundant I / O resources and processing capabilities, it simultaneously drives and controls all (e.g., 10) programming channels, performing synchronous or asynchronous programming operations on the target chips on each channel. The programming status (busy / idle, success / failure) of each channel is monitored independently. During programming, the real-time programming status of each channel is fed back to the system master controller module.

[0024] Based on the multi-chip programming system of this application, when updating or adding programming items, engineers do not need to touch any physical equipment. They only need to log in to the server via the network and upload the new or modified data files to the corresponding directory. This operation can be completed in the office, at home, or anywhere with network access, enabling efficient management of production data anytime, anywhere. The server serves as the sole trusted data source. Data updates on a single device only require a single upload operation on the server. All programming devices connected to the server will automatically execute the synchronization process described in this manual during startup or periodic checks, autonomously updating their local data to be consistent with the server's state. This represents a leap from a "one-to-one" wired update mode to a "one-to-many" wireless broadcast update mode, with update efficiency independent of the number of devices, greatly simplifying operation and maintenance management in large-scale production environments. At key nodes such as completing synchronization, starting programming, and successful / failed programming, the devices report status information (such as the selected product model, synchronization result, programming quantity, and error code) to the server via wireless communication modules. Administrators only need to log in to the server via the network to view information about all devices.

[0025] The programming method implemented using the above-mentioned multi-chip programming system based on wireless synchronization and data management specifically includes the following steps.

[0026] S1: Store the programming data files of all chip products according to the product catalog on a remote server; When storing data, each data file also stores a corresponding checksum; the checksum includes either a CRC checksum or a hash value. Files in each product directory on the remote server are kept up-to-date.

[0027] In step S1, when the programming data files of all chip products of all models are stored on the remote server according to the product catalog, the remote server also saves the catalog summary hash value for all files in the product catalog of each chip product model. The method for generating the directory summary hash value includes the following steps: c1: Reads all data files in the target directory and retrieves the file metadata set for each data file; The file metadata set includes: the filenames of all files in the directory, the size of each file, and the last modification time of each file; The size of each file is accurate to bytes, and the modification time of each file is accurate to seconds; c2: Sort all files alphabetically by filename to ensure that the same set of files always produces the same sorting result, and thus ensure that different directory contents produce different digest hash values; c3: For the sorted file list, retrieve the files one by one in reverse order, denoted as: files to be processed; perform the following processing on the files to be processed: Convert the filename to a UTF-8 byte sequence; Convert the file size into an 8-byte sequence; Convert the last modification time of the file to be processed into an 8-byte sequence; c4: Concatenate the three-byte sequence corresponding to the file to be processed in the order of filename, file size and modification time, and record it as: file description byte stream; c5: Concatenates the file description byte streams corresponding to all data files in the target directory according to the file name order to form a complete description byte stream of the target directory; c6: Calculate the SHA256 hash value for the complete description byte stream of the target directory to obtain the directory digest hash value; c7: Whenever any file included in a product catalog changes, such as adding, deleting, or modifying a file, steps c1 to c6 are executed cyclically to update the catalog summary hash value corresponding to the product catalog.

[0028] This method ensures that identical directory content always generates the same characteristic description. Each time the burning device successfully completes directory synchronization, it retrieves the latest digest hash value from the server and stores it in the local index.

[0029] S2: After the programming device is powered on, it sends a connection request to the remote server; The remote server and the requesting programming device perform two-way encrypted authentication. Upon successful authentication, a secure data channel is established between the server and the programming device. This two-way encrypted authentication is implemented using existing technologies, such as digital certificate or token authentication. In this embodiment, TLS two-way authentication based on an X.509 digital certificate is used. The device verifies the validity of the server certificate to ensure a legitimate connection; the server also verifies the device certificate to ensure it is an authorized device. If authentication fails, the server will not respond to any further requests from the device. Only after successful authentication will the server respond to subsequent requests from the device, ensuring the legitimacy of the communication and preventing unauthorized access.

[0030] S3: After successful authentication, the burning device requests the file directory list on the remote server and compares it with the local file directory list; if the two are inconsistent, the local file directory list is updated to make the local file directory list consistent with the version of the file directory list on the remote server.

[0031] like Figure 3 As shown, after successful authentication, the device obtains the server root directory list through a secure channel. It then performs directory comparison and synchronization, such as creating / Product_C / and deleting / Product_Old / .

[0032] S4: During the burning process, the target product catalog to be burned is specified based on the local file directory list; Once the target directory is selected, the main control module of the burning device obtains the names and sizes of all data files in the target directory on the remote server and synchronizes the data on the remote server with the local data.

[0033] In practice, when a user selects a specific product catalog "ProductA" via the touchscreen, the device will request the names and sizes of all data files in the / ProductA / directory from the server.

[0034] When this application requires synchronizing data files in a directory, the burning device first requests a list of files in the target directory from the cloud server via the FTP protocol. Then, it needs to traverse all files in the corresponding directory on the local storage module to obtain metadata for each file, such as filename, file size, and last modification time. Finally, it compares the local file list with the server list to determine which files need to be added, updated, or deleted. However, in actual production, a product's directory may contain many data files, potentially exceeding 500. Traversing all data files and obtaining their metadata via the standard file system API is time-consuming. Even if no files need to be added, removed, or updated, a complete traversal of all data files is still required. Since factories frequently switch burning tasks between different products, each switch involves synchronizing different directories, and this prolonged waiting time severely impacts production efficiency.

[0035] However, in actual production, it was found that in most cases, local files and server files are completely identical, and no actual synchronization is needed. Therefore, this method is designed to quickly determine whether synchronization is needed using directory digest hash values. Specifically, in step S4, before the burning device synchronizes the data on the remote server with the local data, it first performs the following steps: d1: For the target directory, the main control module of the burning device sends a directory summary request to the remote server; d2: The remote server receives the request, queries the database to obtain the latest directory digest hash value corresponding to the target directory, and sends it to the burning device; d3: The main control module compares the directory digest hash value of the server with the directory digest hash value stored in the burning device; If the digest hash values ​​of the two directories are inconsistent or there is no digest hash value locally, the latest digest hash value is stored in the local index and d4 is executed; If the hash values ​​of the two directory digests are the same, then execute d5; d4: The burning device in step S4 performs the operation of synchronizing the data on the remote server with the local data; d5: Skip the operation in step S4 where the burning device synchronizes the data on the remote server with the local data, and directly execute step S5.

[0036] This invention reduces the time required to determine the necessity of directory synchronization from minutes to milliseconds by introducing a directory digest hashing mechanism. This is particularly suitable for scenarios in factory production where product catalogs are frequently switched, but are synchronized most of the time. By using a directory digest hash value comparison method, it significantly improves equipment response speed and production efficiency without compromising synchronization accuracy. In step S4, if it is determined by comparing the directory digest hash value that a synchronization operation is needed to synchronize data on the remote server with local data using the burning device, then... Figure 4 As shown, the synchronization operation specifically includes the following steps: a1: Retrieves each data file included in the target directory on the remote server, denoted as: target file; Search the storage module of the burning device for all data files with the same name as the target file. If the file can be found, record it as a local file with the same name, and then proceed to step a2; If not found, it means that the data file is newly added, and the target file will be loaded into the storage module of the burning device; a2: Get the size of the target file and compare the size of a local file with the same name with the size of the target file; If the two are consistent, proceed to step a3; If the two are inconsistent, it means that the file content has been deleted or added. After archiving and saving the local file with the same name and creating a historical version, download the target file and replace the local file with the same name in the storage module. a3: Read the checksum corresponding to the target file, denoted as: target checksum; read the checksum of the local file with the same name in the storage module, denoted as: file with the same name checksum; compare the target checksum with the file with the same name checksum; If the two match, proceed to step a4; If the two are inconsistent, it means that the file content has been modified. Then, the local file with the same name is archived and saved, and a historical version is created. The target file is then downloaded and replaced with the local file with the same name in the storage module. a4: Perform no operations on the target file and terminate the target file synchronization process; a5: Repeat steps a1~a4 to perform the synchronization process on all target files in the target directory on the remote server.

[0037] The burning device archives and saves the old version files that will be replaced, establishing a version history, with the aim of rolling back the data when needed.

[0038] S5: When a user selects a product via the touchscreen, the programming process begins. The main control module reads the programming algorithm file and data file corresponding to the product to be programmed from local storage and sends programming-related commands and data to the multi-channel slave control module via the SPI interface. The programming-related commands and data include: programming instructions, algorithm logic, and data to be programmed.

[0039] S6: The slave control module receives instructions and data from the master control module, drives the programming channels, and performs programming operations on the chips to be programmed connected to each programming channel.

[0040] To improve data exchange efficiency, this application utilizes a combination of SPI and DMA technologies to achieve high-efficiency data transmission. The DMA controller directly manages data exchange between the SPI peripheral and memory, significantly reducing CPU intervention and improving system performance. This approach is particularly suitable for high-speed, high-volume communication scenarios such as audio / video stream processing or sensor data acquisition. Based on the combined SPI and DMA computation, step S6 specifically includes the following steps.

[0041] b1: Two memory regions of the same size are allocated inside the slave control module, denoted as: buffer A and buffer B; Initialize a buffer state manager, which records the state of each buffer; The buffer states include: idle, DMA (Direct Memory Access) receiving, receiving completed and awaiting decryption, decrypting, decrypting completed and awaiting burning, burning, and error; the initial state of each buffer is: idle.

[0042] By setting up a dual buffer, the basis for parallel processing is achieved. By using the two buffers alternately, the continuous data stream processing process is decoupled into independent stages that can be parallelized.

[0043] b2: Before each programming session begins, the slave control module sends a ready signal to the master control module.

[0044] b3: The master control module prepares the first frame of data after receiving the slave control ready signal; A data frame includes: frame header, frame number, data length, ciphertext data, and checksum.

[0045] b4: The master control module transmits data to the slave control module via SPI; The slave module sets the state of buffer A to "DMA receiving" and configures SPI DMA control. It then points the target address pointer to buffer A, and the DMA begins transferring data to buffer A. This process does not require intervention from the slave CPU.

[0046] This application uses Direct Memory Access (DMA) technology for high-speed, background data transfer of SPI, freeing the CPU from heavy data handling work and enabling it to perform decryption calculations simultaneously.

[0047] b5: After the slave DMA finishes filling buffer A with data (triggers a transmission completion interrupt), the state of buffer A is changed to: reception complete, awaiting decryption; at the same time, the slave module sends a ready signal to the master module.

[0048] b6: After receiving the ready signal from the slave module, the master control module determines whether the data transmission for this programming is complete; If the data transmission is complete, the master controller will not perform any operation and will execute step b17; If data transmission is not complete, send the next frame of data and proceed to step b7.

[0049] b7: The slave module sets the state of buffer B to DMA receiving and configures the DMA to point the target address pointer of the next frame of data to buffer B; the slave DMA starts to move the data from the master module to buffer B in the background. At the same time, the CPU of the slave module starts to decrypt buffer A, which is in the state of receiving and waiting to be decrypted. The state of buffer A changes to decrypting. Decryption is performed while master control data is received in the background. Decryption and receiving are completely overlapped in time. At this time, A decrypts and B receives.

[0050] b8: When the decryption of buffer A is completed, its status is changed to decryption complete and ready for programming; the programming controller of the slave module starts to program the plaintext data in buffer A to the chip to be programmed, and changes the status of buffer A to programming. Simultaneously with the operation of buffer A, once the slave DMA has moved all the data for this operation to buffer B, the state of buffer B is changed to "reception complete, awaiting decryption".

[0051] b9: After buffer A is burned, the state of buffer A is reset to idle; the idle buffer is reused by DMA for subsequent data frames; at the same time as the state of buffer A is reset to idle, the slave controller sends a ready signal to the master controller.

[0052] b10: After receiving the slave ready signal, the master control module determines whether the data transmission for this programming is complete; If the data transmission is complete, the master controller will not perform any operation and will execute step b17; If data transmission is not complete, send the next frame of data and execute step b11.

[0053] b11: The slave control module sets the state of buffer A to DMA receiving and configures SPI DMA control, pointing the receive target address pointer to buffer A. DMA begins transferring data to buffer A in the background. Simultaneously, decryption and reception of master control data occur in the background, achieving complete overlap in timing. Simultaneously with the operation on buffer A, the slave control CPU begins decryption operations on buffer B, which is in the state of receiving complete and awaiting decryption. Buffer B's state changes to decryption in progress. At this point, A receives, B decrypts.

[0054] b12: When the decryption of buffer B is completed, its status changes to decryption complete and ready for programming; the programming controller of the slave module starts to program the plaintext data in buffer B to the target chip, and changes the status of buffer B to programming in progress. Simultaneously with the operation in buffer B, the DMA has already moved the data to buffer A, and the state of buffer A changes to "received complete, awaiting decryption".

[0055] b13: When buffer B is burned, its state is reset to idle, and the idle buffer is reused by DMA for subsequent data frames; at the same time that the state of buffer B becomes idle, the slave control module sends a ready signal to the master control module.

[0056] b14: ​​After receiving the slave ready signal, the master control module determines whether the data transmission for this programming is complete; If the data transmission is complete, the master controller will not perform any operation and will execute step b17; If data transmission is not complete, send the next frame of data and execute b15.

[0057] b15: The slave control module sets the state of buffer B to DMA receiving and configures SPI DMA control, pointing the receive target address pointer to buffer B. DMA begins transferring data to buffer B in the background. At this time, the slave CPU begins decryption operations on buffer A, which is in the state of receiving completed and awaiting decryption. The state of buffer A changes to decryption in progress. Simultaneously, decryption and receiving receive master control data in the background, achieving complete overlap in timing. In this scenario: A decrypts, B receives.

[0058] b16: Repeat steps b8 to b15.

[0059] b17: The controller determines the status of the two buffers, finds the buffer whose status is "received complete and awaiting decryption", names it buffer X; performs decryption operation on buffer X, and changes the status of buffer X to "decrypting".

[0060] b18: After buffer X is decrypted, the plaintext data in buffer X is burned to the target chip and its status is changed to burning; after buffer X is burned, its status is reset to idle, and the idle buffer is reused by DMA for subsequent data frames.

[0061] This burning process is now complete.

[0062] In the programming system of this application, a master-slave distributed architecture is used. The programming data is stored in encrypted form in the local storage module and transmitted to the slave module in encrypted form via the SPI bus. At the start of programming, the slave module needs to run a decryption algorithm to restore the programming data to plaintext. Due to the low performance of the slave module, the decryption process is time-consuming, affecting the overall programming efficiency. This "receive-decrypt-program" processing method means that the slave module must completely receive a frame of encrypted data and complete all decryption before programming can begin. During this period, the SPI bus remains idle, resulting in low resource utilization. To improve the overall system execution efficiency of this application, this method introduces a double-buffer mechanism, combined with direct memory access (DMA) transmission, to split the three main operations—data reception, decryption calculation, and data programming—from serial tasks into multiple overlapping sub-stages (reception, decryption, and programming). This reduces the overall system time from the sum of the three stages to the time of the longest stage, significantly improving system throughput and the utilization of hardware resources: CPU, bus, and peripherals.

[0063] S7: The slave control module feeds back the real-time burning status of each channel to the main control module of the system in real time until the burning process is completed.

[0064] At key stages such as synchronization completion, start of burning, and successful / failed burning, the burning device reports status information (such as selected product model, synchronization result, number of burns, and error codes) to the server via a wireless communication module for centralized monitoring. This application's solution also supports rollback, using the latest synchronized resources for burning. If burning of a new version file fails consecutively, the system can automatically or manually trigger a rollback mechanism to load the previous stable version of the file for burning, ensuring production continuity.

[0065] like Figure 5 As shown, the user initiates the programming process via the touchscreen. The device's main control module reads the programming algorithm file firware.bin and data file data.bin from the locally stored / productA / directory. It then sends a programming data packet to the slave control module via the SPI interface. This data packet contains: the target channel mask (e.g., 0x3FF indicates all 10 channels are enabled), the programming algorithm file, and the programming data file. Upon receiving the data packet, the slave control module performs programming steps such as connection, erasure, coding, and verification on the chips of the 10 channels in parallel. Next, it sends the programming result of each channel back to the main control module via the SPI communication interface. The main control module receives the feedback, updates the visual status of the corresponding channel on the touchscreen (e.g., green for success, red for failure), and accumulates the number of programming attempts. Finally, the main control module reports the programming results to the server via the wireless communication module. Engineers can view the results at any time through the management client.

[0066] Through the aforementioned hardware and software co-design, this application achieves end-to-end optimization from data management to efficient execution, forming a complete, advanced, and efficient programming solution. Assume a company has one production line each in City A and City B, 2000 kilometers apart, and deploys a total of 50 intelligent programming devices according to this invention. An engineer at any location can upload the Product_C data package to the company's cloud server from their office computer. The entire process takes only a few minutes, requiring no business trips or coordination of on-site personnel. Global automatic updates: The 50 devices in the City B factory automatically connect to the server upon the next startup or scheduled task, autonomously discovering and downloading the Product_C data.

[0067] By employing the technical solution of this invention, a distributed architecture of "system master control + dedicated programming slave control" is adopted, decoupling complex logic such as communication management, user interaction, and data synchronization from high real-time programming control. The system master control can focus on high-level management tasks, while the programming slave control specializes in precise timing control, making the system operation more stable and efficient. Chip data files can be modified and globally updated anytime, anywhere. Engineers can achieve global device data synchronization at the minute level without going to the workshop, realizing centralized management of "one person operates, global effect," which is particularly suitable for modern manufacturing enterprises with multiple production lines, multiple factories, or even global layouts, improving management efficiency by several orders of magnitude. A single programming device can achieve the output previously required by multiple devices, saving equipment procurement costs, space occupation, and production line management complexity. By adopting a multi-channel parallel programming architecture, the programming efficiency of a single programming device can be improved by several times or even ten times compared to traditional single-channel devices, greatly reducing the programming cost and time per unit chip. Multiple comparisons and verifications ensure accurate synchronization of data file content; the version rollback mechanism provides a safety cushion for production, greatly reducing the risk of downtime due to data issues.

Claims

1. A multi-chip programming system based on wireless synchronization and data management, characterized in that, It includes: a remote server and a burning device, wherein the remote server and the burning device are connected in communication; The remote server stores the programming data files for all models of chip products and provides file access services; The human-computer interaction module is connected to the main control module and is used to receive user commands and display device status; The programming device includes: a master control module, a slave control module, a communication module, a storage module, and a human-computer interaction module; The main control module is implemented based on a SoC chip and serves as the core management unit of the device, responsible for user interaction, network communication, data synchronization, and task scheduling. The main control module downloads the file to be burned from the remote server and stores it in the storage module. The main control module establishes a communication connection with the remote server based on the communication module. The communication module supports both wireless and wired communication. The master control module and the slave control module are connected based on a communication interface; The slave control module is based on a microcontroller with IO interface resources as its core module and is responsible for executing the programming algorithm; the number of IO interfaces is greater than 1; the programming device is installed on the production line and connects to the chip to be programmed through the IO interface of the slave control module as a programming channel.

2. The multi-chip programming system based on wireless synchronization and data management according to claim 1, characterized in that: The main control module is implemented based on T113 or RK3566, and the slave control module is implemented based on STM32F407 chip.

3. A multi-chip programming method based on wireless synchronization and data management, characterized in that, It includes the following steps: S1: Store the programming data files of all chip products according to the product catalog on a remote server; When storing data, each data file also stores the corresponding checksum. The files in each product directory on the remote server are kept to be the latest version. S2: After the programming device is powered on, it sends a connection request to the remote server; The remote server performs two-way encrypted authentication with the burning device that sent the request, and establishes a secure data channel with the burning device after successful authentication. S3: After successful authentication, the burning device requests the file directory list on the remote server and compares it with the local file directory list; If the two are inconsistent, update the local file directory list to make the local file directory list consistent with the version of the file directory list on the remote server. S4: During the burning process, the target product catalog to be burned is specified based on the local file directory list; Once the target directory is selected, the main control module of the burning device obtains the names and sizes of all data files in the target directory on the remote server and synchronizes the data on the remote server with the local data; S5: Entering the programming process; the main control module reads the programming algorithm file and data file corresponding to the product to be programmed from local storage, and sends programming-related commands and data to the slave control module through the SPI interface; S6: The slave control module receives instructions and data from the master control module, drives the programming channels, and performs programming operations on the chips to be programmed connected to each programming channel. S7: The slave control module feeds back the real-time burning status of each channel to the main control module of the system in real time until the burning process is completed.

4. The multi-chip programming method based on wireless synchronization and data management according to claim 3, characterized in that: In step S4, when the burning device synchronizes the data on the remote server with the local data, it specifically includes the following steps: a1: Retrieves each data file included in the target directory on the remote server, denoted as: target file; Search the storage module of the burning device for all data files with the same name as the target file. If the file can be found, record it as a local file with the same name, and then proceed to step a2; If not found, the target file will be loaded into the storage module of the burning device; a2: Obtain the size of the target file and compare the size of the local file with the same name with the size of the target file; If the two are consistent, proceed to step a3; If the two are inconsistent, after archiving and saving the local file with the same name and creating a historical version, download the target file and replace the local file with the same name in the storage module; a3: Read the verification value corresponding to the target file, denoted as: target verification value; read the verification value of the local file with the same name in the storage module, denoted as: file with the same name verification value; compare the target verification value and the file with the same name verification value; If the two match, proceed to step a4; If the two are inconsistent, the local file with the same name will be archived and saved, and a historical version will be created. Then, the target file will be downloaded and replaced with the local file with the same name in the storage module. a4: Perform no operation on the target file and terminate the synchronization process of the target file; a5: Repeat steps a1~a4 to perform the synchronization process on all target files in the target directory on the remote server.

5. The multi-chip programming method based on wireless synchronization and data management according to claim 3, characterized in that: Step S6 specifically includes the following steps: b1: Two memory regions of the same size are allocated inside the slave control module, denoted as: buffer A and buffer B; Initialize a buffer state manager, which records the state of each buffer; The buffer status includes: idle, DMA receiving, receiving completed and awaiting decryption, decrypting, decrypting completed and awaiting burning, burning, and error; The initial state of each buffer is: idle; b2: Before each programming session begins, the slave control module sends a ready signal to the master control module; b3: The master control module prepares the first frame of data after receiving the slave control ready signal; A data frame includes: a frame header, a frame number, a data length, ciphertext data, and a checksum; b4: The master control module transmits data to the slave control module via SPI; The slave control module sets the state of buffer A to "DMA receiving" and configures SPI DMA control, points the receiving target address pointer to buffer A, and the DMA starts transferring data to buffer A; b5: After the slave DMA finishes filling buffer A with data, the state of buffer A is changed to: reception complete, awaiting decryption; at the same time, the slave module sends a ready signal to the master module. b6: After receiving the ready signal from the slave module, the master control module determines whether the data transmission for this programming is complete; If the data transmission is complete, the master controller will not perform any operation and will execute step b17; If data transmission is not completed, send the next frame of data and proceed to step b7; b7: The slave module sets the state of buffer B to DMA receiving and configures the DMA to point the target address pointer of the next frame of data to buffer B; the slave DMA starts to move the data from the slave module to buffer B in the background. At the same time, the CPU of the slave module starts to perform decryption operation on buffer A, which is in the state of receiving completed and waiting to be decrypted. The state of buffer A changes to decryption. b8: When the decryption of buffer A is completed, its status is changed to decryption complete and ready for programming; the programming controller of the slave module starts to program the plaintext data in buffer A to the chip to be programmed, and changes the status of buffer A to programming. Simultaneously with the operation of buffer A, after the slave DMA has moved all the data for this time to buffer B, the state of buffer B is changed to receive complete and awaiting decryption; b9: After buffer A is programmed, the state of buffer A is reset to idle; the idle buffer is reused by DMA for subsequent data frames; at the same time as the state of buffer A is reset to idle, the slave controller sends a ready signal to the master controller. b10: After receiving the slave ready signal, the master control module determines whether the data transmission for this programming is complete; If the data transmission is complete, the master controller will not perform any operation and will execute step b17; If data transmission is not completed, send the next frame of data and execute step b11; b11: The slave control module sets the state of buffer A to DMA receiving and configures SPI DMA control, points the receiving target address pointer to buffer A, and the DMA starts transferring data to buffer A in the background; Simultaneously with the operation of buffer A, the slave CPU begins the decryption operation on buffer B, which is in the state of receiving completed and awaiting decryption, and the state of buffer B changes to decryption in progress; b12: When the decryption of buffer B is completed, its status changes to decryption complete and ready for programming; the programming controller of the slave module starts to program the plaintext data in buffer B to the target chip, and changes the status of buffer B to programming in progress. Simultaneously with the operation in buffer B, the DMA has already moved the data to buffer A, and the state of buffer A changes to "received and awaiting decryption". b13: When buffer B is burned, its state is reset to idle, and the idle buffer is reused by DMA for subsequent data frames; at the same time that the state of buffer B becomes idle, the slave control module sends a ready signal to the master control module. b14: ​​After receiving the slave ready signal, the master control module determines whether the data transmission for this programming is complete; If the data transmission is complete, the master controller will not perform any operation and will execute step b17; If data transmission is not complete, send the next frame of data and execute b15; b15: The slave control module sets the state of buffer B to DMA receiving and configures SPI DMA control. It points the receiving target address pointer to buffer B, and the DMA starts transferring data to buffer B in the background. At this time, the slave control CPU starts decrypting buffer A, which is in the state of receiving completed and waiting to be decrypted. The state of buffer A changes to decrypting. b16: Repeat steps b8~b15; b17: The controller determines the status of the two buffers, finds the buffer whose status is "received complete and awaiting decryption", names it buffer X; performs decryption operation on buffer X, and changes the status of buffer X to "decrypting". b18: After buffer X is decrypted, the plaintext data in buffer X is burned to the target chip and its status is changed to burning; after buffer X is burned, its status is reset to idle and the idle buffer is reused by DMA for subsequent data frames. This burning process is now complete.

6. The multi-chip programming method based on wireless synchronization and data management according to claim 3, characterized in that: The verification value includes either a CRC checksum or a hash value.

7. The multi-chip programming method based on wireless synchronization and data management according to claim 3, characterized in that: In step S1, when the programming data files of all chip products of all models are stored on the remote server according to the product catalog, the remote server also saves the catalog digest hash value for all files in the product catalog of each chip product model. The method for generating the directory digest hash value includes the following steps: c1: Read all data files in the target directory and obtain the file metadata set for each data file; The file metadata set includes: the filenames of all files in the directory, the size of each file, and the last modification time of each file; c2: Sort all files alphabetically by filename; c3: For the sorted file list, retrieve the files one by one in reverse order, denoted as: files to be processed; perform the following processing on the files to be processed: Convert the filename to a UTF-8 byte sequence; Convert the file size into an 8-byte sequence; Convert the last modification time of the file to be processed into an 8-byte sequence; c4: Concatenate the three-byte sequence corresponding to the file to be processed in the order of filename, file size and modification time, and record it as: file description byte stream; c5: Concatenate the file description byte streams corresponding to all data files in the target directory according to the file name order to form a complete description byte stream of the target directory; c6: Calculate the SHA256 hash value for the complete description byte stream of the target directory to obtain the directory digest hash value; c7: Whenever any file included in a product catalog changes, execute steps c1 to c6 in a loop to update the catalog digest hash value corresponding to the product catalog.

8. The multi-chip programming method based on wireless synchronization and data management according to claim 7, characterized in that: In step S4, before the programming device synchronizes the data on the remote server with the local data, it first performs the following steps: d1: For the target directory, the main control module of the burning device sends a directory summary request to the remote server; d2: Upon receiving the request, the remote server queries the database to obtain the latest directory digest hash value corresponding to the target directory and sends it to the burning device; d3: The main control module compares the directory digest hash value of the server with the directory digest hash value stored in the burning device; If the digest hash values ​​of the two directories are inconsistent or there is no digest hash value locally, the latest digest hash value is stored in the local index and d4 is executed; If the hash values ​​of the two directory digests are the same, then execute d5; d4: The burning device in step S4 performs the operation of synchronizing the data on the remote server with the local data; d5: Skip the operation of synchronizing data on the remote server with local data performed by the burning device in step S4, and directly execute step S5.

Images