GW5 camera firmware burning device and method

Abstract

The embodiment of the invention provides a GW5 camera firmware burning device and method, and belongs to the technical field of burning control. The device comprises an equipment identification module used for acquiring equipment identification information and current firmware version information of a target GW5 camera; the firmware processing module is used for analyzing the mirror image content of the firmware mirror image file, performing version and hash comparison on each partition data block based on the current firmware version information, and determining a data block boundary needing to be updated; the burning execution module is used for generating a burning instruction according to the boundary of the data block and writing the data block to be updated into the target GW5 camera through the PCIE interface; and the verification module is used for verifying the written data block after the writing operation is completed, and triggering the rollback operation to recover to the snapshot state before burning when the verification fails. Equipment identification automation and efficient and reliable control over the firmware updating process are achieved, and the burning stability and execution efficiency suitable for the multi-equipment and multi-version firmware environment are remarkably improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of burning control, in particular to a GW5 camera firmware burning device and a GW5 camera firmware burning method. BACKGROUND

[0002] With the wide application of industrial cameras in intelligent manufacturing, vehicle-mounted perception, machine vision and other scenes, as a key production configuration link, the efficiency and reliability of firmware burning directly affect the product delivery cycle and on-site debugging cost. The commonly used firmware burning tools on the market are mostly based on general burners or general command line tools provided by SoC manufacturers, which have a series of problems in actual application.

[0003] The existing burning tools usually require the operator to manually switch the device working mode or preset the device address, and cannot automatically identify the hardware version and firmware state of the connected device, which leads to errors in burning configuration in the scene where multiple models or batches of devices coexist, high cost of manual intervention, and it is difficult to find errors in time, and in severe cases, it may even cause device damage or batch failure.

[0004] Most current tools use the whole image rewriting method for firmware update, lack of partition or data block level comparison and judgment mechanism, and need to rewrite all the contents completely each time. This method not only wastes time, but also increases the writing burden of the device Flash, affecting the service life of the device; at the same time, in the scene of frequent iterative update or online repair, due to the lack of version check and content difference identification, it is impossible to selectively update as needed, which is low in efficiency and high in risk.

[0005] In summary, the existing intelligent camera firmware burning technology still has obvious deficiencies in device automatic identification capability, partition level incremental writing capability and high reliable batch adaptation capability, and a new type of firmware burning method suitable for multiple models, fine control, high adaptability and high security is needed to improve. SUMMARY

[0006] The purpose of the embodiments of the present application is to provide a GW5 camera firmware burning device and method to at least solve the problems of insufficient device identification automation and low efficiency of firmware update process of the existing burning tools.

[0007] In order to achieve the above-mentioned purpose, the first aspect of the present application provides a GW5 camera firmware burning device, which comprises:

[0008] A device identification module is configured to obtain device identification information and current firmware version information of a target GW5 camera through a PCIE interface connected with the target GW5 camera;

[0009] The firmware processing module is in signal connection with the device identification module, configured to receive a firmware image file to be burned, analyze image content of the firmware image file, and perform version and hash comparison on each partition data block based on current firmware version information to determine a data block boundary to be updated.

[0010] The burning execution module is in signal connection with the firmware processing module, configured to generate a burning instruction according to the data block boundary, and write the data block to be updated into a target GW5 camera through a PCIE interface.

[0011] The verification module is in signal connection with the burning execution module, configured to verify the written data block after the writing operation is completed, and trigger a rollback operation to restore to a snapshot state before burning when the verification fails.

[0012] Optionally, the device identification module is further configured with a JTAG auxiliary identification submodule when obtaining the device identification information and the firmware version information through the PCIE interface.

[0013] When it is detected that the PCIE link is unstable or identification fails, the JTAG auxiliary identification submodule accesses a target GW5 camera bottom layer register through a JTAG interface to read a key identification field and assist device confirmation.

[0014] Optionally, the firmware processing module comprises:

[0015] An unpacking processing submodule and a disturbance loading submodule.

[0016] The unpacking processing submodule is configured to perform decryption and reconstruction operations on the encrypted and differentially compressed firmware image file.

[0017] The disturbance loading submodule is configured to perform random disturbance configuration on a data block loading sequence after image reconstruction to prevent physical layer attacks caused by fixed image layout.

[0018] Optionally, the burning execution module comprises:

[0019] A snapshot management submodule and a writing calibration submodule.

[0020] The snapshot management submodule is configured to obtain complete state information of all partitions to be updated in the target GW5 camera before the burning operation and generate a rollback snapshot.

[0021] The writing calibration submodule is configured to dynamically adjust a burning level, a current peak value and a timing interval according to a target camera Flash characteristic to ensure burning stability and writing consistency.

[0022] Optionally, the verification module is configured to:

[0023] The corresponding partition index, check result, firmware version, burning time and device identification information are written into the non-volatile storage area of the target GW5 camera for querying the burning history, fault tracing and version management.

[0024] Optionally, the device further comprises:

[0025] A multi-device scheduling module;

[0026] The multi-device scheduling module is configured to dynamically allocate the burning task priority and concurrent timing according to the initialization state, connection delay, burning channel occupation and Flash health degree prediction index of each device in the case that multiple target GW5 cameras are connected to the same PC end.

[0027] Optionally, the multi-device scheduling module comprises:

[0028] A light-weight strategy model submodule;

[0029] The light-weight strategy model submodule constructs a device response model and a failure probability model based on historical burning data; wherein,

[0030] The device response model is used to represent the response time and execution delay characteristics of each target GW5 camera in different burning stages, so as to identify devices with poor response performance;

[0031] The failure probability model is used to predict the potential failure risk of the current burning task based on the historical failure number, error type and firmware version label, and accordingly adjust the scheduling burning order and task allocation strategy.

[0032] The second aspect of the application provides a GW5 camera firmware burning method, which is realized based on the GW5 camera firmware burning device described above, and the method comprises:

[0033] The device identification module establishes a PCIE connection with the target GW5 camera, and obtains the device identification information and the current firmware version information of the target GW5 camera;

[0034] The firmware image file to be burned is input into the firmware processing module, the image content in the firmware image file is parsed, and version and hash comparison is performed on each partition data block based on the current firmware version information, so as to determine the data block boundary that needs to be updated;

[0035] The burning instruction is generated according to the data block boundary, and the data block to be updated is written into the target GW5 camera through the burning execution module;

[0036] After the data block is written, a verification module is called to perform consistency verification on the written data block, and if the verification fails, a rollback operation is performed to restore the firmware state of the target GW5 camera to the snapshot state before burning.

[0037] Optionally, in the process of establishing a PCIE connection with the target GW5 camera through the device identification module, obtaining the device identification information and the current firmware version information of the target GW5 camera, the method further comprises:

[0038] If the PCIE connection state is detected to be abnormal or failed to be obtained, a JTAG auxiliary identification path is called to establish a JTAG debugging channel with the target GW5 camera, and chip number, hardware version and firmware configuration segment data related to device identification are obtained by accessing internal registers of the target GW5 camera as a substitute source for the device identification information and the current firmware version information;

[0039] The JTAG identification process has an automatic switching judgment condition for preferentially ensuring the integrity of the key field.

[0040] Optionally, in the process of writing the data block to be updated into the target GW5 camera through the burning execution module, the method further comprises:

[0041] A device response model and a failure probability model pre-constructed in the lightweight strategy model module are called; wherein,

[0042] The device response model is used to predict the response delay and execution stability of the current target GW5 camera in the burning process, and the failure probability model is used to predict the failure risk level of this burning operation according to historical error records and the current firmware version;

[0043] When any model output does not meet the preset success criterion, the writing rate is reduced, the amount of concurrent instructions is limited, or the burning task sequence is adjusted.

[0044] Through the above technical solutions, the device identification module automatically obtains the device identification information and the current firmware version information of the target GW5 camera, avoiding the problem of manual configuration and identification error; the firmware processing module performs partition-level comparison on the image content, accurately identifies the boundary of the data block to be updated, avoids rewriting the entire image, improves the update efficiency and reduces the Flash writing burden; the burning execution module performs on-demand writing based on the comparison result, further compressing the burning time; the verification module performs consistency verification on the written content, and triggers a rollback operation when the verification fails, improving the safety and fault tolerance of the burning process. Overall, the device identification automation and efficient and reliable control of the firmware update process are realized, and the burning stability and execution efficiency in the environment of multiple devices and multiple versions of firmware are significantly improved.

[0045] Other features and advantages of the present application will be explained in the following detailed description of embodiments. BRIEF DESCRIPTION OF DRAWINGS

[0046] The accompanying drawings are included to provide a further understanding of embodiments of the application and are incorporated in and constitute a part of this specification, illustrate embodiments of the application and serve to explain the principles of the application, but are not intended to limit the application. In the drawings:

[0047] Figure 1 is a device structure diagram of a GW5 camera firmware burning device provided by an embodiment of the application;

[0048] Figure 2 is a GW5 camera PCIe firmware burning flowchart provided by an embodiment of the application;

[0049] Figure 3 is a step flowchart of a GW5 camera firmware burning method provided by an embodiment of the application. DETAILED DESCRIPTION

[0050] The specific embodiments of the application will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely intended to illustrate and explain the application, and are not intended to limit the application.

[0051] Figure 1 is a device structure diagram of a GW5 camera firmware burning device provided by an embodiment of the application. As shown in Figure 1 The device includes a device identification module for obtaining device identification information and current firmware version information of a target GW5 camera through a PCIE interface connected to the target GW5 camera; a firmware processing module connected to the device identification module for receiving a firmware image file to be burned, analyzing the image content of the firmware image file, and performing version and hash comparison on each partition data block based on the current firmware version information to determine the data block boundary that needs to be updated; a burning execution module connected to the firmware processing module for generating a burning instruction according to the data block boundary and writing the data block to be updated into the target GW5 camera through the PCIE interface; and a verification module connected to the burning execution module for verifying the written data block after the writing operation is completed and triggering a rollback operation to restore to a snapshot state before burning when the verification fails.

[0052] In the embodiments of the present application, the GW5 camera firmware burning device is provided, which is designed for the firmware updating needs of industrial cameras in mass production, debugging, version iteration and other scenarios, and builds an execution framework with device identification, image analysis, on-demand writing and consistency verification as the core. The device is provided with a device identification module, which can automatically read the unique identification information and the current firmware version number of the device after establishing a connection with the target GW5 camera through the PCIE interface, so as to realize the rapid identification of the device model and the firmware state and provide accurate basis for subsequent firmware matching. This module can avoid manual judgment and configuration errors, and improve the firmware processing module responsible for receiving and analyzing the target image file after identification is completed. This module not only extracts the logical partition structure of the firmware, but also combines the current firmware version to perform differential comparison based on the version number and hash value, which is used to locate the data block boundary that needs to be updated. This partition-level difference analysis mechanism effectively avoids the writing redundancy and Flash resource waste problems caused by the traditional whole-image rewriting method, and is particularly suitable for frequent iteration or multi-version deployment environment.

[0053] After completing the update range confirmation, the burning execution module generates accurate burning instruction set according to the data block boundary, and performs data block-level writing operation on the target GW5 camera through the PCIE channel. This writing process can update the different partition content, significantly improve the burning efficiency, and reduce the damage to the Flash life. In addition, the verification module immediately performs consistency verification operation on the written data block after writing is completed, including comparing the hash value of the written data with the original image, performing version signature verification, etc. If the verification fails, the built-in rollback mechanism is triggered to automatically restore to the firmware snapshot state generated before burning, so as to protect the data integrity and device recoverability.

[0054] Overall, the device realizes the closed-loop process from automatic identification, intelligent judgment to precise writing and rollback protection through modular division and data-driven execution path, which can significantly improve the efficiency, reliability and batch adaptation capability of the GW5 camera firmware burning process without increasing additional manual operation. The automation level in batch processing.

[0055] Preferably, the device identification module is configured with a JTAG auxiliary identification sub-module while obtaining the device identification information and firmware version information through the PCIE interface; when it is detected that the PCIE link is unstable or the identification fails, the JTAG auxiliary identification sub-module accesses the target GW5 camera bottom register through the JTAG interface to read the key identification field and assist the device confirmation.

[0056] In the embodiments of the present application, the PCIE link initialization channel is established, the EEPROM or register group mapped out by the camera side Bootloader stage is read, and the device identification information (such as product model, hardware version, channel number, etc.) and current firmware version information contained therein are parsed. The identification process preferentially uses the high-speed PCIE channel for data interaction, ensuring that fast initialization and automated identification are achieved under normal communication conditions, thereby reducing manual intervention steps and improving response efficiency during batch deployment.

[0057] Considering that in actual engineering environment, there may be PCIE link instability, camera end power-on abnormality or Boot stage configuration error, etc., resulting in the device failing to return legal identification information within the expected time window, a JTAG auxiliary identification submodule is integrated in the device identification module as a fault-tolerant path supplement. When any of the identification failure criteria is triggered, such as PCIE link handshake failure, frame synchronization abnormality, read instruction response timeout or missing return information field, the JTAG auxiliary channel is started.

[0058] The JTAG auxiliary identification submodule is connected to the JTAG pin of the target GW5 camera through the introduced debug interface, performs boundary scan operation according to IEEE 1149.1 standard, and directly accesses the chip-level register group without relying on the main communication protocol. In the identification process, the access sequence needs to be constructed according to the JTAG link description file (such as SVF or XSVF) of the target camera chip platform (such as GW5300 series SoC), and the field data for identity identification in a specific address range is scanned bit by bit. Usually, these fields include but are not limited to chip ID, embedded Fuse bit, write protection identification, startup configuration segment information, etc., which are used to determine the device model, factory configuration and current firmware version when the PCIE link is unavailable.

[0059] To improve the JTAG access efficiency and stability, it is recommended to use a JTAG adapter with buffer impedance matching in the design, and control the TCK frequency not to exceed the maximum scan frequency supported by the target platform. In the identification process, the device identification structure area stored in the low address segment is preferentially read, and a timeout protection mechanism is set to avoid JTAG link blockage or deadlock. After successful scanning, the identification result is transmitted into the main identification module through the backfill mechanism, so that the subsequent firmware comparison and burning process can continue.

[0060] By introducing the JTAG auxiliary path in the device identification stage, not only the robustness of the overall identification process is enhanced, but also a reliable identification alternative means is provided for devices with communication abnormalities, hardware micro-faults or early stage debugging on the production line. This design is particularly suitable for batch burning, engineering testing and after-sales troubleshooting, etc. The application scenarios have high requirements for identification accuracy and continuity. In actual deployment, it has been verified that the auxiliary path can improve the identification success rate by more than 30% under high interference test lines, effectively reducing the cost of manual intervention and identification failure rate.

[0061] In another possible implementation, the device identification module further integrates an auxiliary identification mechanism based on edge current disturbance analysis, which is used to perform device state discrimination and identification confirmation in special scenarios where the PCIE link is abnormal and the JTAG interface is limited or occupied. Specifically, the mechanism collects the transient current waveform of the PCIE power supply channel in real time during the power-on process of the target GW5 camera, extracts characteristic indexes including power-on response delay, initial current peak, stable stage current offset, etc. without directly accessing the data interface, and performs similarity matching between the indexes and the current characteristic template corresponding to the preset device model, to assist in judging whether the access device is a specific model of the target GW5 camera.

[0062] To achieve the above functions, a high-precision Hall current sensor can be integrated in the mainboard or fixture, and its sampling data can be input into the local analysis module. This mechanism does not rely on conventional communication links, and is particularly suitable for abnormal devices with locked interfaces, damaged Flash or entering protection state. Experiments show that more than 70% of the device types can be successfully identified through current disturbance pattern matching while the JTAG interface is occupied and the PCIE handshake fails, significantly improving the identification success rate and production line fault tolerance ability in extreme situations.

[0063] Preferably, the firmware processing module includes an unpacking processing submodule and a disturbance loading submodule; the unpacking processing submodule is used to perform decryption and reconstruction operations on the encrypted and differentially compressed firmware image file; and the disturbance loading submodule is used to perform random disturbance configuration on the data block loading sequence after image reconstruction, to prevent physical layer attacks caused by fixed image layout.

[0064] In the embodiment of the present application, the firmware processing module is provided with an unpacking processing submodule and a disturbance loading submodule to further improve the security of the firmware loading process and the anti-attack ability of the structural level. The unpacking processing submodule is used to perform preprocessing operations such as decryption, differential reconstruction and integrity verification on the firmware image file after receiving the file. Specifically, the module can support AES-256 symmetric encryption algorithm to decrypt the original firmware content, and after decryption, it combines with the differential index file to perform reconstruction, and reconstructs the complete writable format partition image. The differential reconstruction process needs to be based on the preset partition boundary information and data pointer mapping table to ensure that the reconstruction process of each logical partition does not appear cross-zone writing or address misplacement problem, and at the same time, the hash check is performed on the reconstruction result to confirm the success of the reconstruction and the data consistency.

[0065] The disturbance loading submodule is started after the image reconstruction is completed, and is mainly used to disturb the loading order of the firmware data block in the storage mapping structure. Specifically, the module will determine a disturbance mapping table based on a pseudo-random sequence generator (such as a seed initialized linear congruence algorithm), and adjust the loading sequence of each data block according to the table. The disturbance operation does not change the partition content and structural boundary, but makes the loading position and order of the data block different from the original firmware packaging structure, thereby destroying the inherent image layout rule. The disturbance structure interferes with the static analysis of the attacker based on the fixed address table or the firmware fingerprint feature, and can effectively prevent the image relocation attack or feature matching injection at the physical level.

[0066] After deploying the structure, even if the image file is leaked or externally analyzed, it is difficult to restore the standard image layout from the disturbance structure, making it difficult for attackers to construct targeted malicious patches or fake paragraphs. This mechanism is particularly suitable for camera devices with security boot requirements or intermediate node caching in OTA transmission links, which improves the security of the image while not introducing significant increases in complexity at the write end. In practice, this scheme has been successfully deployed on similar SoC platforms and has good defense performance when facing image replay and decompilation attacks.

[0067] Preferably, the burning execution module includes a snapshot management submodule and a write calibration submodule; the snapshot management submodule is used to obtain the complete state information of all to-be-updated partitions in the target GW5 camera before the burning operation and generate a rollback snapshot; and the write calibration submodule is used to dynamically adjust the burning level, current peak value and timing interval according to the characteristics of the target camera Flash, so as to ensure the burning stability and write consistency.

[0068] In the embodiment of the present application, the burning execution module includes a snapshot management submodule and a write calibration submodule, which are used to perform state backup and write behavior regulation before and after data writing, respectively, to enhance the safety and reliability of the burning process. The function of the snapshot management submodule is to extract the state and read the content of all partitions marked as "to be updated" in the target GW5 camera before formally performing the firmware writing operation, and to construct a complete rollback snapshot data structure based on the extraction result. The snapshot data should include the starting address, data length, original content hash value and actual byte sequence content of each target partition, and additional meta information such as partition version mark and timestamp can be attached if necessary, to facilitate quick positioning of the original state during subsequent rollback execution. The snapshot can be stored in a local cache, an external storage card or a special rollback partition, and the specific configuration should be flexibly set according to the device capacity and burning strategy.

[0069] During the execution of the writing process, if any burning failure, inconsistency, writing interruption or abnormal return state occurs, the snapshot data can be called to perform recovery operation. The recovery mechanism rewrites the snapshot content block by block according to the original partition address mapping, and recovers to the state before burning, to ensure that the device is not trapped in a state of being unable to start or having functional errors after being written with abnormal firmware, and is particularly suitable for production scenes or OTA update scenes that require high consistency and low failure tolerance. This mechanism effectively improves the fault tolerance and overall reliability of the burning process.

[0070] At the same time, in order to ensure the stability of writing under different Flash models, different power supply states or external temperature and humidity environments, the write calibration submodule dynamically controls the burning behavior through a strategy combining pre-setting and self-adaptation. The control behavior includes: detecting the model, page write size, erase block capacity and maximum write current characteristics of the Flash device configured for the current target GW5 camera; loading the corresponding write level reference table according to the device parameters, and dynamically adjusting the instruction rhythm, level waveform amplitude and waiting interval during data writing in combination with the monitored information such as power supply fluctuation, current load curve, response delay, etc. If the system detects that the current environmental temperature exceeds the threshold range, it can also automatically switch to a low-speed writing mode or add a verification interval, thereby reducing the risk of writing failure caused by internal overheating or charge leakage of the Flash.

[0071] Through the cooperative work of the snapshot management submodule and the write calibration submodule, the stability, error recovery capability and cross-device adaptation capability of the firmware writing process can be significantly improved without affecting the execution efficiency of the original burning process, which is particularly suitable for engineering prototype verification, large-scale parallel burning of multiple camera models, and product delivery processes with high requirements for firmware consistency. In practical application, this design has successfully controlled the burning failure recovery rate to below 3%, and effectively reduced the potential damage to the Flash device caused by writing overshoot or high temperature operation.

[0072] Preferably, the verification module is configured to write the corresponding partition index, verification result, firmware version, burning time and device identification information into the non-volatile storage area of the target GW5 camera after completing the verification of all updated data blocks, for querying the burning history, fault tracing and version management.

[0073] In the embodiment of the application, the verification module is configured to perform a post-information solidification operation for recording the key information of the current burning process to the non-volatile storage area of the target GW5 camera after completing the verification process of all updated data blocks, thereby providing data support for subsequent version management, fault tracing and production line quality tracing. Specifically, the writing operation should be based on a fixed format data structure to package the partition index of each updated partition, the data block verification result (including CRC32 or SHA256 hash value), the corresponding firmware version number, the burning completion timestamp and the identification information (such as serial number, hardware version, etc.) of the current device to generate a verification record entry. Each record can be written in time sequence into EEPROM, Flash free area or dedicated verification record area, and it is recommended to be designed as a circular coverage or page storage mechanism to control the occupied space.

[0074] To ensure the reliability and recognizability of the record, it is recommended to assign a frame header identifier and a verification trailer code to each record, and attach a record validity marker to prevent data misplacement or redundant interpretation in subsequent reading process. The record format can be further extended to include fields such as abnormal marker bit in writing process, whether to enable snapshot rollback, burning mode flag (full image / micro upgrade / parallel task ID), etc., for further improving the traceability granularity.

[0075] During deployment, this mechanism allows batch reading and analysis of the above verification records through subsequent maintenance interface or diagnostic channel, for judging whether the current device has performed firmware update of a specific version, whether there is writing abnormality, or whether it is a factory qualified state. This function is particularly suitable for batch device delivery acceptance, positioning of problem devices in after-sales, and firmware update history review of long-running devices. By solidifying the verification results into the device body in a structured form, the dependence on external logs is significantly reduced, the information closed-loop degree and device self-verifiability are improved, which greatly facilitates the version supervision and error backtracking in the production process in engineering practice.

[0076] Preferably, the device further comprises a multi-device scheduling module, which is configured to dynamically allocate the burning task priority and concurrent timing according to the initialization state, connection delay, burning channel occupation and Flash health degree prediction index of each device in the case that multiple target GW5 cameras are connected to the same PC end.

[0077] In the embodiment of the present application, the device further comprises a multi-device scheduling module, which is used to reasonably coordinate the burning sequence and task allocation strategy of each device in the case that multiple target GW5 cameras are connected to the same PC port resource at the same time, so as to improve the overall burning efficiency and reduce the failure rate or abnormal rate caused by resource contention. Specifically, before performing scheduling, first, the initialization state detection is performed on each accessed target GW5 camera, and basic state information such as whether the device is powered on, whether the PCIE link is established, and whether the Boot stage has completed the identification response is collected. For the device that has not completed initialization, it is skipped or delayed in the current scheduling round.

[0078] Further, the communication response time of each device needs to be counted in the detection stage, including the time consumed for establishing a link, the command issuing delay, and the time consumed for returning identification information, and other key timing indicators. The connection delay is input into the scheduling scoring model as a performance characterization factor of the device response. In addition, in order to avoid the burning conflict caused by resource congestion, the task load state of the current PCIE channel should be synchronously collected, including the number of concurrent writing devices, the occupancy rate of each channel, and whether the data backhaul is accumulated, and other information to form a “channel availability factor”.

[0079] In addition, in order to further improve the scheduling stability in complex batch devices, a Flash health degree prediction index can be introduced as a reference parameter for evaluating the short-term writing risk of the device. The index can be constructed based on the information recorded in the historical burning log, such as the number of Flash writing failures, the number of erase-write cycles, and the frequency of error correction code triggering, which is used to determine whether the current device is in a sub-healthy state. If it is predicted that the current device may have unstable risk of burning and writing, it can be preferentially allocated to a low-load channel or arranged as a separate writing round to reduce the overall probability of multi-device concurrent burning failure.

[0080] After the above multi-source parameter collection is completed, the multi-device scheduling module will comprehensively evaluate the device state response capability, the channel resource occupancy state, and the Flash health degree in three dimensions, build a scheduling priority score for each target camera, and combine a dynamic timing allocation strategy to group, sort and task all devices in the current scheduling round. This mechanism supports a variety of strategy combinations such as round-robin scheduling, load-aware scheduling, and priority-first scheduling, allowing flexible adjustment according to the actual scene of the production line. Experiments show that in a typical 16-way concurrent burning scene, compared with the static sequential burning mechanism, the module can reduce the overall average burning completion time by more than 30%, while controlling the number of failure retries at a low level, and has good engineering adaptability and batch deployment value.

[0081] Preferably, the multi-device scheduling module comprises a lightweight policy model submodule; the lightweight policy model submodule constructs a device response model and a failure probability model based on historical burning data; wherein the device response model is used to represent the response time and execution delay characteristics of each target GW5 camera at different burning stages, so as to identify devices with poor response performance; the failure probability model is used to predict the potential failure risk of the current burning task based on the historical failure times, error types and firmware version labels, and to adjust the scheduling burning order and task allocation strategy accordingly.

[0082] In the embodiment of the application, the multi-device scheduling module further comprises a lightweight policy model submodule for performing scheduling optimization based on historical behavior patterns in a large batch of concurrent burning tasks of the plurality of target GW5 cameras. The module realizes behavior estimation of different devices in different operating states by constructing two types of core prediction models, namely a device response model and a failure probability model, and dynamically adjusts the execution order of the burning task and the allocation strategy of the concurrent resources on this basis, thereby effectively reducing the burning failure rate, improving the resource utilization rate and the overall production line throughput capacity without introducing additional hardware overhead.

[0083] Specifically, the device response model is used to quantitatively model the response behavior of the target GW5 camera at each stage in the burning task life cycle. The model takes the response time recorded by the device at each round of burning task as the main input parameter, including but not limited to device initialization response time, identification information return delay, burning command confirmation time, data write start waiting time, write completion confirmation feedback time and other timing characteristics. For each target camera, a feature vector can be constructed according to the mean, variance, maximum / minimum value and other statistical indicators of the response parameters in multiple historical tasks, and the model state is updated through a sliding window method. In combination with a scoring function, if a device continuously exhibits characteristics such as high delay, unstable response or timeout retry in multiple burning stages, it is marked as a “device with poor response performance”, which can be automatically down-weighted in the subsequent scheduling process, the priority is downgraded, or arranged to execute in an independent channel to avoid dragging the overall task execution progress.

[0084] The failure probability model focuses more on burn stability and failure prediction. The model is based on the failure events of each device during historical burn-in, and statistics the total number of failures, specific failure types (such as verification failure, data write exception, write interruption, device drop, etc.), failure location, firmware version number and device hardware version number, and extracts common features related to device status. For example, if a certain type of Flash chip frequently appears data inconsistency in the tail of V1.2.0 version firmware, or a batch of devices is more likely to drop out under high concurrent load, these features will be used as high-weight factors in the construction of the failure probability model, participating in the burn-in failure risk prediction of the current round.

[0085] In practical applications, the lightweight strategy model submodule generates a score value for each device in the current scheduling period by combining the outputs of the above two models. The score value is used to comprehensively reflect the burn-in feasibility, response efficiency and potential failure risk of the device, thereby forming a reasonable basis for task allocation and execution order. The score result can be input into the scheduling priority sorting algorithm, and the aforementioned initialization state, connection delay, Flash health degree and other indicators are considered together as decision factors for dynamic scheduling optimization.

[0086] In order to reduce the complexity of the algorithm and improve the practicability of the model, the strategy model in the present application adopts a lightweight modeling method, which does not rely on large-scale neural networks or deep learning structures, but uses a combination strategy based on rule engine and statistical feature extraction, such as using weighted average score, moving window regression, failure number segmented threshold, etc. to construct a fast converging scoring logic, so as to ensure that the model can run in real time in the embedded scheduling program without causing additional load on the PC end main thread.

[0087] In actual deployment, the lightweight strategy model submodule can significantly improve the stability and efficiency of large-scale parallel burn-in. For example, in a typical 16-target GW5 camera concurrent burn-in scene, by dynamically excluding devices with poor response performance or high failure probability from participating in high-priority concurrent tasks, and scheduling them to independent channels or delayed rounds for execution, the overall burn-in average completion time can be shortened by 15% to 30%, while significantly reducing the failure retry rate in single round tasks.

[0088] In addition, the model has the ability of continuous learning and dynamic updating, and as the historical data continues to accumulate and iterate, it can automatically identify and adaptively parameterize the response and error rules of each device under different versions, different hardware states, different environmental temperature and humidity conditions, forming a self-optimizing scheduling mechanism for specific batches, specific environments or specific firmware versions, further enhancing the expansion ability and cross-project reuse value of the scheme.

[0089] In another possible implementation, multiple physical layer identification signals are fused, including transient power consumption characteristics after the device is powered on, voltage waveform recovery time, and microscopic parameters such as on-board crystal oscillator startup noise, to construct a device state inference model, and dynamically switch the identification path in combination with a weighting rule.

[0090] Specifically, in the identification module initialization stage, first, the priority of multiple identification paths (PCIE main link, JTAG auxiliary, GPIO detection, and power consumption disturbance analysis) is scored, if the high-priority path does not respond, then the power consumption fluctuation curve within the first 200 ms after the device is powered on, the 3.3V voltage recovery time, and the reference model are compared to determine the power supply stability interval in which the current device is located, and the most suitable identification path combination is activated accordingly.

[0091] This mechanism is suitable for some early hardware prototypes in the production line, severe power supply interference scenarios, or situations where standard channel communication cannot be established when some firmware is abnormally powered on. Through this identification path dynamic switching strategy, the identification success rate and the anti-interference ability of the identification stage can be significantly improved, and it is particularly suitable for ensuring that the overall throughput of the identification stage is not slowed down by "individual abnormal devices" in multi-position parallel burning engineering requirements.

[0092] In a possible implementation, as Figure 2 , the first executed step is to start the graphical user interface of the corresponding firmware burning process. The operator connects the target GW5 camera to the image acquisition card, which adopts the PCIe bus standard and is stably connected with the PC host, ensuring that the physical channel for subsequent instruction interaction is unblocked. After confirming the physical connection, the operator opens the burning tool software and enters the device initialization and firmware loading stage. Then, the operator selects the model number of the target camera in the software interface, and the firmware version list matching the model number will be retrieved, and the operator loads the firmware image file to be burned.

[0093] After loading is completed, the operator clicks the "initialize" button to trigger the device identification and connection detection process. The driver program will be called to query the device state in the current PCIe link, if the cam (i.e., the target camera) is detected to have not been connected, the "check cam connection state" branch is jumped to, and the user is prompted by the debug log to re-plug the connection or check the power supply and interface status. If the cam is successfully connected, the initialization success flag is set to True, and the process enters the "cam connected" path.

[0094] After successful connection, the operator needs to input the unique serial number of the current target camera, which is used to bind the device identification information and the burning task record, facilitating subsequent version management and historical tracing. After input is completed, the operator clicks the "burn" button to trigger the firmware writing process. The data block information parsed from the image file will be automatically issued and written through the PCIe interface, and the data block writing operation is performed.

[0095] After the to-be-burned ends, the automatic verification module is executed to compare the hash value of the written data with the original image, if the comparison passes, it is prompted that the burning is successful and enters the "verification" step, to perform additional startup item verification, device information reading or version confirmation operation. After the verification is completed, the whole process enters the "end" node, indicating that the current burning task is completed.

[0096] Figure 3 It is a method flowchart of the GW5 camera firmware burning method provided by an embodiment of the present application. As shown in Figure 3 The embodiment of the present application provides a GW5 camera firmware burning method, which comprises the following steps:

[0097] Step S10: A PCIE connection is established with the target GW5 camera through a device identification module, and device identification information and current firmware version information of the target GW5 camera are obtained.

[0098] Specifically, after the target GW5 camera is powered on, the device identification module initializes the bus handshake process through the PCIE interface, including address allocation, device enumeration and channel establishment and other basic operations. After the initialization is completed, the camera side Boot area or register address space is accessed through a preset identification instruction, and the device identification information stored in the EEPROM or specific identification block is obtained, which can include device model, hardware version, serial number, sensor type and the like; and the current firmware version information stored in the mapping Flash front area or version description block is further read, which is usually a version number string with a time stamp or a partition label set. In order to avoid identification failure in the communication process, preferably, the identification process is provided with a handshake timeout time, a return content format check and a retry mechanism. When the PCIE link is abnormal or the identification instruction returns an error, the system will call the JTAG auxiliary identification path to enter the JTAG scanning process, and the backup device identification field is obtained through boundary scanning or direct reading of registers, so as to guarantee the integrity and robustness of the identification process. After this step is completed, the device identification information and the current firmware version are written into the cache area for subsequent image processing and version comparison module.

[0099] Step S20: The firmware image file to be burned is input into the firmware processing module, the image content in the firmware image file is parsed, and the version and hash comparison of each partition data block is performed based on the current firmware version information, to determine the data block boundary that needs to be updated.

[0100] Specifically, the firmware processing module first reads the target image file in the local or external input path, which can be an image file with an extension of.rom,.img, or a custom format image packaged after encrypted compression. After reading, the image file needs to go through decryption, differential unpacking and header structure analysis in turn, and be restored to the original partition data structure, including the boot guide partition, parameter area, main program partition, image configuration area, etc. After analysis, combined with the current firmware version information of the target GW5 camera obtained in S10, the version field and hash digest of each partition are compared with the version number and digest value of the corresponding partition in the current image. The comparison method can be a dual strategy of field-level version comparison + content-level SHA256 hash comparison, ensuring that the difference is identified based on not only the version identifier, but also the content-level potential update (e.g. the label is not changed but the content is changed). If the version of a certain partition is older or the hash value is inconsistent, the partition is marked as "to be updated", and key parameters such as its data offset address, length and check value in the image are recorded. Finally, the data block boundary index structure is output for subsequent instruction generation and writing module. This structure ensures the accuracy and minimization of the writing range, improves the burning efficiency and reduces the Flash wear.

[0101] Step S30: generating a burning instruction according to the data block boundary, and writing the data block to be updated into the target GW5 camera through a burning execution module.

[0102] Specifically, after determining the data block boundary to be updated, the burning execution module generates a series of write instructions for PCIE transmission according to the address and data length of each to-be-written region. The write instruction contains target Flash start address, data length, partition type, page alignment parameter, etc. The data segment to be written is packaged and loaded into the instruction queue. The instruction generation process needs to be compatible with the writing specification of the Flash chip in the target GW5 camera, such as page write size limit, block erase alignment requirement, level control range, etc. In the actual execution process, each instruction is sent to the target camera end through the PCIE channel in a streaming write manner, and the ACK response and write success code returned during the period are monitored to ensure that the instruction is not interrupted or skipped. To improve the writing stability, it is preferred to call the writing calibration module before instruction execution, and dynamically adjust the writing rate and waveform amplitude according to the current power supply voltage, current loading condition and Flash warning state, to avoid writing failure caused by power supply fluctuation or high temperature. In addition, a snapshot management mechanism is started before writing to cache the original content of all to-be-updated regions and construct a rollback snapshot structure. This snapshot can be quickly called to perform rollback operation when writing exception or subsequent verification fails, ensuring the recoverability of the writing process. After all the to-be-updated data blocks are written, the verification process in the next stage is entered.

[0103] Step S40: After the data block is written, the verification module is called to perform consistency verification on the written data block. If the verification fails, a rollback operation is performed to restore the firmware state of the target GW5 camera to the snapshot state before burning.

[0104] Specifically, after receiving the write completion identifier, the verification module performs an integrity verification operation on each written partition according to the data block boundary structure. Preferably, the verification method is to read the actual data content of the written Flash partition and calculate the CRC32 and SHA256 hash digest, respectively, and compare them with the corresponding values of the original image data. If they match, the verification is considered successful. If they do not match or reading fails, it is considered a verification failure. In order to ensure the atomicity and real-time performance of the verification process, a timeout protection and reading failure retry mechanism can be set for Flash reading to avoid false judgments caused by accidental reading interference. If a partition fails the verification, the rollback snapshot structure generated before writing is immediately called to perform a content-level rewrite recovery operation on the partition. The rollback operation is based on the partition start address, snapshot content, and write control table to recover block by block. During the execution process, the recovery status and recovery timestamp are recorded, and a rollback log can be optionally generated. If the verification still fails after recovery, the current device task can be suspended, an error identifier is output, and manual review is notified. If all partitions pass the verification, the current burn is marked as "successful", and the burn result, partition state, version number, verification value, and device ID information are written to the non-volatile storage area to form a local trace record. Through the above mechanism, not only is the overall verification after writing realized, but also an automatic recovery closed loop under abnormal conditions is constructed to ensure the reliability and data consistency of the firmware update process, which is especially suitable for actual scenarios such as unattended burning or remote operation and maintenance deployment.

[0105] Preferably, in the process of establishing a PCIE connection with the target GW5 camera through the device identification module and obtaining the device identification information and the current firmware version information of the target GW5 camera, the method further comprises: if an abnormal PCIE connection state is detected or acquisition fails, a JTAG auxiliary identification path is called to establish a JTAG debugging channel with the target GW5 camera, and chip number, hardware version, and firmware configuration segment data related to device identification are obtained by accessing internal registers of the target GW5 camera as alternative sources of the device identification information and the current firmware version information; the JTAG identification process has an automatic switching judgment condition that prioritizes the integrity of key fields.

[0106] In the embodiments of the present application, in the process of establishing a PCIE connection with the target GW5 camera by the device identification module to obtain device identification information and current firmware version information, a JTAG auxiliary identification path is further introduced to enhance the fault tolerance and anti-interference performance of the identification stage. This path mainly targets scenarios where the PCIE link is unstable, contact is abnormal, communication handshake fails, or Boot initialization is not completed, etc. By directly accessing the chip's bottom layer registers through the JTAG channel, it realizes forced acquisition of key identification fields, ensuring that the identification capability under device initialization state has redundant backup.

[0107] In actual operation, when the device identification module detects that the PCIE link has not completed initialization handshake within a specified timeout window, or the identification instruction returns invalid information (such as null value, default byte stream, error frame header, etc.) multiple times, the path switching criterion is triggered, and the JTAG auxiliary identification path is automatically called. Based on the pre-defined IEEE 1149.1 protocol interface, this path performs boundary scan operation on the JTAG pin group of the target GW5 camera, and constructs an access sequence corresponding to the chip bottom layer register mapping table. Preferably, the access logic first reads the identification field area in the preset address segment, including the chip number (Chip ID), the hardware version number (usually fixed in the SoC ROM segment), and the initialization parameters or version label in the firmware configuration area. The data bit width, starting address, and mask rules of the above-mentioned fields should be adapted according to the type of the main control chip in the GW5 camera used, and the decoding method and reading period should be set accordingly.

[0108] To ensure the lowest interference and highest identification stability during reading, the JTAG path will perform TCK frequency calibration and input level verification before entering the access flow, ensuring that the signal can still be transmitted stably under the current physical link conditions. At the same time, the access sequence follows the "key field first" principle, i.e. even if an interruption or scan failure occurs during communication, the chip number and firmware major version number fields must be read before exiting to ensure the minimum validity of the identification result. If necessary, the JTAG identification flow can be set with several retry mechanisms or segmented reading modes to deal with single scan failures caused by target device static adsorption, power fluctuations, or unstable IO pull-up.

[0109] Through the above mechanism, even if the PCIE link is completely disabled, the key identity information of the target GW5 camera can still be obtained through the JTAG channel, the automatic fault tolerance replacement of the identification data is realized, the effective version reference is ensured for the subsequent image processing module, and the problem that the whole machine task is terminated or batch burning fails due to the failure of the identification stage is avoided. At the same time, the path has low coupling and non-invasive characteristics, does not depend on the device operating system or the application layer response after power-on, can be directly executed when the early Boot is not loaded, and is suitable for engineering prototype debugging, production line extreme environment verification and custom camera version deployment with known startup abnormal risk. The introduction of the auxiliary path significantly improves the identification success rate in multiple batches of tests, and especially exhibits higher identification stability and engineering practicability in low temperature, high humidity and high electromagnetic interference environments.

[0110] Preferably, in the process of writing the data block to be updated into the target GW5 camera by the burning execution module, the method further comprises: calling the device response model and the failure probability model pre-constructed in the lightweight strategy model module; wherein the device response model is used to predict the response delay and execution stability of the current target GW5 camera in the burning process, and the failure probability model is used to predict the failure risk level of this burning operation according to the historical error record and the current firmware version; when any model output does not satisfy the preset success criterion, the writing rate is reduced, the amount of concurrent instructions is limited, or the burning task sequence is adjusted.

[0111] In the embodiment of the application, in the process of writing the data block to be updated into the target GW5 camera by the burning execution module, in order to further improve the stability and adaptability of the burning execution, the method further comprises: calling the device response model and the failure probability model pre-constructed in the lightweight strategy model module, dynamically predicting the behavior and risk of the target GW5 camera to be executed for writing operation, and adjusting the burning parameters and scheduling strategy of this round according to the prediction.

[0112] Specifically, the device response model is built based on historical interaction data in multiple dimensions to quantify and predict the response delay and stability performance of the target GW5 camera in different stages of firmware burning. The input parameters of the model usually include: PCIE link initialization delay, identification command response time, firmware data reception confirmation time, cycle length between write start and end, statistical frequency of abnormal interruption or return error code, etc. The above parameters can be obtained by structured parsing of the execution log recorded in each burning task, and are updated with time weighting in a fixed window or exponential decay manner, finally forming a response score function that can be predicted for a single device. The core of the device response model is to capture the non-ideal behaviors of the device exposed in real operation, such as slow response, high jitter, uncertain execution, etc. Once the predicted response score of the current device is lower than the preset threshold, it is judged as a potential high-delay device, which is not suitable for arranging into a high-concurrency burning path.

[0113] At the same time, the failure probability model complements the analysis from another dimension, focusing on establishing an evaluation of the failure risk level of this burning operation according to the burning failure records, abnormal termination logs and version adaptation relationship of the device in the historical task. The construction dimensions of the model can include but are not limited to: matching records of firmware version and device hardware version, whether the device has appeared check failure under a specific partition or a specific image format before, whether there is a historical rollback event, flash health degree flag (such as erase count close to threshold), failure rate trend under working temperature, etc. The failure probability model output is a set of labeled classification predictions, such as "low risk", "medium risk" and "high risk" three-level discrimination levels, to facilitate quick decision whether to perform pace optimization on the device before burning.

[0114] After the model prediction result is generated, the method further includes a coping strategy mechanism. When the output result of any model does not meet the preset success criterion (such as response score lower than 0.6 or failure probability evaluation as "high risk"), the system will immediately perform parameter-level adjustment: including reducing the write rate of the current device, prolonging the interval period between write instructions, thereby giving the device more execution reaction buffer time; limiting the amount of concurrent burning instructions, excluding the device from the current high-concurrency channel, and only retaining a single-channel execution path to reduce resource competition; or directly adjusting the burning task order, delaying it to the end of the queue to wait, to prioritize the burning task completion of other high-response, low-risk devices.

[0115] Through the dual judgment mechanism of the device response model and the failure probability model, not only can the potential "high-risk" device be actively identified before the firmware is burned, but also the burning behavior and scheduling strategy can be dynamically corrected without changing the image content and the burning core process, so as to effectively control the failure rate, reduce the number of retries and the occurrence of rollback operation. Experimental data show that after the above-mentioned model is fused, in the large batch burning scene, the overall burning stability can be improved by nearly 20%, and the failure rate of high delay device is reduced by more than 40%. The method is particularly suitable for multi-device heterogeneous deployment scene, multi-version coexistence batch of engineering prototype, and complex applications of joint burning of mixed old and new devices in the production line.

[0116] Those skilled in the art can understand that all or part of the steps of the methods for implementing the above-mentioned embodiments can be completed by programs instructing relevant hardware, the programs are stored in a storage medium, and the programs include a plurality of instructions for causing a single-chip microcomputer, a chip or a processor to execute all or part of the steps of the methods described in various embodiments of the present application. The foregoing storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a magnetic disk or an optical disk and various storage medium capable of storing program codes.

[0117] The optional embodiments of the present application are described in detail above in combination with the drawings, but the embodiments of the present application are not limited to the specific details in the above-mentioned embodiments, and various simple modifications can be made to the technical solutions of the embodiments of the present application within the technical concept of the embodiments of the present application, and these simple modifications all belong to the protection scope of the embodiments of the present application. In addition, it should be noted that various specific technical features described in the above-mentioned specific embodiments can be combined in any appropriate manner without contradiction. In order to avoid unnecessary repetition, various possible combination manners are not described again in the embodiments of the present application.

[0118] In addition, various different embodiments of the present application can also be combined in any manner, as long as it does not deviate from the idea of the embodiments of the present application, and it should also be considered as the disclosed content of the embodiments of the present application.

Claims

1. A firmware burning device for a GW5 camera, characterized in that, The device includes: The device identification module is used to obtain the device identification information and current firmware version information of the target GW5 camera through the PCIe interface connected to the target GW5 camera; The firmware processing module is signal-connected to the device identification module and is used to receive the firmware image file to be burned, parse the image content of the firmware image file, and perform version and hash comparison on each partition data block based on the current firmware version information to determine the boundary of the data block that needs to be updated. The burning execution module is signal-connected to the firmware processing module and is used to generate burning instructions according to the data block boundary and write the data block to be updated into the target GW5 camera through the PCIE interface. The verification module is connected to the programming execution module and is used to verify the written data block after the writing operation is completed, and to trigger a rollback operation to restore the snapshot state before programming if the verification fails.

2. The apparatus according to claim 1, characterized in that, The device identification module, while acquiring device identification information and firmware version information through the PCIE interface, is also equipped with a JTAG-assisted identification submodule. When an unstable PCIE link or identification failure is detected, the JTAG-assisted identification submodule accesses the underlying registers of the target GW5 camera through the JTAG interface to read key identification fields and assist the device in confirmation.

3. The apparatus according to claim 1, characterized in that, The firmware processing module includes: Decapsulation processing submodule and disturbance loading submodule; The decapsulation processing submodule is used to perform decryption and reconstruction operations on the encrypted and differentially compressed firmware image file; The perturbation loading submodule is used to perform random perturbation configuration on the loading order of each data block after image reconstruction, so as to prevent physical layer attacks caused by fixed image layout.

4. The apparatus according to claim 1, characterized in that, The programming execution module includes: Snapshot management submodule and write calibration submodule; The snapshot management submodule is used to obtain complete status information of all partitions to be updated in the target GW5 camera and generate rollback snapshots before the burning operation; The write calibration submodule is used to dynamically adjust the burning level, current peak and timing interval according to the characteristics of the target camera Flash, so as to ensure burning stability and writing consistency.

5. The apparatus according to claim 1, characterized in that, After completing the verification of all updated data blocks, the verification module is configured as follows: The corresponding partition index, verification result, firmware version, burning time, and device identification information are written to the non-volatile storage area of ​​the target GW5 camera for querying burning history, fault tracing, and version management.

6. The apparatus according to claim 1, characterized in that, The device further includes: Multi-device scheduling module; The multi-device scheduling module is configured to dynamically allocate the priority and concurrent timing of burning tasks based on the initialization status, connection latency, burning channel occupancy, and Flash health prediction indicators of each device when multiple target GW5 cameras are connected to the same PC.

7. The apparatus according to claim 6, characterized in that, The multi-device scheduling module includes: Lightweight strategy model submodule; The lightweight strategy model submodule constructs a device response model and a failure probability model based on historical programming data; wherein... The device response model is used to characterize the response time and execution latency characteristics of each target GW5 camera at different burning stages, in order to identify devices with poor response performance; The failure probability model is used to predict the potential failure risk of the current burning task based on the number of historical failures, error types, and firmware version tags, and adjust the scheduling burning order and task allocation strategy accordingly.

8. A method for burning firmware to a GW5 camera, characterized in that, The method is implemented based on the GW5 camera firmware burning device according to any one of claims 1-7, and the method includes: Establish a PCIE connection with the target GW5 camera through the device identification module to obtain the device identification information and current firmware version information of the target GW5 camera; The firmware image file to be burned is input into the firmware processing module, which parses the image content in the firmware image file and performs version and hash comparison on each partition data block based on the current firmware version information to determine the boundary of the data block that needs to be updated. Based on the data block boundary, a burning instruction is generated, and the data block to be updated is written into the target GW5 camera through the burning execution module; After the data block is written, the verification module is called to perform a consistency check on the written data block. If the check fails, a rollback operation is performed to restore the firmware state of the target GW5 camera to the snapshot state before burning.

9. The method according to claim 8, characterized in that, In the process of establishing a PCIe connection with the target GW5 camera through the device identification module and obtaining the device identification information and current firmware version information of the target GW5 camera, the method further includes: If an abnormal PCIE connection status or acquisition failure is detected, the JTAG auxiliary identification path is invoked to establish a JTAG debugging channel with the target GW5 camera. The chip number, hardware version, and firmware configuration segment data related to device identification are obtained by accessing the internal registers of the target GW5 camera, which serve as alternative sources for the device identification information and the current firmware version information. The JTAG recognition process has an automatic switching judgment condition that prioritizes the integrity of key fields.

10. The method according to claim 8, characterized in that, The method further includes the following steps during the process of writing the data block to be updated into the target GW5 camera via the programming execution module: The device response model and failure probability model pre-built in the lightweight strategy model module are invoked; wherein... The device response model is used to predict the response latency and execution stability of the current target GW5 camera during the burning process, and the failure probability model is used to predict the failure risk level of this burning operation based on historical error records and the current firmware version. If any model output does not meet the preset success criteria, reduce the write rate, limit the number of concurrent instructions, or adjust the order of burning tasks.

Images