A remote OTA upgrade method and device based on a 4G module master

Abstract

The application provides a remote OTA upgrade method and device based on a 4G module master control, applied to a serial screen device containing a 4G module and a non-operating system MCU, the 4G module communicates with the MCU through a serial port, and the device is internally provided with a security SE domain, an embedded operating system and a GPIO control interface. The application takes the 4G module as an OTA upgrade full-process master control core, sequentially completes network initialization and MCU serial port DMA channel configuration, SE domain bidirectional identity authentication and encrypted channel establishment, firmware acquisition verification and differential synthesis, firmware fragmentation issuing and writing, peripheral device driving pre-testing and bootloader backup, and finally completes upgrade restart and multi-level rollback logic configuration. The application migrates OTA full-process control and operation to the 4G module, breaks through the non-system MCU resource limitation, and improves upgrade security and reliability.

Description

Technical Field

[0001] This application relates to the field of firmware upgrade technology for serial port screen devices, and in particular to a remote OTA upgrade method and device based on a 4G module main control. Background Technology

[0002] Serial port display devices are widely used in industrial control, automotive, and commercial displays. They typically use a microcontroller (MCU) without an operating system as the main control unit, along with a 4G module to achieve remote communication and over-the-air (OTA) firmware upgrades. Existing OTA upgrade solutions generally use the MCU as the core control unit, with the 4G module only serving as a communication component for serial port pass-through, which has several inherent drawbacks: First, the limited computing power and memory resources of the MCU without a system prevent it from running high-compression-ratio differential upgrade algorithms, forcing it to use full upgrades, which consume a lot of bandwidth and have low upgrade efficiency. Second, the OTA logic and main business operations share MCU resources, making the upgrade process prone to display lag and touch response delays. Third, network adaptation can only obtain surface signal parameters through AT commands, making it impossible to predict network fluctuations such as base station switching, which can easily lead to upgrade interruptions in mobile scenarios. Fourth, only firmware integrity is verified, without prior verification of peripheral driver compatibility, which can easily result in screen and touch failures after the upgrade. Fifth, the rollback mechanism relies on the MCU's own bootloader; if the bootloader is damaged or the MCU crashes, the device cannot be remotely repaired, posing a risk of becoming bricked. In addition, keys and firmware plaintext are easily intercepted, and the device and firmware are easily cloned and tampered with, resulting in insufficient security protection capabilities. Summary of the Invention

[0003] In view of this, the embodiments of this application provide a remote OTA upgrade method and device based on a 4G module master control, which can overcome the limitation of no system MCU resources, realize stable upgrades in mobile scenarios, peripheral compatibility pre-verification, multi-level rollback in all scenarios and high-level security protection, and solve the problems of low efficiency, poor stability, high risk and insufficient security of existing OTA upgrades.

[0004] The technical solution of this application embodiment is implemented as follows: In a first aspect, embodiments of this application provide a remote OTA upgrade method based on a 4G module master control, applied to a 4G module in a serial port screen device. The serial port screen device includes a 4G module and an MCU without an operating system. The 4G module and the MCU are connected via serial communication. The 4G module has a built-in security SE domain, an embedded operating system, and a GPIO hardware management interface connected to the MCU. The method includes: Complete cellular network registration and TCP / IP protocol stack initialization, obtain the underlying network status parameters of the cellular protocol stack, send DMA configuration commands to the MCU, and complete the configuration of the MCU serial port DMA channel; The secure SE domain completes two-way authentication with the remote OTA server, negotiates encrypted session keys, and establishes an encrypted transmission channel. The system obtains relevant data for the target upgrade firmware from the OTA server and performs integrity and signature validity verification of the target firmware locally. If differential upgrade mode is used, the system reads the currently running old firmware data from the MCU and combines it with the differential patch package downloaded from the OTA server to synthesize the complete target firmware. The target firmware is divided into continuous fixed-length segments, and the segment data is sent to the MCU through the configured serial port DMA channel. The MCU is then controlled to write the segment data to the corresponding Flash storage address. After all chips are distributed, a RAM run command is sent to the MCU to control the MCU to load and execute the peripheral driver test process of the new firmware in RAM; at the same time, the MCU's bootloader program is read and stored locally for backup to verify the availability of the MCU's programming channel; After the peripheral driver test is passed, an upgrade start command is sent to the MCU to control the MCU to complete the firmware upgrade and restart; and multi-level rollback trigger logic is configured to execute the corresponding rollback operation when the MCU encounters an abnormality.

[0005] Secondly, this application also provides a remote OTA upgrade device based on a 4G module master control, applied to a 4G module in a serial port screen device. The serial port screen device includes a 4G module and an MCU without an operating system. The 4G module and the MCU are connected via serial communication. The 4G module has a built-in security SE domain, an embedded operating system, and a GPIO hardware management interface connected to the MCU. The device includes: The pre-configured module is used to complete cellular network registration and TCP / IP protocol stack initialization, obtain the underlying network status parameters of the cellular protocol stack, send DMA configuration commands to the MCU, and complete the configuration of the MCU serial port DMA channel; The authentication module is used to complete two-way identity authentication with the remote OTA server through the secure SE domain, negotiate the encrypted session key, and establish an encrypted transmission channel; The calibration module is used to obtain relevant data of the target upgrade firmware from the OTA server and perform integrity verification and signature validity verification of the target firmware locally. If the differential upgrade mode is adopted, it reads the currently running old firmware data from the MCU and combines it with the differential patch package downloaded from the OTA server to synthesize the complete target firmware. The delivery module is used to divide the target firmware into continuous fixed-length segments, and send the segment data to the MCU through the configured serial port DMA channel, controlling the MCU to write the segment data to the corresponding Flash storage address; The pre-test module is used to send RAM run instructions to the MCU after all chips have been distributed, control the MCU to load and execute the peripheral driver test process of the new firmware in RAM; at the same time, it reads the MCU's bootloader program and stores it to local backup to verify the availability of the MCU's programming channel; The control module is used to send an upgrade start command to the MCU after the peripheral driver test is passed, control the MCU to complete the firmware upgrade and restart; and configure multi-level rollback trigger logic to execute the corresponding rollback operation when the MCU encounters an abnormality.

[0006] Thirdly, embodiments of this application also provide an electronic device, including: a processor, a storage medium, and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the remote OTA upgrade method based on a 4G module master control as described in any of the first aspects.

[0007] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, performs the remote OTA upgrade method based on a 4G module master control as described in any one of the first aspects.

[0008] The embodiments of this application have the following beneficial effects: By migrating the control, computation, and decision-making power of the entire OTA upgrade process from the resource-constrained systemless MCU to the 4G module, this approach overturns the inherent technical architecture of the field, where the MCU is the main controller and the 4G module is the transparent network card. It not only breaks through the computing power and memory bottlenecks of systemless MCUs, enabling high-compression ratio differential upgrades to be implemented on low-cost serial port screen devices, significantly reducing upgrade traffic consumption and upgrade time, but also achieves zero CPU and memory usage for the MCU's main business during the upgrade process through serial port DMA channel configuration, truly achieving seamless upgrades. Furthermore, leveraging the 4G module's ability to directly obtain the underlying parameters of the cellular protocol stack, it enables base station handover prediction and dynamic network status adaptation, significantly improving... Upgrade stability and success rate in mobile scenarios; a national cryptographic security protection system with full-link physical isolation is built through the built-in secure SE domain of the 4G module. The key and plaintext firmware do not come into contact with the MCU throughout the process, eliminating the risk of firmware tampering, device cloning and key leakage at the source; combined with pre-testing of peripheral drivers before upgrade and a three-level full-scenario rollback mechanism, it not only avoids hardware compatibility issues of peripheral failure after upgrade, but also realizes remote recovery in extreme scenarios such as MCU crash and bootloader corruption, completely eliminating the risk of device bricking. Moreover, this solution does not require additional hardware costs and can be directly adapted to the existing general serial port screen hardware architecture, which has strong commercial application value and industry promotion significance. Attached Figure Description

[0009] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 This is a flowchart illustrating steps S101-S106 provided in the embodiments of this application; Figure 2 This is a flowchart illustrating steps S201-S203 provided in the embodiments of this application; Figure 3 This is a flowchart illustrating steps S301-S303 provided in the embodiments of this application; Figure 4 This is a flowchart illustrating steps S401-S404 provided in the embodiments of this application; Figure 5 This is a schematic diagram of the structure of the remote OTA upgrade device based on the 4G module master control provided in the embodiments of this application; Figure 6 This is a schematic diagram of the composition structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0011] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0012] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0013] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0014] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0015] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

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

[0017] See Figure 1 , Figure 1 This is a flowchart illustrating steps S101-S106 of the remote OTA upgrade method based on a 4G module master control provided in this application embodiment. It is applied to a 4G module in a serial port screen device. The serial port screen device includes a 4G module and an MCU without an operating system. The 4G module and the MCU are connected via serial communication. The 4G module has a built-in security SE domain, an embedded operating system, and a GPIO hardware management interface connected to the MCU. Figure 1 Steps S101-S106 shown will be explained.

[0018] In step S101, cellular network registration and TCP / IP protocol stack initialization are completed, the underlying network status parameters of the cellular protocol stack are obtained, a DMA configuration command is sent to the MCU, and the configuration of the MCU serial port DMA channel is completed. In step S102, two-way authentication is completed with the remote OTA server through the secure SE domain, an encrypted session key is negotiated, and an encrypted transmission channel is established; In step S103, relevant data of the target upgrade firmware is obtained from the OTA server, and the integrity verification and signature validity verification of the target firmware are completed locally; if the differential upgrade mode is adopted, the data of the currently running old firmware is read from the MCU, and combined with the differential patch package downloaded from the OTA server to synthesize the complete target firmware. In step S104, the target firmware is divided into continuous fixed-length segments, and the segment data is sent to the MCU through the configured serial port DMA channel, controlling the MCU to write the segment data to the corresponding Flash storage address; In step S105, after all chip distribution is completed, a RAM run instruction is sent to the MCU to control the MCU to load and execute the peripheral driver test process of the new firmware in RAM; at the same time, the MCU's bootloader program is read and stored locally for backup to verify the availability of the MCU's programming channel; In step S106, after the peripheral driver test is passed, an upgrade start command is sent to the MCU to control the MCU to complete the firmware upgrade and restart; and multi-level rollback trigger logic is configured to execute the corresponding rollback operation when the MCU encounters an abnormality.

[0019] The essence of this application's embodiment is to migrate 100% of the control, computation, and decision-making power of the entire OTA upgrade process to the 4G module for execution. Throughout the entire process, the MCU (Microcontroller Unit) without a system needs to handle any core OTA logic, complex calculations, or process control. The MCU merely acts as a slave device for service and upgrade execution, passively responding to the instructions of the 4G module. In specific implementation, a general-purpose 4G module can be selected. This module has a built-in LuatOS embedded real-time operating system, an NFC secure SE domain, up to 64MB of RAM, and 128MB of Flash storage, providing sufficient computing power and storage resources to support the entire OTA process logic. The matching MCU can be a mainstream general-purpose MCU without a system, such as the STM32F103 series or GD32 series, used in the serial port display field. No additional hardware modification is required; simply connect the 4G module's UART serial port to the MCU's serial peripheral, and connect the 4G module's three general-purpose GPIOs to the MCU's reset pin, BOOT configuration pin, and ISP programming trigger pin, respectively. This completes the hardware deployment with zero additional hardware cost.

[0020] In practical implementation, after the 4G module powers on, it independently completes cellular network registration, PDP context activation, and TCP / IP protocol stack initialization without requiring the MCU to send any AT commands or participate in any networking process. This differs from the existing technology where the MCU drives the 4G module to connect to the network via AT commands. After networking, the 4G module directly accesses the cellular protocol stack layer through the operating system's underlying API to obtain full-dimensional network status parameters, instead of only obtaining the surface signal strength CSQ value through AT commands as in the existing technology. Simultaneously, it sends DMA configuration commands to the MCU to complete the full parameter configuration of the MCU's serial port DMA channel, establishing a firmware transmission basic channel without MCU CPU intervention. After the channel is established, the 4G module relies entirely on its built-in secure SE domain to independently complete two-way authentication with the remote OTA server, negotiate the national cryptographic encryption session key, and establish an end-to-end encrypted transmission channel. All key calculations and encryption / decryption operations are executed in a closed loop within the SE domain. Throughout the process, the key and sensitive data do not leave the SE hardware security domain, physically eliminating the risk of key leakage and plaintext data eavesdropping.

[0021] After the secure channel is established, the 4G module reports the device's current firmware version number, hardware model, and MCU's globally unique ID to the OTA server. It then obtains relevant data for the target upgrade firmware from the OTA server and performs SM3 integrity verification and SM2 signature validity verification of the firmware locally to ensure that the firmware source is legitimate and the data is complete and untampered with. For differential upgrade scenarios, the 4G module reads the full data of the currently running old firmware from the MCU via the serial port. Combined with the differential patch package downloaded from the server, it runs a high compression ratio differential synthesis algorithm in the local embedded operating system to generate the complete target firmware. This completely breaks through the resource limitation of only tens of KB of running memory in a systemless MCU, making it possible to implement industry-standard high compression ratio differential algorithms such as bsdiff / hdiffz on low-cost systemless serial port screen devices.

[0022] After firmware preprocessing and verification, the 4G module divides the target firmware into continuous fixed-length segments. It then sends these segment data to the MCU via a pre-configured serial DMA channel. The MCU writes the segment data to an upgrade backup partition in Flash, completely isolated from the main program partition. The entire data reception, transfer, and writing process is automatically completed by the MCU's DMA and Flash controllers, without any computation or scheduling by the MCU CPU. After all segments are sent, the 4G module sends a RAM execution command to the MCU, controlling it to load and execute the new firmware's peripheral driver test process in its internal RAM. Without modifying the currently running main program, this verifies the hardware compatibility of the new firmware with the device's display, touchscreen, and core peripherals. Simultaneously, it reads the MCU's bootloader program and stores it in local Flash backup, verifying the full availability of the MCU's programming channel and preparing for subsequent rollback in all scenarios. Ultimately, the 4G module will send an upgrade start command to the MCU only after all peripheral driver tests have passed, controlling the MCU to complete firmware partition switching and restart. At the same time, it is configured with a three-level multi-level rollback trigger logic covering all scenarios. When the MCU encounters any abnormal state such as startup anomaly, crash, or bootloader corruption, the corresponding rollback operation will be automatically executed to achieve closed-loop management of upgrade risks in all scenarios.

[0023] In some embodiments, see Figure 2 , Figure 2 This is a flowchart illustrating steps S201-S203 provided in the embodiments of this application. The steps of completing cellular network registration and TCP / IP protocol stack initialization, obtaining the underlying network status parameters of the cellular protocol stack, sending DMA configuration instructions to the MCU, and completing the configuration of the MCU serial port DMA channel can be achieved through steps S201-S203, which will be explained in conjunction with each step.

[0024] In step S201, the network status parameters of the underlying cellular protocol stack are read. The network status parameters include serving cell signal quality, neighboring cell signal strength, base station handover countdown, RRC connection status, and channel congestion level. In step S202, the TCP transmission parameters and firmware fragment length are dynamically adjusted based on the read network status parameters. In step S203, when the base station handover countdown is less than or equal to a preset threshold, the new fragment delivery operation is paused, the transmission confirmation of the currently delivered fragment is completed, and the fragment delivery operation is resumed after the base station handover is completed.

[0025] In practical implementation, after the 4G module completes cellular network registration, it directly reads the full-dimensional network status parameters of the cellular protocol stack through the underlying API of the LuatOS embedded operating system. The parameters include six dimensions: serving cell RSRP signal quality, neighboring cell RSRP signal strength, base station handover countdown, RRC connection status, downlink channel congestion level, and TA time advance. Unlike existing technologies that can only obtain the surface signal strength CSQ value through AT commands, the CSQ value only reflects the current signal strength and cannot predict core events that will cause network interruption, such as base station handover and channel congestion. This embodiment can predict changes in network status 500ms to 3s in advance through the collection of full-dimensional underlying parameters, especially the base station handover event, which is the most common in mobile scenarios, upgrading from "post-event remediation" to "pre-event prediction".

[0026] The 4G module establishes a parameter mapping table based on the read full-dimensional network status parameters, dynamically adjusting TCP transmission parameters and firmware fragment length to achieve real-time matching between transmission strategies and network conditions. Specifically, the mapping rules are as follows: When the network is in a stable, optimized state (serving cell RSRP ≥ -85dBm, no neighbor cell handover warning, no channel congestion), the TCP sliding window size is configured to 64KB, the firmware fragment length to 4096 bytes, and forward error correction is disabled to maximize transmission efficiency; when the network is in a weak, stable state (-105dBm ≤ RSRP < -85dBm, no handover warning, mild congestion), the TCP sliding window size is configured to 16KB, the firmware fragment length to 1024 bytes, and mild forward error correction is enabled. To balance transmission efficiency and stability, when the network is in a congested state (RSRP ≥ -85dBm, but the channel congestion level is higher than the preset threshold), the TCP slow start algorithm is activated, the TCP sliding window is configured to 8KB, and the firmware fragment length is 512 bytes to reduce the transmission rate and prevent the network congestion from worsening. When the network is in a transient state (RSRP < -105dBm, or RRC connection anomaly), the TCP sliding window is configured to 4KB, the firmware fragment length is 256 bytes, strong forward error correction is enabled, and the link fast self-healing mechanism is triggered.

[0027] When the 4G module detects that the base station handover countdown is less than or equal to a preset threshold, it will immediately execute predictive transmission control. In this embodiment, the preset threshold is 3 seconds. The triggering condition is: the neighboring cell RSRP value is higher than the serving cell by 3dBm for more than 500ms, and the cellular protocol stack reports a base station handover preparation event. After triggering, the 4G module immediately suspends the new fragment delivery operation, and at the same time completes the TCP transmission confirmation of the currently delivered fragments, maintaining the continuous active state of the TCP long connection and PDP context. There is no need to disconnect the existing network connection or release session resources. After the base station handover is completed, the 4G module obtains the stable TA value of the new serving cell, and the channel state returns to normal, the fragment delivery operation resumes within 10ms without re-establishing the TCP connection or re-authenticating. This implementation completely avoids the problems of 1-3 seconds network interruption, fragmentation packet loss, and connection loss caused by base station switching in mobile scenarios. It eliminates the need to perform reconnection and retransmission operations after network interruption, thereby reducing the probability of upgrade interruption in mobile scenarios from the root. The measured upgrade interruption rate in mobile scenarios has been reduced from more than 30% in the existing technology to less than 0.1%.

[0028] In some embodiments, the DMA configuration command sent to the MCU is used to configure the MCU's serial port receive event to trigger automatic DMA data transfer, and configure the target address of the DMA data transfer to be the corresponding storage partition of the MCU Flash.

[0029] In practice, the DMA configuration command sent by the 4G module to the MCU is a dedicated register configuration command that matches the MCU chip model. For the mainstream STM32F103C8T6 MCU in the serial port display field, the specific configuration parameters are: binding the MCU's USART1 serial port peripheral (the serial port communicating with the 4G module), corresponding to channel 2 of the DMA1 controller, configuring the DMA transfer direction as peripheral to memory, data width of 8 bits, enabling loop mode and transfer completion interrupt, and fixing the serial port baud rate to 115200, with 8 data bits, 1 stop bit, and no parity bit, perfectly matching the 4G module's serial port parameters. After receiving this configuration command, the MCU automatically completes the full parameter configuration of the serial port DMA channel, implementing two core functions, both of which are executed automatically at the hardware level without CPU intervention.

[0030] The first configuration option is to configure the MCU's serial port receive event to trigger automatic DMA data transfer. Specifically, the IDLE interrupt of USART1 is enabled. When the serial port receives a frame of fragmented data sent by the 4G module and the serial bus enters an idle state, the IDLE interrupt is triggered. This interrupt service function only performs a flag setting operation for one instruction cycle and does not perform any data reading, processing, or transfer. The DMA controller will automatically transfer the serial port data in the USART1 data register directly to the preset buffer in the MCU's internal SRAM. The entire process does not require the CPU to trigger a serial port receive interrupt or perform data reading and transfer operations, completely freeing up the MCU's CPU computing power.

[0031] The second configuration involves setting the target address for DMA data transfer to the corresponding memory partition of the MCU Flash. Specifically, the MCU Flash is pre-divided into two completely hardware-isolated main partitions: Partition A is the main program execution partition, with an address range of 0x08000000-0x0803FFFF, storing the currently running device main program; during the upgrade process, it is read-only and cannot be erased or written. Partition B is the upgrade backup partition, with an address range of 0x08040000-0x0807FFFF, specifically used to store downloaded upgrade firmware, and is completely isolated from the main program partition. The DMA configuration command explicitly specifies that the final target address for DMA data transfer is the corresponding offset address of Partition B. After the DMA completes the internal SRAM transfer of one frame of data, it automatically triggers the Flash controller to write the data in the buffer to the corresponding Flash address of Partition B. The entire process requires no CPU intervention in Flash erasure / write operations.

[0032] The core advantage of this configuration method is that the entire process of firmware data being received from the serial port and written to the Flash backup partition is automatically completed by the MCU's DMA controller and Flash controller hardware. The MCU's CPU only needs to run the main business such as serial port screen display refresh, touch scanning, and business logic processing. It does not need to allocate any computing resources for OTA upgrades. In actual tests, the CPU utilization rate of the MCU's main business fluctuated by no more than 1% during the upgrade process, achieving zero impact and zero lag on the main business during OTA upgrades. This is different from the compromise solution of "time-sharing and idle scheduling" in existing technologies, and completely solves the resource conflict between OTA upgrades and main business.

[0033] In some embodiments, see Figure 3 , Figure 3 This is a flowchart illustrating steps S301-S303 provided in the embodiments of this application. The two-way authentication between the security SE domain and the remote OTA server, the negotiation of the encrypted session key, and the establishment of the encrypted transmission channel can be achieved through steps S301-S303, which will be explained in conjunction with each step.

[0034] In step S301, within the built-in security SE domain, a two-way authentication process with the remote OTA server is executed to negotiate and generate an encrypted session key; In step S302, an encrypted transmission channel is established with the OTA server based on the encrypted session key generated through negotiation; In step S303, the globally unique ID of the MCU is read, and the target firmware is bound and encrypted with the globally unique ID of the MCU within the built-in security SE domain.

[0035] In practice, all authentication, key negotiation, and encryption / decryption operations of the 4G module are performed within the built-in NFC security SE domain. This SE domain is an independent hardware security unit built into the 4G module. The device root key pair with the national cryptographic SM2 algorithm is fixed at the factory. The root key can only be accessed within the SE domain and cannot be read by any external program. Even the 4G module's own LuatOS embedded operating system cannot directly obtain the key data in the SE domain. This physically eliminates the risk of key reading and leakage, which is different from the fundamental defect of storing the key in plaintext in the MCU Flash in existing technologies, making it easy for hardware debuggers to read.

[0036] The two-way authentication process is executed in a closed loop within the SE domain. The specific steps are as follows: First, the 4G module generates a 16-byte true random number within the SE domain, signs this random number using the device's built-in SM2 private key, and sends the device's unique IMEI number, the device's SM2 public key, and the signed random number data packet to the remote OTA server. Second, after receiving the data packet, the OTA server verifies the validity of the random number signature using the device's SM2 public key. Upon successful verification, it generates a 16-byte server true random number, signs the combination of the "server random number + device random number" using the server's SM2 private key, and sends the server's SM2 public key, the signed data packet, and the SM4 session key encrypted using the device's SM2 public key to the 4G module. Third, the 4G module imports the received data packet into the SE domain, verifies the validity of the signature using the server's SM2 public key, and upon successful verification, decrypts the signature using the device's SM2 private key to obtain the SM4 session key. This session key is stored in the secure storage area of ​​the SE domain. The session key is never exported from the SE domain and cannot be read by external programs.

[0037] After key negotiation, the 4G module establishes a TLS 1.3 encrypted transmission channel with the OTA server based on the SM4 session key stored in the SE domain. All subsequent firmware data and control command transmissions are completed through this encrypted channel. All encryption and decryption operations are performed within the SE domain, ensuring the MCU has no access to plaintext firmware data. Even if serial port data is intercepted, the plaintext firmware cannot be decrypted. Simultaneously, the 4G module reads the 96-bit globally unique ID (GUID) embedded in the MCU chip at the factory via the serial port. This ID is a unique and unmodifiable hardware identifier for each MCU chip. The 4G module transmits this ID to the SE domain, binding the target firmware with the MCU's GUID for encryption. Specifically, the MCU's 96-bit unique ID is used as the initial IV vector for SM4 encryption in CBC mode, and the target firmware is encrypted in blocks. The encrypted firmware ciphertext can only be decrypted and written by the MCU's built-in hardware decryption engine corresponding to the unique ID. Even if the firmware ciphertext is illegally intercepted, it cannot be decrypted and used on other devices, completely eliminating the risks of device cloning, firmware tampering, and malicious flashing.

[0038] Meanwhile, this embodiment also implements version chain anti-replay protection in the SE domain. Specifically, the signature data of each new firmware version must contain the SM3 hash value of the previous firmware version, forming an immutable version chain structure. When the 4G module verifies the firmware signature in the SE domain, it simultaneously verifies the continuity of the version chain hash value. If the version chain hash value of the new firmware version is not continuous, or if it is a replay of an old version of the vulnerable firmware, the upgrade is directly rejected, thus completely preventing replay attacks by old version of the vulnerable firmware. This constructs a full-link security protection system from device authentication, transmission encryption, firmware anti-cloning to anti-replay.

[0039] In some embodiments, see Figure 4 , Figure 4 This is a flowchart illustrating steps S401-S404 provided in the embodiments of this application. The step of obtaining relevant data of the target upgrade firmware from the OTA server and completing the integrity verification and signature validity verification of the target firmware locally; if the differential upgrade mode is adopted, the data of the currently running old firmware is read from the MCU and combined with the differential patch package downloaded from the OTA server to synthesize the complete target firmware, which can be achieved through steps S401-S404, and will be explained in conjunction with each step.

[0040] In step S401, the size parameters of the differential patch package and the full firmware package are obtained from the OTA server; In step S402, the differential upgrade mode or the full upgrade mode is selected based on the size ratio of the differential patch package to the full firmware package. In step S403, when the full upgrade mode is selected, the complete target firmware is downloaded from the OTA server, and the integrity verification and signature validity verification are completed locally. In step S404, when the differential upgrade mode is selected, the full data of the currently running old firmware is read from the MCU via the serial port and stored in the local Flash. The corresponding version of the differential patch package is downloaded from the OTA server. The differential synthesis algorithm is run in the local embedded operating system to generate the complete target firmware and complete the integrity verification and signature legality verification of the target firmware.

[0041] In practice, after the 4G module and the OTA server complete two-way authentication, the 4G module first sends the device's current firmware version number, hardware model, and globally unique MCU ID to the OTA server. Based on the reported device information, the OTA server returns the corresponding version's differential patch package, the size parameters of the full firmware package, the SM3 hash value, and the SM2 signature value to the 4G module. The 4G module automatically selects the optimal upgrade mode based on the ratio of the differential patch package size to the full firmware package size. In this embodiment, the preset selection threshold is 60%, meaning that when the ratio of the differential patch package size to the full firmware package size is ≤60%, the differential upgrade mode is selected first; otherwise, the full upgrade mode is selected, achieving an optimal balance between upgrade traffic consumption and upgrade efficiency.

[0042] When the full upgrade mode is selected, the 4G module directly downloads the complete target firmware from the OTA server. During the download process, each data segment is decrypted and verified simultaneously. After the download is completed, the hash value of the complete firmware is calculated locally using the national cryptographic SM3 algorithm and compared with the hash value of the firmware sent by the server to complete the integrity verification. At the same time, the firmware signature data is transmitted to the SE domain, and the national cryptographic SM2 algorithm is called to complete the digital signature legality verification of the firmware to ensure that the firmware is complete, of legitimate origin, and has not been tampered with. After the verification is passed, the segment delivery process begins.

[0043] When differential upgrade mode is selected, the 4G module first sends an old firmware read command to the MCU via serial port. After receiving the command, the MCU uses the DMA controller to transfer the full amount of old firmware data in the main program partition of area A into data blocks of 2048 bytes each, and sends them to the 4G module via serial port. Each data block is accompanied by a 16-bit CRC check value. After receiving each data block, the 4G module first checks the CRC value. If the check is successful, it stores the data in its local Flash memory to ensure that the old firmware data read is complete and error-free. Throughout the process, the MCU only performs DMA data transfer and does not need to perform any calculations. After the old firmware is read, the 4G module downloads the corresponding differential patch package from the OTA server. In its own LuatOS embedded operating system, it runs the industry-standard bsdiff / hdiffz high-efficiency differential synthesis algorithm. The peak memory requirement of this algorithm is 3 to 5 times the firmware size. For the 256KB firmware commonly used in serial port screens, the peak memory requirement is about 1MB. The 4G module has sufficient memory to support this operation, while the memory of MCUs without a system is generally only 20KB to 64KB, which is not enough to support the operation of this algorithm. This is the core bottleneck that has prevented the implementation of high-efficiency differential upgrades in this field for a long time.

[0044] The specific implementation process of differential synthesis is as follows: The 4G module first decompresses the differential patch package, parses the block offset address, block length, newly added data, and replacement instructions in the patch package, and performs block replacement, block addition, and block deletion operations on the old firmware according to the patch instructions to generate a complete new version target firmware. After synthesis, the 4G module calculates the SM3 hash value of the synthesized new firmware and compares it with the hash value of the target firmware sent by the server to complete the integrity verification. At the same time, it completes the SM2 signature validity verification. Only after all verifications pass will it enter the fragmentation and distribution process. This implementation method transfers all the complex calculations of differential synthesis to the 4G module for execution, without requiring the MCU to undertake any differential calculations. It completely breaks through the resource limitations of MCUs without a system, realizes the implementation of high compression ratio differential upgrades on low-cost serial port screen devices, reduces upgrade traffic consumption, and shortens upgrade time.

[0045] In some embodiments, when generating a fragment distribution status table locally, the next fragment is distributed only after the distribution of each fragment is completed and a write completion receipt is received from the MCU; after the device recovers from an anomaly, the distribution continues from the fragments that were not completed last time, according to the fragment distribution status table.

[0046] In practice, after completing the integrity verification, signature verification, and fragmentation of the target firmware, the 4G module generates a standardized fragmentation distribution status table in its local Flash memory. This status table is a fixed-structure binary file, stored in real-time in the non-volatile storage area of ​​the 4G module, and is not lost when power is lost, ensuring that the historical distribution status can be fully read after the device recovers from an anomaly. Each fragment corresponds to a fixed entry in the status table, and the structure of each entry is as follows: fragment sequence number (2 bytes), fragment start Flash offset address (4 bytes), fragment data length (2 bytes), fragment CRC32 check value (4 bytes), distribution status (1 byte: 0 = not distributed, 1 = distribution in progress, 2 = distribution completed), and MCU write confirmation status (1 byte: 0 = unconfirmed, 1 = confirmed). The total number of entries in the status table is exactly the same as the total number of fragments.

[0047] The 4G module strictly follows the order of fragment number from smallest to largest, sending fragment data one by one. After each fragment is sent, it must wait for the MCU to return a write completion receipt, which contains the CRC32 checksum of the fragment data. The 4G module compares the checksum in the receipt with the fragment checksum stored in its local status table. Only after a complete match will the sending status of that fragment be marked as 2 and the MCU write confirmation status as 1. At the same time, the updated status table is written to local Flash persistent storage, and then the next fragment is sent. A retransmission mechanism is also set: if no MCU receipt is received within the preset 500ms timeout after a fragment is sent, or if the checksum in the receipt fails to match, the 4G module will immediately retransmit the fragment, up to a maximum of 3 consecutive retransmissions. If all 3 retransmissions fail, transmission is immediately paused, the network status is rechecked, and transmission resumes only after the network status recovers, avoiding unnecessary retransmissions that could exacerbate network congestion.

[0048] When a device experiences an anomaly such as power outage, network interruption, or hardware reset, and resumes normal operation, the 4G module first reads the fragment delivery status table stored in its local Flash memory. It then iterates through the delivery status of all fragments and the MCU write confirmation status to pinpoint the first incomplete fragment sequence number. Simultaneously, to ensure that the data already written to the MCU Flash is not corrupted, the 4G module sends a fragment verification command to the MCU. The MCU returns the CRC32 checksum of the confirmed written fragments according to their sequence numbers, comparing it one by one with the checksum values ​​in the local status table. Failed fragments are eliminated, and the starting fragment sequence number for retransmission is determined. Delivery continues directly from this fragment without needing to re-download the entire firmware package or re-deliver fragments marked as complete and verified. This implementation significantly improves upgrade efficiency after anomaly recovery, reduces unnecessary data consumption, and is particularly suitable for mobile environments with frequent network fluctuations and device power outages, avoiding the problems of prolonged upgrade time and increased data costs caused by repeated downloads.

[0049] In some embodiments, the RAM run instruction sent to the MCU is used to control the MCU to load the peripheral driver code of the new firmware into the MCU's internal RAM without modifying the current running program, perform peripheral initialization and loopback test, and return the test results to the 4G module; the 4G module only performs the subsequent upgrade startup steps after all peripheral driver tests have passed.

[0050] In practice, the RAM execution instructions sent by the 4G module to the MCU are dedicated control instructions that match the MCU's core instruction set. Upon receiving these instructions, the MCU first allocates an independent execution space in its internal SRAM. This execution space is completely address-isolated from the current main program's execution space, ensuring no mutual interference and no modification of any data in the Flash memory. This guarantees that the testing process will not affect the normal operation of the main business. Subsequently, the MCU loads the key peripheral driver code from the new firmware, including the display driver, touchscreen driver, core serial port peripheral driver, and GPIO control driver, into this independent RAM space. It then sets the program counter to jump to the driver entry address in RAM and executes the driver initialization and testing process. The entire testing process runs entirely in RAM, without writing to Flash or replacing the currently running peripheral driver. After the test is completed, the RAM space is immediately released, having no lasting impact on the main business.

[0051] The peripheral driver testing process is a standardized, item-by-item verification process, controlled by the 4G module. It includes four core test items: First, the display driver test: the MCU sends a read chip ID command to the display driver chip of the serial port screen (commonly used in serial port screens such as ILI9341, ST7789, NV3023, etc.), reads the chip ID and compares it with a preset list of valid IDs to verify the communication link is normal; then, a full-screen refresh command is sent to read the echo data from the display cache, verifying the driver read / write function is normal, ensuring the display can light up and refresh normally after the upgrade. Second, the touchscreen driver test: the MCU sends reset and initialization commands to the touchscreen controller (commonly used XPT2046, GT911, FT5x06 series), reads the chip ID to verify normal communication, and sends a touch scan command to verify that the touch coordinate data can be returned normally, ensuring the touch function is normal after the upgrade. The third item is the core serial port peripheral test. The MCU performs a data loopback test on the core serial port that communicates with the 4G module and the functional serial port that communicates with peripherals. A fixed-length test data packet is sent, the returned data is read and compared, and the consistency is verified to confirm that the serial communication function is normal. The fourth item is the core GPIO peripheral test. The MCU performs output level toggling and input level reading tests on the core control GPIO pins of the device to verify that the GPIO control function is normal.

[0052] After the MCU completes all peripheral tests, it returns the complete test results to the 4G module via serial port. The 4G module verifies the test results one by one. Only when all peripheral tests pass is the peripheral compatibility test considered passed, and the subsequent upgrade startup steps are executed. If any peripheral test fails, the 4G module immediately terminates the upgrade process, sends a data clearing command to the MCU to clear the firmware data already written to the Flash backup partition, and reports a peripheral compatibility error log to the OTA server, including the failed test, device hardware model, and firmware version number. It will absolutely not start new firmware with compatibility risks. The entire testing process takes no more than 500ms, completed entirely within the display refresh interval of the serial port screen, without affecting the normal operation of the main business. This fundamentally avoids extreme problems such as peripheral failure, device inoperability, and inability to trigger rollback after the upgrade, significantly reducing the risk of device paralysis after the upgrade.

[0053] In some embodiments, the multi-level rollback triggering logic specifically includes: First-level rollback: After the MCU restarts, the 4G module starts a timeout countdown. If it does not receive a startup success signal from the MCU within the preset timeout period, it sends a rollback command to the MCU's bootloader to control the bootloader to load the old version of firmware. Second-level rollback: If the 4G module does not receive the MCU's heartbeat signal within the preset detection period, it triggers the MCU's ISP burning mode through the GPIO interface to write the locally backed-up old firmware into the MCU's Flash storage area. Third-level rollback: When the 4G module detects that the MCU's bootloader is damaged, it configures the MCU's startup pin level through the GPIO interface, forcing the MCU to enter the serial programming mode that is originally programmed by the chip manufacturer, and rewrites the bootloader and main program firmware.

[0054] The first-level rollback is an automatic rollback based on basic startup anomalies. It's the most commonly used basic rollback mechanism for common scenarios such as new firmware startup failures and program crashes. In practice, after the 4G module restarts the MCU, it starts a preset timeout. In this embodiment, the default timeout is 10 seconds, which can be flexibly adjusted according to the device hardware configuration. After the new firmware on the MCU starts normally, it immediately sends a startup success heartbeat packet to the 4G module via serial port after completing peripheral initialization and main service framework startup, and simultaneously sends a watchdog signal to the bootloader. If the 4G module does not receive a startup success signal from the MCU within the preset 10-second timeout, it determines that the new firmware startup is abnormal and immediately sends a rollback command to the MCU's bootloader via serial port. Upon receiving the command, the MCU's bootloader automatically rewrites the backed-up old firmware version into the main program partition, loads the old firmware version, and starts running, allowing the device to quickly return to normal working status within 10 seconds, without any manual intervention.

[0055] The second-level rollback is a forced rollback for MCU crashes. It addresses abnormal scenarios such as MCU program crashes, serial port unresponsiveness, or inability to respond to bootloader commands. This is done entirely by the 4G module through a hardware interface, without the need for MCU program intervention. Specifically, the GPIO1 pin of the 4G module is hardware-connected to the MCU's NRST reset pin, and the GPIO2 pin is hardware-connected to the MCU's BOOT0 boot configuration pin. The 4G module has a preset heartbeat detection period; in this embodiment, the default period is 30 seconds. Under normal operating conditions, the MCU's main program sends a running status heartbeat signal to the 4G module every 10 seconds. If the 4G module does not receive any heartbeat signal from the MCU within the 30-second detection period, it determines that the MCU has experienced a crash, program crash, or other serious abnormality. At this point, the 4G module executes a forced rollback process: first, it pulls the GPIO1 pin low to force a hardware reset of the MCU, and simultaneously pulls the GPIO2 pin high. Then, it releases the GPIO1 pin, allowing the MCU to directly enter the ISP programming mode pre-programmed by the chip manufacturer after the reset. Subsequently, the 4G module sends an ISP handshake command via serial port to establish communication with the MCU's ISP bootloader, completely writing the locally backed-up old firmware version into the MCU's Flash main program partition. After writing is complete, it verifies the firmware hash value. Once confirmed to be correct, it pulls the GPIO2 pin low, resets the MCU again, and forces a rollback to the normal old firmware version. The entire rollback process is completely controlled by the 4G module, without the need for user program intervention on the MCU. Even if the MCU completely crashes and the serial port becomes unresponsive, the rollback can still be executed normally.

[0056] The third-level rollback is a remote recovery for bootloader corruption. Addressing the extreme scenario where the bootloader in the MCU user's Flash is corrupted and unable to enter normal boot or ISP mode, this is the ultimate fault tolerance guarantee of the invention, completely breaking the conventional wisdom that "bootloader corruption can only be corrected by returning the device to the factory for reprogramming." In specific implementation, after triggering the ISP programming mode, if the 4G module fails to establish communication with the MCU's ISP bootloader three times consecutively, it is determined that the bootloader in the MCU user's Flash is corrupted. At this point, the 4G module executes the recovery process: It configures the MCU's BOOT0 and BOOT1 pin levels through the GPIO interface, forcing the MCU to enter the system memory boot mode embedded in the chip's original ROM. This mode is the low-level boot mode embedded in the hardware ROM at the chip's factory and cannot be modified, erased, or damaged by software. Even if the bootloader in the user's Flash is completely corrupted, it can still enter normally. Subsequently, the 4G module, through this serial programming mode, first writes the original bootloader program to the MCU. After verifying that the writing is correct, it then writes the backed-up old version of the main program firmware. After the entire writing process is completed, it verifies the hash value of the complete firmware. After confirming that it is correct, it resets the MCU, allowing the device to fully restore its normal operating state. This rollback mechanism enables remote recovery after a complete MCU failure, eliminating the possibility of the device becoming unusable. In addition, after each rollback, the 4G module will report the rollback trigger reason, abnormal status, and device information to the OTA server, facilitating remote operation and maintenance and troubleshooting.

[0057] In some embodiments, the method further includes: For incremental upgrade scenarios, the Flash physical address corresponding to the target incremental data is calculated. During the MCU's main business idle period, the incremental data is sent to the MCU through the serial port DMA channel, and the MCU is controlled to write the incremental data directly to the corresponding Flash address.

[0058] This embodiment applies to incremental upgrade scenarios, specifically including: UI updates for serial port screens, adjustments to business parameter thresholds, optimization of non-core business logic, and minor bug fixes. These scenarios require only modifications to some functional code and do not require changes to the interrupt vector table, reset vector, main loop framework, or peripheral drivers. These scenarios account for over 80% of daily upgrade needs for serial port screen devices. A full upgrade is not necessary; only modifications to a small number of binary code segments are required. In practice, the 4G module uses a binary comparison tool to compare the bin files of the old and new firmware, accurately locating the differing binary byte segments. It records the starting Flash physical address, data length, and incremental data content of each differing segment, generating a lightweight incremental upgrade package. Each incremental data segment is no longer than 256 bytes, ensuring that writing can be completed within the MCU's CPU idle period without affecting the normal operation of the main business.

[0059] The 4G module obtains the running status of the MCU's main business in real time through the serial port and accurately identifies the idle cycle of the MCU CPU. The specific identification method is as follows: The main program of the MCU without a system adopts the industry-standard super loop (while(1)) structure. After each loop, the MCU will send an idle flag signal to the 4G module, indicating that the core logic of the current main business has been completed and the CPU has entered the idle cycle. After receiving the idle flag, the 4G module immediately sends an incremental segment of data. Through the pre-configured serial port DMA channel, the incremental data is moved to the MCU's Flash write buffer. At the same time, the MCU's Flash controller is controlled to write the incremental data to the corresponding Flash physical address. The entire writing process adopts an atomic writing mechanism: each incremental segment is first written to the Flash backup area. After verifying that the data is complete and error-free, it is written to the target address all at once to prevent data corruption caused by power failure during the writing process and ensure the integrity of the writing operation.

[0060] After the incremental data is written, the MCU does not need to be restarted. The new code segment will be automatically called during the next execution of the main loop, achieving hot patch upgrades without restarting or interrupting the main business. Simultaneously, this solution also includes a real-time rollback mechanism for hot upgrades: if a device malfunction is detected after the incremental data is written, the 4G module can immediately send the original data to the original address, restoring the device to its pre-upgrade state without restarting, eliminating any risk of device failure. This implementation fills the technical gap where MCUs without a system cannot achieve upgrades without restarting. It is particularly suitable for application scenarios such as industrial serial port displays, vehicle-mounted serial port displays, and commercial self-service equipment serial port displays that require continuous operation and cannot be arbitrarily stopped and restarted, significantly improving the flexibility and availability of device upgrades and reducing the impact of upgrades on normal device operation.

[0061] In summary, the embodiments of this application have the following beneficial effects: By migrating the control, computation, and decision-making power of the entire OTA upgrade process from the resource-constrained systemless MCU to the 4G module, this approach overturns the inherent technical architecture of the field, where the MCU is the main controller and the 4G module is the transparent network card. It not only breaks through the computing power and memory bottlenecks of systemless MCUs, enabling high-compression ratio differential upgrades to be implemented on low-cost serial port screen devices, significantly reducing upgrade traffic consumption and upgrade time, but also achieves zero CPU and memory usage for the MCU's main business during the upgrade process through serial port DMA channel configuration, truly achieving seamless upgrades. Furthermore, leveraging the 4G module's ability to directly obtain the underlying parameters of the cellular protocol stack, it enables base station handover prediction and dynamic network status adaptation, significantly improving... Upgrade stability and success rate in mobile scenarios; a national cryptographic security protection system with full-link physical isolation is built through the built-in secure SE domain of the 4G module. The key and plaintext firmware do not come into contact with the MCU throughout the process, eliminating the risk of firmware tampering, device cloning and key leakage at the source; combined with pre-testing of peripheral drivers before upgrade and a three-level full-scenario rollback mechanism, it not only avoids hardware compatibility issues of peripheral failure after upgrade, but also realizes remote recovery in extreme scenarios such as MCU crash and bootloader corruption, completely eliminating the risk of device bricking. Moreover, this solution does not require additional hardware costs and can be directly adapted to the existing general serial port screen hardware architecture, which has strong commercial application value and industry promotion significance.

[0062] Based on the same inventive concept, this application also provides a remote OTA upgrade device based on a 4G module master control, which corresponds to the remote OTA upgrade method based on a 4G module master control in the first embodiment. Since the principle of the device in this application is similar to the remote OTA upgrade method based on a 4G module master control, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0063] like Figure 5 As shown, Figure 5 This is a schematic diagram of the structure of a remote OTA upgrade device 500 based on a 4G module master control provided in this application embodiment. The 4G module is applied to a serial port screen device, which includes a 4G module and an MCU without an operating system. The 4G module and the MCU are connected via serial communication. The 4G module has a built-in security SE domain, an embedded operating system, and a GPIO hardware management interface connected to the MCU. The remote OTA upgrade device 500 based on a 4G module master control includes: The pre-configured module 501 is used to complete cellular network registration and TCP / IP protocol stack initialization, obtain the underlying network status parameters of the cellular protocol stack, send DMA configuration commands to the MCU, and complete the configuration of the MCU serial port DMA channel. Authentication module 502 is used to complete two-way identity authentication with the remote OTA server through the security SE domain, negotiate the encrypted session key, and establish an encrypted transmission channel; The calibration module 503 is used to obtain relevant data of the target upgrade firmware from the OTA server and complete the integrity verification and signature validity verification of the target firmware locally. If the differential upgrade mode is adopted, it reads the currently running old firmware data from the MCU and combines it with the differential patch package downloaded from the OTA server to synthesize the complete target firmware. The sending module 504 is used to divide the target firmware into continuous fixed-length segments, send the segment data to the MCU through the configured serial port DMA channel, and control the MCU to write the segment data to the corresponding Flash storage address; The pre-test module 505 is used to send RAM run instructions to the MCU after all chips have been distributed, control the MCU to load and execute the peripheral driver test process of the new firmware in RAM; at the same time, it reads the MCU's bootloader program and stores it to local backup to verify the availability of the MCU's programming channel. The control module 506 is used to send an upgrade start command to the MCU after the peripheral driver test is passed, control the MCU to complete the firmware upgrade and restart; and configure multi-level rollback trigger logic to execute the corresponding rollback operation when the MCU encounters an abnormality.

[0064] Those skilled in the art should understand that Figure 5 The functions of each unit in the remote OTA upgrade device 500 based on 4G module master control shown can be understood by referring to the relevant description of the remote OTA upgrade method based on 4G module master control mentioned above. Figure 5 The functions of each unit in the remote OTA upgrade device 500 based on the 4G module master control shown can be implemented by a program running on the processor or by specific logic circuits.

[0065] In one possible implementation, the pre-configuration module 501 is specifically used for: Read the network status parameters at the bottom layer of the cellular protocol stack. The network status parameters include serving cell signal quality, neighboring cell signal strength, base station handover countdown, RRC connection status, and channel congestion level. Based on the read network status parameters, dynamically adjust the TCP transmission parameters and firmware fragment length; When the base station handover countdown is less than or equal to a preset threshold, the new fragment delivery operation is paused, the transmission confirmation of the currently delivered fragments is completed, and the fragment delivery operation is resumed after the base station handover is completed.

[0066] In one possible implementation, the DMA configuration command sent to the MCU is used to configure the MCU's serial port receive event to trigger automatic DMA data transfer, and the target address of the DMA data transfer is configured to be the corresponding storage partition of the MCU Flash.

[0067] In one possible implementation, the authentication module 502 is specifically used for: Within the built-in secure SE domain, a two-way authentication process with the remote OTA server is executed to negotiate and generate an encrypted session key; An encrypted transmission channel is established with the OTA server based on the negotiated encrypted session key; Read the MCU's globally unique ID, and bind and encrypt the target firmware with the MCU's globally unique ID within the built-in secure SE domain.

[0068] In one possible implementation, the alignment module 503 is specifically used for: Obtain the size parameters of the differential patch package and the full firmware package from the OTA server; Choose between differential upgrade mode or full upgrade mode based on the size ratio of the differential patch package to the full firmware package. When selecting the full upgrade mode, the complete target firmware is downloaded from the OTA server, and integrity verification and signature validity verification are performed locally. When the differential upgrade mode is selected, the system reads the full data of the currently running old firmware from the MCU via serial port and stores it in the local Flash. It then downloads the corresponding version of the differential patch package from the OTA server, runs the differential synthesis algorithm in the local embedded operating system to generate the complete target firmware, and completes the integrity verification and signature validity verification of the target firmware.

[0069] In one possible implementation, when generating the fragment distribution status table locally, the next fragment is distributed only after the distribution of each fragment is completed and a write completion receipt is received from the MCU; after the device recovers from an anomaly, the distribution continues from the fragments that were not completed last time, according to the fragment distribution status table.

[0070] In one possible implementation, the RAM run instruction sent to the MCU is used to control the MCU to load the peripheral driver code of the new firmware into the MCU's internal RAM without modifying the current running program, perform peripheral initialization and loopback test, and return the test results to the 4G module; the 4G module only performs the subsequent upgrade startup steps after all peripheral driver tests have passed.

[0071] In one possible implementation, the multi-level rollback triggering logic specifically includes: First-level rollback: After the MCU restarts, the 4G module starts a timeout countdown. If it does not receive a startup success signal from the MCU within the preset timeout period, it sends a rollback command to the MCU's bootloader to control the bootloader to load the old version of firmware. Second-level rollback: If the 4G module does not receive the MCU's heartbeat signal within the preset detection period, it triggers the MCU's ISP burning mode through the GPIO interface to write the locally backed-up old firmware into the MCU's Flash storage area. Third-level rollback: When the 4G module detects that the MCU's bootloader is damaged, it configures the MCU's startup pin level through the GPIO interface, forcing the MCU to enter the serial programming mode that is originally programmed by the chip manufacturer, and rewrites the bootloader and main program firmware.

[0072] In one possible implementation, the control module is also used for: For incremental upgrade scenarios, the Flash physical address corresponding to the target incremental data is calculated. During the MCU's main business idle period, the incremental data is sent to the MCU through the serial port DMA channel, and the MCU is controlled to write the incremental data directly to the corresponding Flash address.

[0073] The aforementioned remote OTA upgrade device based on a 4G module as the main control unit migrates the control, computation, and decision-making power of the entire OTA upgrade process from a resource-constrained, system-less MCU to a 4G module. This overturns the inherent technical architecture in this field where the MCU is the main controller and the 4G module is the transparent network card. It not only breaks through the computing power and memory bottlenecks of system-less MCUs, enabling high-compression ratio differential upgrades to be implemented on low-cost serial port screen devices, significantly reducing upgrade traffic consumption and upgrade time, but also achieves zero CPU and memory usage for the MCU's main business during the upgrade process through serial port DMA channel configuration, truly achieving seamless upgrades. Relying on the 4G module's ability to directly obtain the underlying parameters of the cellular protocol stack, it realizes base station handover prediction and network status. Dynamic adaptation significantly improves the stability and success rate of upgrades in mobile scenarios. A fully physically isolated national cryptographic security protection system is built through the 4G module's built-in secure SE domain, ensuring that the key and plaintext firmware never come into contact with the MCU, thus eliminating the risks of firmware tampering, device cloning, and key leakage at the source. Combined with pre-testing of peripheral drivers before upgrades and a three-level full-scenario rollback mechanism, hardware compatibility issues of peripheral failure after upgrades are avoided in advance, and remote recovery is achieved in extreme scenarios such as MCU crashes and bootloader corruption, completely eliminating the risk of device bricking. Furthermore, this solution requires no additional hardware costs and can be directly adapted to existing general-purpose serial port screen hardware architectures, possessing strong commercial application value and industry promotion significance.

[0074] like Figure 6 As shown, Figure 6This is a schematic diagram of the composition structure of the electronic device 600 provided in the embodiments of this application. The electronic device 600 includes: The device includes a processor 601, a storage medium 602, and a bus 603. The storage medium 602 stores machine-readable instructions that can be executed by the processor 601. When the electronic device 600 is running, the processor 601 communicates with the storage medium 602 via the bus 603. The processor 601 executes the machine-readable instructions to perform the steps of the remote OTA upgrade method based on a 4G module master control as described in the embodiments of this application.

[0075] In practical applications, the various components in the electronic device 600 are coupled together via a bus 603. It is understood that the bus 603 is used to achieve communication between these components. In addition to a data bus, the bus 603 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 6 The general designated all buses as Bus 603.

[0076] The aforementioned electronic devices, by migrating the control, computation, and decision-making power of the entire OTA upgrade process from a resource-constrained, system-less MCU to a 4G module, overturn the inherent technical architecture of the field, where the MCU is the main controller and the 4G module is the transparent network card. This not only breaks through the computing power and memory bottlenecks of system-less MCUs, enabling high-compression ratio differential upgrades to be implemented on low-cost serial port screen devices, significantly reducing upgrade traffic consumption and upgrade time, but also achieves zero CPU and memory usage for the MCU's main business during the upgrade process through serial port DMA channel configuration, truly achieving seamless upgrades. Furthermore, relying on the 4G module's ability to directly obtain the underlying parameters of the cellular protocol stack, it achieves base station handover prediction and dynamic network status adaptation, significantly… It improves the stability and success rate of upgrades in mobile scenarios; it constructs a national cryptographic security protection system with full-link physical isolation through the built-in secure SE domain of the 4G module, ensuring that the key and plaintext firmware do not come into contact with the MCU throughout the process, thus eliminating the risks of firmware tampering, device cloning, and key leakage at the source; combined with pre-testing of peripheral drivers before upgrades and a three-level full-scenario rollback mechanism, it not only avoids hardware compatibility issues of peripheral failure after upgrades in advance, but also realizes remote recovery in extreme scenarios such as MCU crashes and bootloader corruption, completely eliminating the risk of device bricking. Moreover, this solution does not require additional hardware costs and can be directly adapted to existing general serial port screen hardware architectures, which has strong commercial application value and industry promotion significance.

[0077] This application also provides a computer-readable storage medium storing executable instructions. When the executable instructions are executed by at least one processor 601, the remote OTA upgrade method based on a 4G module master control described in this application is implemented.

[0078] In some embodiments, the storage medium may be a magnetic random access memory (FRAM), a read-only memory (ROM), or a programmable read-only memory (PROM). Erasable Programmable Read-Only Memory (EPROM) Electrically Erasable Programmable Read-Only Memory (EEPROM) Read-only memory, flash memory, magnetic surface storage, optical disc, or CD-ROM ROM, Compact Disc Read It can be a memory such as a memory only; or it can be a device that includes one or any combination of the above-mentioned memories.

[0079] In some embodiments, executable instructions may take the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0080] As an example, executable instructions may, but do not necessarily, correspond to files in the file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple collaborating files (e.g., a file that stores one or more modules, subroutines, or code sections).

[0081] As an example, executable instructions can be deployed to execute on a single computing device, or on multiple computing devices located in one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network.

[0082] The aforementioned computer-readable storage medium, by migrating the control, computation, and decision-making power of the entire OTA upgrade process from the resource-constrained systemless MCU to the 4G module, overturns the inherent technical architecture of the field, where the MCU is the main controller and the 4G module is the transparent network card. This not only breaks through the computing power and memory bottlenecks of systemless MCUs, enabling high-compression ratio differential upgrades to be implemented on low-cost serial port screen devices, significantly reducing upgrade traffic consumption and upgrade time, but also achieves zero CPU and memory usage for the MCU's main business during the upgrade process through serial port DMA channel configuration, truly achieving seamless upgrades. Furthermore, relying on the 4G module's ability to directly obtain the underlying parameters of the cellular protocol stack, it enables base station handover prediction and dynamic network status adaptation. It significantly improves the stability and success rate of upgrades in mobile scenarios; by building a fully physical isolated national cryptographic security protection system through the built-in secure SE domain of the 4G module, the key and plaintext firmware never come into contact with the MCU throughout the process, eliminating the risks of firmware tampering, device cloning and key leakage at the source; combined with the pre-testing of peripheral drivers before the upgrade and the three-level full-scenario rollback mechanism, it not only avoids hardware compatibility issues of peripheral failure after the upgrade in advance, but also realizes remote recovery in extreme scenarios such as MCU crash and bootloader damage, completely eliminating the risk of device bricking. Moreover, this solution does not require additional hardware costs and can be directly adapted to the existing general serial port screen hardware architecture, which has strong commercial application value and industry promotion significance.

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

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

[0085] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0086] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a platform server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0087] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A remote OTA upgrade method based on a 4G module main control, characterized in that, A 4G module is applied in a serial port display device, the serial port display device including a 4G module and an MCU without an operating system, the 4G module and the MCU are connected via serial communication, the 4G module has a built-in security SE domain, an embedded operating system, and a GPIO hardware management interface connected to the MCU, the method includes: Complete cellular network registration and TCP / IP protocol stack initialization, obtain the underlying network status parameters of the cellular protocol stack, send DMA configuration commands to the MCU, and complete the configuration of the MCU serial port DMA channel; The secure SE domain completes two-way authentication with the remote OTA server, negotiates encrypted session keys, and establishes an encrypted transmission channel. The system obtains relevant data for the target upgrade firmware from the OTA server and performs integrity and signature validity verification of the target firmware locally. If differential upgrade mode is used, the system reads the currently running old firmware data from the MCU and combines it with the differential patch package downloaded from the OTA server to synthesize the complete target firmware. The target firmware is divided into continuous fixed-length segments, and the segment data is sent to the MCU through the configured serial port DMA channel. The MCU is then controlled to write the segment data to the corresponding Flash storage address. After all chips are distributed, a RAM run command is sent to the MCU to control the MCU to load and execute the peripheral driver test process of the new firmware in RAM; at the same time, the MCU's bootloader program is read and stored locally for backup to verify the availability of the MCU's programming channel; After the peripheral driver test is passed, an upgrade start command is sent to the MCU to control the MCU to complete the firmware upgrade and restart; and multi-level rollback trigger logic is configured to execute the corresponding rollback operation when the MCU encounters an abnormality.

2. The method according to claim 1, characterized in that, The steps of completing cellular network registration and TCP / IP protocol stack initialization, obtaining underlying network status parameters of the cellular protocol stack, sending DMA configuration commands to the MCU, and completing the configuration of the MCU serial port DMA channel include: Read the network status parameters at the bottom layer of the cellular protocol stack. The network status parameters include serving cell signal quality, neighboring cell signal strength, base station handover countdown, RRC connection status, and channel congestion level. Based on the read network status parameters, dynamically adjust the TCP transmission parameters and firmware fragment length; When the base station handover countdown is less than or equal to a preset threshold, the new fragment delivery operation is paused, the transmission confirmation of the currently delivered fragments is completed, and the fragment delivery operation is resumed after the base station handover is completed.

3. The method according to claim 1, characterized in that, The DMA configuration command sent to the MCU is used to configure the MCU's serial port receive event to trigger automatic DMA data transfer, and configure the target address of the DMA data transfer to be the corresponding storage partition of the MCU Flash.

4. The method according to claim 1, characterized in that, The secure SE domain and remote OTA server complete two-way authentication, negotiate an encrypted session key, and establish an encrypted transmission channel, including: Within the built-in secure SE domain, a two-way authentication process with the remote OTA server is executed to negotiate and generate an encrypted session key; An encrypted transmission channel is established with the OTA server based on the negotiated encrypted session key; Read the MCU's globally unique ID, and bind and encrypt the target firmware with the MCU's globally unique ID within the built-in secure SE domain.

5. The method according to claim 1, characterized in that, The relevant data of the target upgrade firmware is obtained from the OTA server, and the integrity verification and signature validity verification of the target firmware are completed locally. If differential upgrade mode is used, the currently running old firmware data is read from the MCU and combined with the differential patch package downloaded from the OTA server to synthesize the complete target firmware, including: Obtain the size parameters of the differential patch package and the full firmware package from the OTA server; Choose between differential upgrade mode or full upgrade mode based on the size ratio of the differential patch package to the full firmware package. When selecting the full upgrade mode, the complete target firmware is downloaded from the OTA server, and integrity verification and signature validity verification are performed locally. When the differential upgrade mode is selected, the system reads the full data of the currently running old firmware from the MCU via serial port and stores it in the local Flash. It then downloads the corresponding version of the differential patch package from the OTA server, runs the differential synthesis algorithm in the local embedded operating system to generate the complete target firmware, and completes the integrity verification and signature validity verification of the target firmware.

6. The method according to claim 1, characterized in that, When generating the fragment distribution status table locally, the next fragment is distributed only after the distribution of each fragment is completed and a write completion receipt is received from the MCU. After the device recovers from an anomaly, the distribution continues from the fragments that were not completed last time, according to the fragment distribution status table.

7. The method according to claim 1, characterized in that, The RAM run instruction sent to the MCU is used to control the MCU to load the peripheral driver code of the new firmware into the MCU's internal RAM without modifying the current running program, perform peripheral initialization and loopback test, and return the test results to the 4G module; The 4G module will only proceed with the subsequent upgrade and startup steps after all peripheral driver tests have passed.

8. The method according to claim 1, characterized in that, The multi-level rollback triggering logic specifically includes: First-level rollback: After the MCU restarts, the 4G module starts a timeout countdown. If it does not receive a startup success signal from the MCU within the preset timeout period, it sends a rollback command to the MCU's bootloader to control the bootloader to load the old version of firmware. Second-level rollback: If the 4G module does not receive the MCU's heartbeat signal within the preset detection period, it triggers the MCU's ISP burning mode through the GPIO interface to write the locally backed-up old firmware into the MCU's Flash storage area. Third-level rollback: When the 4G module detects that the MCU's bootloader is damaged, it configures the MCU's startup pin level through the GPIO interface, forcing the MCU to enter the serial programming mode that is originally programmed by the chip manufacturer, and rewrites the bootloader and main program firmware.

9. The method according to claim 1, characterized in that, The method further includes: For incremental upgrade scenarios, the Flash physical address corresponding to the target incremental data is calculated. During the MCU's main business idle period, the incremental data is sent to the MCU through the serial port DMA channel, and the MCU is controlled to write the incremental data directly to the corresponding Flash address.

10. A remote OTA upgrade device based on a 4G module main control, characterized in that, A 4G module for use in a serial port display device, the serial port display device including a 4G module and an MCU without an operating system, the 4G module and the MCU being connected via serial communication, the 4G module having a built-in security SE domain, an embedded operating system, and a GPIO hardware management interface connected to the MCU, the device comprising: The pre-configured module is used to complete cellular network registration and TCP / IP protocol stack initialization, obtain the underlying network status parameters of the cellular protocol stack, send DMA configuration commands to the MCU, and complete the configuration of the MCU serial port DMA channel; The authentication module is used to complete two-way identity authentication with the remote OTA server through the secure SE domain, negotiate the encrypted session key, and establish an encrypted transmission channel; The calibration module is used to obtain relevant data of the target upgrade firmware from the OTA server and perform integrity verification and signature validity verification of the target firmware locally. If the differential upgrade mode is adopted, it reads the currently running old firmware data from the MCU and combines it with the differential patch package downloaded from the OTA server to synthesize the complete target firmware. The delivery module is used to divide the target firmware into continuous fixed-length segments, and send the segment data to the MCU through the configured serial port DMA channel, controlling the MCU to write the segment data to the corresponding Flash storage address; The pre-test module is used to send RAM run instructions to the MCU after all chips have been distributed, control the MCU to load and execute the peripheral driver test process of the new firmware in RAM; at the same time, it reads the MCU's bootloader program and stores it to local backup to verify the availability of the MCU's programming channel; The control module is used to send an upgrade start command to the MCU after the peripheral driver test is passed, control the MCU to complete the firmware upgrade and restart; and configure multi-level rollback trigger logic to execute the corresponding rollback operation when the MCU encounters an abnormality.

Images