A camera firmware burning method and system based on dynamic driver loading

Abstract

The application discloses a camera firmware burning method and system based on dynamic driving loading, and relates to the technical field of camera management. The method is applied to an embedded system containing a microcontroller (MCU) and comprises the following steps: after the MCU detects that a camera is connected, a driving file containing burning control logic is read from a first preset path of a storage medium and is carried to a preset execution address of SRAM; a firmware data block is read from a second preset path and is stored in a data buffer; a global interrupt is closed, a separate stack space is switched to, and the driving file is executed by jumping; the MCU transmits a service interface to the driving file through a function pointer table, and the driving file calls a bottom hardware operation through the interface to complete data block burning. The application decouples the burning control logic from a main program, supports dynamic loading and adaptation to different cameras, does not need to recompile the MCU firmware, is not dependent on an interrupt, has small memory occupation, and is suitable for batch burning and on-site upgrading scenes in a PC-free environment.

Description

Technical Field

[0001] This invention relates to the field of camera management technology, and in particular to a method and system for burning camera firmware based on dynamic driver loading. Background Technology

[0002] With the advancement of artificial intelligence and sensor fusion technology, cameras have been widely deployed in key areas such as advanced driver assistance systems (ADAS), autonomous driving, robot navigation, and industrial vision inspection. As a core sensor for environmental perception, the performance and reliability of cameras directly affect the safety and user experience of the entire intelligent system.

[0003] Currently, camera technology solutions are highly diversified. Different manufacturers and models of cameras exhibit significant differences in image sensor type, communication protocols (such as I2C, SPI, GMSL), programming timing, command frame format, and verification mechanisms. This heterogeneity presents the following technical challenges for camera firmware programming and online upgrades: PC dependency issue: In existing technologies, a common solution is to integrate the programming control logic into a PC application and program the camera via USB or serial port. This method is not applicable in PC-free environments such as production line automation, on-site vehicle upgrades, and outdoor maintenance.

[0004] Firmware coupling issue: Another approach is to directly embed the programming logic into the main program of the microcontroller (MCU) or system-on-a-chip (SoC). However, for each new camera model, the main program code must be modified, the entire MCU firmware recompiled, and the firmware reprogrammed, leading to a sharp increase in development and maintenance costs and a longer product iteration cycle.

[0005] Memory usage and interrupt dependency issues: In resource-constrained embedded systems, existing solutions often require loading the entire firmware file into memory at once, making it difficult to efficiently handle large firmware files. Furthermore, the flashing process frequently relies on interrupt mechanisms; in scenarios with frequent interrupts or interrupts disabled, the flashing timing is easily disrupted, reducing flashing stability and success rate.

[0006] Therefore, there is an urgent need in this field for a camera firmware burning solution that can flexibly adapt to various camera models, does not rely on a PC, does not rely on interrupt execution, and has a small memory footprint. Summary of the Invention

[0007] This invention provides a method and system for burning camera firmware based on dynamic driver loading, aiming to solve the technical problems in the prior art, such as strong coupling between the burning control logic and the main program, the need to recompile the MCU firmware to adapt to new models, the burning process relying on interrupts, and high memory consumption.

[0008] To achieve the above objectives, this invention provides a method for burning camera firmware based on dynamic driver loading, applicable to embedded systems containing microcontrollers (MCUs), the method comprising: Step S1, driver loading step: The MCU detects the connection signal with the camera. After detecting the connection, it reads the driver file containing the burning control logic from the first preset path of the storage medium and moves the driver file to the preset execution address of the SRAM inside the MCU.

[0009] Step S2, data reading step: The MCU reads a data block of camera firmware data from the second preset path of the storage medium and stores the data block into the preset data buffer of the SRAM.

[0010] Step S3, Dynamic Execution Step: The MCU disables global interrupts, saves the current stack pointer, switches the stack pointer to the independent stack space preset for the driver file, then points the program counter to the preset execution address of the SRAM, and jumps to execute the driver file.

[0011] The MCU has a pre-defined service interface in the form of a function pointer table, which is passed to the driver file as parameters. The driver file does not contain any absolute hardware address calls; all hardware operations are performed by calling the underlying hardware operation functions provided by the MCU main program through the function pointer table. During execution, the driver file reads the current data block from the data buffer and sends the data block to the camera via the communication interface.

[0012] Step S4, Status Return Step: After the driver file is executed, it returns to the MCU main program, carrying the burning status return value. The MCU main program determines whether the current data block has been successfully burned based on the return status of the driver file.

[0013] Step S5, Cyclic burning steps: If the burning is successful but the firmware data has not been completely burned, repeat steps S2 to S4 until all firmware data is burned.

[0014] As a further improvement of the present invention, the first preset path and the second preset path are different storage paths, thereby achieving physical isolation between the burning control logic and the burning object data.

[0015] As a further improvement of the present invention, the independent stack space is physically isolated from the MCU main program stack space, and the stack operations during the execution of the driver file are only performed in the independent stack space, so as to avoid stack overflow during the execution of the driver file from affecting the data integrity of the main program.

[0016] As a further improvement of the present invention, the driver file is a binary file in native machine code format. When the MCU jumps to execute the driver file, it points the program counter to the preset execution address of the SRAM and executes it in Thumb instruction set mode.

[0017] As a further improvement of the present invention, the function pointer table includes at least communication bus read / write service pointers and non-interrupt-dependent delay service pointers. The communication bus read / write service is implemented based on register polling and does not depend on any interrupt; the non-interrupt-dependent delay service is implemented based on the hardware timer's counter register and does not depend on the system tick timer interrupt.

[0018] As a further improvement of the present invention, the camera is connected to the MCU via a GMSL serializer / deserializer link. The MCU reads the status register inside the deserializer via the I2C bus to determine whether its link lock flag is valid. If so, it determines that the camera is connected.

[0019] As a further improvement of the present invention, the size of the data block does not exceed the capacity of the preset data buffer of the SRAM.

[0020] On the other hand, to achieve the above method, the present invention also provides a camera firmware burning system based on dynamic driver loading, the system comprising: The storage module is used to store the driver file containing the burning control logic in a first preset path and to store the camera firmware data in a second preset path. The detection module is used to detect whether the camera is connected. A loading module is used to move the driver file from the storage module to a preset execution address in the SRAM inside the MCU; The data reading module is used to read a data block of camera firmware data from the second preset path of the storage module and store the data block into the preset data buffer of the SRAM; The execution module is used to disable global interrupts, save the current stack pointer, switch the stack pointer to the independent stack space preset for the driver file, then point the program counter to the preset execution address of the SRAM, and jump to execute the driver file; The MCU has a pre-defined service interface in the form of a function pointer table, which is passed to the driver file via parameters. The driver file does not contain any absolute hardware address calls; all hardware operations are completed by calling the underlying hardware operation functions provided by the MCU main program through the function pointer table. During execution, the driver file reads the current data block from the data buffer and sends the data block to the camera through the communication interface. After the driver file finishes execution, it returns to the MCU main program with a burning status return value. The MCU main program determines whether the current data block has been successfully burned based on the return status of the driver file. If the burning is successful but the firmware data has not been completely burned, the data reading module continues to read the next data block, and the execution module jumps back to execute the driver file until all firmware data has been burned.

[0021] In some embodiments of the present invention, the system further includes a status indication module for controlling the status of indicator lights (such as off, flashing, or constantly on) according to the burning process to provide user interaction feedback.

[0022] Beneficial effects: By separating the programming control logic from the MCU main program and dynamically loading and executing it as an independent driver file, this invention has the following significant advantages compared to existing technologies: High decoupling and flexible adaptation: Driver files and MCU main program are stored separately and dynamically loaded. When adapting to a new camera model, only the driver file needs to be replaced, without modifying or recompiling the MCU main program, greatly reducing development and maintenance costs.

[0023] Independent operation without PC: The entire programming process is completed independently by the MCU without the need to connect to a computer, making it suitable for PC-free environments such as batch programming on production lines, on-vehicle on-site upgrades, and outdoor maintenance.

[0024] High memory efficiency: By adopting a data block loop reading mechanism, large-capacity firmware can be burned with only a small data buffer (such as 256 bytes), which greatly reduces memory usage and is suitable for resource-constrained embedded systems.

[0025] High execution stability: Global interrupts are disabled and an independent stack space is used during driver execution, avoiding interrupt interference and stack overflow risks, ensuring accurate programming timing and reliable process. The service interface is implemented based on polling and hardware timers, which does not rely on system interrupts, further enhancing the system's robustness. Attached Figure Description

[0026] Figure 1 This is a schematic diagram of the overall process of the camera firmware burning method based on dynamic driver loading described in this invention; Figure 2This is a schematic diagram of an embodiment of the SRAM memory layout inside the MCU in this invention; Figure 3 This is a schematic diagram of the MCU pre-set service interface (function pointer table) structure in this invention. Detailed Implementation

[0027] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0028] Specific implementation examples are given below.

[0029] Example 1: System Architecture and Hardware Environment In this embodiment, the embedded system includes an MCU (such as an STM32 series), a storage medium (such as an SD card / TF card), a camera module (connected to the MCU via a GMSL serializer / deserializer link), and status indicator lights (LEDs).

[0030] In the storage medium, the first preset path (such as "0: / driver / ") is used to store the driver file (driver.bin); the second preset path (such as "0: / firmware / ") is used to store the camera firmware data to be burned.

[0031] The memory layout of the MCU's internal SRAM is as follows: Figure 2 As shown, the driver code area, data buffer, and driver independent stack space are physically isolated from each other.

[0032] Example 2: Main Program Execution Flow like Figure 1 As shown, the MCU main program executes the following steps: System initialization: Initialize GPIO, I2C, SDIO, hardware timer (TIM), and FATFS file system.

[0033] Connection detection: The MCU reads the link lock flag (LOCK bit) from the internal register of the GMSL deserializer via the I2C bus. If the flag is valid, the camera is determined to be connected, and the LED is controlled to flash; if not connected, the LED remains off.

[0034] Driver loading: Read the driver file (driver.bin) from the first preset path on the SD card and move it to the preset execution address of SRAM (such as 0x20003000).

[0035] Data block read: Read 256 bytes of firmware data from the second preset path of the SD card through the FATFS file system and store it in the data buffer (e.g., 0x20007000).

[0036] Jump execution: Disable global interrupts, back up the current stack pointer, switch to the driver's independent stack space (such as 0x2000FFF0), set the program counter to the driver entry address (Thumb mode, address or 0x01), and pass the function pointer table (API Table) and data buffer address as parameters.

[0037] Status handling: After the driver execution returns, the main program stack and global interrupts are restored. If the return value is 0 (success), it is determined whether the firmware has been fully read; if it is negative (failure), the LED is turned off and the burning process is exited.

[0038] Looping and Iteration: If the current data block is successfully burned but the firmware is not completely burned, the next data block is read and the above jump execution process is repeated until all firmware is burned. At this time, the LED becomes constantly lit to indicate completion.

[0039] Example 3: Driver File Execution Logic After the driver file is loaded into SRAM, its execution flow is as follows: Parse the input parameters to obtain the API Table pointer and data buffer address.

[0040] Read 256 bytes of firmware data from the data buffer.

[0041] According to the preset programming timing logic, data is sent to the camera byte by byte or in a specific format through the I2C communication service pointer in the API Table.

[0042] When timing delay is required, call the non-interruptible delay service in the API Table (implemented based on the hardware timer counter register).

[0043] After the current data block is sent, the program returns the burning status to the main program (0 indicates success, and a negative number indicates failure).

[0044] Example 4: Service Interface (Function Pointer Table) Definition like Figure 3 As shown, the MCU main program's preset function pointer table (API Table) contains at least the following members: I2C_Write: I2C bus write service based on register polling, which does not rely on interrupts.

[0045] I2C_Read: I2C bus read service based on register polling, which does not rely on interrupts.

[0046] Delay_us: A microsecond-level delay service based on the hardware timer counter register, which does not rely on SysTick interrupts.

[0047] The driver file does not need to be bound to any hardware address during compilation. All low-level operations are indirectly called through the above function pointers, thereby decoupling the driver logic from the hardware platform.

[0048] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A method for burning camera firmware based on dynamic driver loading, applied to an embedded system containing a microcontroller (MCU), characterized in that, Includes the following steps: Step S1: The MCU detects the connection signal with the camera. After detecting the connection, it reads the driver file containing the programming control logic from the first preset path of the storage medium and moves the driver file to the preset execution address of the SRAM inside the MCU. Step S2: The MCU reads a data block of camera firmware data from the second preset path of the storage medium and stores the data block into the preset data buffer of the SRAM; Step S3: The MCU disables global interrupts, saves the current stack pointer, switches the stack pointer to the independent stack space preset for the driver file, then points the program counter to the preset execution address of the SRAM, and jumps to execute the driver file; The MCU has a service interface that exists in the form of a function pointer table, and passes the service interface to the driver file through parameters. The driver file does not contain any hardware absolute address calls. All hardware operations are completed by calling the underlying hardware operation functions provided by the MCU main program through the function pointer table. During execution, the driver file reads the current data block from the data buffer and sends the data block to the camera through the communication interface; Step S4: After the driver file is executed, it returns to the MCU main program, carrying the burning status return value. The MCU main program determines whether the current data block has been successfully burned based on the return status of the driver file. Step S5: If the burning is successful but the firmware data has not been completely burned, repeat steps S2 to S4 until all firmware data has been burned.

2. The method according to claim 1, characterized in that: The first preset path and the second preset path are different storage paths, thereby achieving physical isolation between the burning control logic and the burning object data.

3. The method according to claim 1, characterized in that: The independent stack space is physically isolated from the MCU main program stack space. Stack operations during the execution of the driver file are performed only in the independent stack space to avoid stack overflow during the execution of the driver file from affecting the data integrity of the main program.

4. The method according to claim 1, characterized in that: The driver file is a binary file in native machine code format. When the MCU jumps to execute the driver file, it points the program counter to the preset execution address of the SRAM and executes it in Thumb instruction set mode.

5. The method according to claim 1, characterized in that: The function pointer table includes at least communication bus read / write service pointers and non-interrupt-dependent delay service pointers; The driver file interacts with the camera by calling the communication bus read / write service pointer. This service is implemented based on register polling and does not rely on any interrupts. The driver file implements timing control by calling the non-interruptible delay service pointer, which is based on the hardware timer's counter register and does not depend on the system tick timer interrupt.

6. The method according to claim 1, characterized in that: In step S1, the camera is connected to the MCU via a GMSL serializer / deserializer link. The MCU reads the status register inside the deserializer via the I2C bus to determine whether its link lock flag is valid. If so, it determines that the camera is connected.

7. The method according to claim 1, characterized in that: The size of the data block does not exceed the capacity of the preset data buffer of the SRAM.

8. A camera firmware burning system based on dynamic driver loading, characterized in that, include: The storage module is used to store the driver file containing the burning control logic in a first preset path and to store the camera firmware data in a second preset path. The detection module is used to detect whether the camera is connected. A loading module is used to move the driver file from the storage module to a preset execution address in the SRAM inside the MCU; The data reading module is used to read a data block of camera firmware data from the second preset path of the storage module and store the data block into the preset data buffer of the SRAM; The execution module is used to disable global interrupts, save the current stack pointer, switch the stack pointer to the independent stack space preset for the driver file, then point the program counter to the preset execution address of the SRAM, and jump to execute the driver file; The MCU has a service interface that exists in the form of a function pointer table, and passes the service interface to the driver file through parameters. The driver file does not contain any hardware absolute address calls. All hardware operations are completed by calling the underlying hardware operation functions provided by the MCU main program through the function pointer table. During execution, the driver file reads the current data block from the data buffer and sends the data block to the camera through the communication interface; After the driver file is executed, it returns to the MCU main program, carrying the burning status return value. The MCU main program determines whether the current data block has been successfully burned based on the return status of the driver file. If the burning is successful but the firmware data has not been completely burned, the data reading module continues to read the next data block, and the execution module jumps to execute the driver file again until all firmware data is burned.

9. The system according to claim 8, characterized in that: The first preset path and the second preset path are different storage paths.

10. The system according to claim 8, characterized in that: The function pointer table includes at least communication bus read / write service pointers and non-interrupt-dependent delay service pointers; The driver file interacts with the camera by calling the communication bus read / write service pointer. This service is implemented based on register polling and does not rely on any interrupts. The driver file implements timing control by calling the non-interruptible delay service pointer, which is based on the hardware timer's counter register and does not depend on the system tick timer interrupt.

Images