Remote OTA upgrading method and device for coffee booth and storage medium

Abstract

The invention relates to the technical field of embedded device firmware upgrading, in particular to a remote OTA upgrading method and device for a coffee pavilion and a storage medium, and the method comprises the steps that S1, an OTA cloud generates a differential package according to a slave control module, and generates a security upgrading package according to the differential package; s2, forwarding the security upgrade package to a target slave control module; s3, the APP program receives the security upgrade package and performs row-level verification; s4, after the security upgrade package is received, the APP program sets an upgrade mark and resets the device, the Bootloader program writes the upgrade package data in the dynamic buffer area into a main program area, and final verification is carried out on the written firmware; s5, if the final verification is passed, the slave control module runs the new firmware and cleans a dynamic buffer area and an upgrade mark; and if the final verification fails, the Bootloader program rolls back to the old firmware. Through differential upgrading, multiple verification and an automatic rollback mechanism, safe and reliable firmware upgrading is realized in a resource-constrained environment, equipment is effectively prevented from becoming brick-shaped, and service continuity is ensured.

Description

Technical Field

[0001] This invention relates to the field of embedded device firmware upgrade technology, and in particular to a remote OTA upgrade method, device and storage medium for coffee kiosks. Background Technology

[0002] With the deep integration of IoT technology and smart catering equipment, fully automatic coffee kiosks, as typical commercial devices integrating embedded systems, are becoming increasingly complex. A modern fully automatic coffee kiosk typically includes a main control board and multiple dedicated slave control modules, such as grinding control modules, milk frothing control modules, and capping control modules. Each module runs independent firmware to achieve precise collaborative control. Firmware version iterations are crucial for optimizing the coffee making process, fixing software defects, introducing new beverage recipes, and improving the user experience. Traditional firmware upgrades mainly rely on on-site operation by technicians, using physical connections (such as USB-to-serial adapters) to individually flash each slave control module. This method has inherent drawbacks such as high maintenance costs and slow response times.

[0003] To address these issues, remote over-the-air (OTA) technology has been introduced into the embedded systems field. Existing technologies include several common embedded OTA solutions, such as: the bootloader-based dual-partition IAP solution, which requires twice the storage space of the firmware, making the hardware cost prohibitive for the resource-constrained slave modules widely used in coffee kiosks; application-in-programming solutions, which heavily rely on the normal operation of the application, preventing the upgrade process from starting if the application crashes; and the high overhead of embedded Linux system upgrade frameworks, making them unsuitable for simple microcontroller-based slave modules.

[0004] Furthermore, existing OTA solutions have revealed a series of new technical challenges when applied to the specific scenario of coffee kiosks: Lack of anti-accidental firmware flashing mechanism: There are many models of coffee kiosk modules with different board numbers and function numbers. The existing solution lacks an effective firmware and hardware matching verification mechanism. Accidental firmware flashing can easily lead to abnormal module functions or even hardware damage. The upgrade process suffers from insufficient reliability: Commercial networks (such as Wi-Fi) are subject to fluctuations, and large firmware files are prone to upgrade failures due to packet loss or verification errors. There is a lack of reliable breakpoint resumption and line-level verification mechanisms. Significant security risks exist: the beverage recipes at coffee kiosks are core business assets, and there is a risk of them being stolen or tampered with during remote transmission. Existing solutions often lack end-to-end encryption and strong authentication mechanisms.

[0005] Weak fault tolerance and rollback capability: If the upgrade process is interrupted due to power failure or other reasons, the module may become unusable. There is a lack of a fast rollback solution to ensure business continuity, which may cause the coffee kiosk to be unusable for a long time. Inefficient batch management: It is impossible to perform efficient and differentiated batch upgrades and status monitoring of a wide range of coffee kiosks of different models and their multiple slave control modules.

[0006] Therefore, there is an urgent need in this field for a remote OTA upgrade solution that combines high reliability, high security, resource efficiency, and convenient operation and maintenance for multi-module collaborative scenarios in coffee kiosks. Summary of the Invention

[0007] The purpose of this invention is to overcome the shortcomings of existing technologies and provide a remote OTA upgrade method for coffee kiosks, comprising the following steps: S1: The OTA cloud generates a differential packet containing board number identifier and function number based on the current firmware version and target firmware version of each slave control module of the coffee kiosk, and encrypts the differential packet to form a security upgrade package. S2: The OTA cloud sends the security upgrade package to the coffee kiosk main control board, and the coffee kiosk main control board forwards the security upgrade package to the target slave control module; S3: The APP program of the target slave module receives the security upgrade package, performs row-level verification during the receiving process, and temporarily stores the data that passes the verification into the dynamic buffer of the slave module. If the verification fails, the upgrade process is stopped. S4: After the security upgrade package is received, the APP program sets the upgrade flag and resets the device. The Bootloader program writes the upgrade package data in the dynamic buffer into the main program area and performs final verification on the written firmware. S5: If the final verification passes, the slave control module runs the new firmware and clears the dynamic buffer and upgrade flag. If the final verification fails, the bootloader program rolls back to the old firmware and clears the upgrade flag.

[0008] Preferably, in step S1, generating the differential package including the board number identifier and the function number includes: S11: The OTA cloud uses a differential algorithm to compare the current firmware version with the target firmware version to generate an initial differential packet; S12: The OTA cloud adds a firmware identifier, including a board number field and a function number field, to the header of the initial differential packet; S13: The OTA cloud uses an encryption algorithm to encrypt the differential upgrade package after adding the firmware identifier to obtain an encrypted differential package, and at the same time calls a verification algorithm to calculate the verification value of the encrypted differential package; S14: The OTA cloud encapsulates the encrypted differential packet, the verification value, and firmware version information, including the new firmware version number and version release time, into a complete security upgrade package.

[0009] Preferably, before executing the upgrade process, the slave control module also includes verifying the firmware identifier in the security upgrade package: The APP program reads its own stored hardware configuration information, which includes the local board number and the pre-configured local function number. The APP program parses the firmware identifier in the security upgrade package and extracts the upgrade package board number and upgrade package function number; Compare the local board number with the upgrade package board number, the local function number, and the upgrade package function number; If the board number is inconsistent or the function number is incompatible, the upgrade process will be terminated and an error code will be returned. If they match, the subsequent upgrade steps will continue.

[0010] Preferably, in step S3, line-level verification is performed during the receiving process, and the verified data is temporarily stored in the dynamic buffer of the slave control module, including: S31: The APP program receives the data of the security upgrade package line by line according to the preset data line length in the security upgrade package. After receiving each complete line of data, it immediately calls the preset verification algorithm to calculate the checksum of the data in that line. S32: The APP program extracts the preset checksum carried in the currently received data line and compares the checksum with the preset checksum for consistency. S33: If the comparison results are inconsistent, the upgrade process will be stopped immediately, and an upgrade failure response containing the error code and the failure line number will be returned to the main control board. S34: If the comparison results match, then according to the address allocation rules of the dynamic buffer, determine the target write address corresponding to the row of data, and write the row of data to the target address of the dynamic buffer; S35: After the data is written, perform a readback verification to ensure that the write is correct; S36: When the first line of data is received and verified, the APP program first performs a complete sector erasure operation on the target sector in the dynamic buffer to store the data, clearing the old data remaining in the sector; the subsequently received verified data is written into the dynamic buffer in ascending order of the target address, without repeating the sector erasure.

[0011] Preferably, in step S4, the Bootloader program writes the upgrade package data in the dynamic buffer into the main program area and performs final verification of the written firmware, including: S41: After the slave module is reset, the bootloader program first reads the upgrade flag bit in the specified storage area of ​​the slave module and determines whether the upgrade flag bit is in a preset valid state. If the upgrade flag bit is in an invalid state, the bootloader program directly guides the slave module to run the firmware in the current main program area. S42: If the upgrade flag is valid, the Bootloader program performs a sector erasure operation on the target storage area in the main program area where the new firmware is to be written. After erasure, it verifies whether the sector is erased cleanly. If it is not erased cleanly, it performs erasure again. S43: After the sector erase verification is passed, the Bootloader program reads the security upgrade package data from the dynamic buffer continuously in ascending order of the address of the dynamic buffer, and moves it in batches to the target storage area of ​​the main program area to ensure the continuity and integrity of data transfer. S44: After the data transfer is completed, the Bootloader program reads the complete data of the new firmware that has been written in the main program area, calls the preset overall verification algorithm, and calculates the overall verification value of the new firmware. S45: The Bootloader program parses the target verification information carried in the upgrade package and performs a consistency comparison between the overall verification value and the target verification information; S46: If the comparison results are consistent, the final verification is deemed successful. The Bootloader program updates the firmware validity flag in the main program area and prepares to jump to the new firmware for execution. If the comparison results are inconsistent, the final verification is deemed unsuccessful. The firmware rollback mechanism is immediately triggered to terminate the startup of the new firmware.

[0012] Preferably, the firmware rollback triggering mechanism includes: If the final verification fails, the Bootloader program will immediately reset the upgrade flag in the storage area specified by the slave module to an invalid state; The bootloader program switches the program access address to the backup program area of ​​the slave module, calls the boot process of the old firmware stored in the backup program area, and attempts to boot the old firmware. The bootloader program determines whether the old firmware has started successfully by detecting the reset vector integrity and initialization completion signal of the old firmware. If the old firmware is detected as ready within a preset time, the startup is considered successful, and the control module is restored to its normal working state before the upgrade, and can respond normally to the function control commands of the coffee kiosk. After the old firmware boots successfully, the Bootloader program records the relevant information of this upgrade failure in the non-volatile log storage area of ​​the slave control module. The log content includes the upgrade failure timestamp, target firmware version number, old firmware version number, failure reason, and comparison result of the new firmware verification value in the main program area with the target verification information. After returning the upgrade failure result to the main control board, the Bootloader program shuts down its own running resources, transfers system control to the old firmware, and the slave module maintains normal working status, waiting for the main control board to forward the next OTA upgrade command.

[0013] Preferably, the method further includes batch upgrade management: The OTA cloud platform pre-builds and maintains a multi-dimensional mapping relationship library. The mapping relationship library stores the association relationship between coffee kiosk equipment model, slave control module type, slave control module hardware architecture, target firmware version and corresponding differential package, and supports dynamic updating of the mapping relationship library when adding a new equipment model or iterating the firmware version. Maintenance personnel input upgrade configuration commands through the visual management interface of the OTA cloud platform; The OTA cloud platform responds to the upgrade configuration command by sending a board number query request to the main control board of each coffee kiosk in the target device group. It determines the corresponding hardware architecture through the slave control module board number fed back by the main control board, and then matches compatible differential packages for slave control modules with different hardware architectures based on the mapping relationship library. The OTA cloud platform sends upgrade instructions and matching differential packets to the target device group in batches according to the preset distribution strategy, and starts the real-time monitoring process. It collects upgrade status data of each device in real time through the bidirectional communication link. The upgrade status data includes upgrade instruction reception status, differential packet transmission progress, row-level verification results, data writing status, final verification results, and rollback status. The OTA cloud platform aggregates the upgrade results of each device and generates upgrade result statistics, including the total number of upgraded devices, the number of successful upgrades, the number of failed upgrades, the classification of failure reasons, and the upgrade success rate. For devices that fail to upgrade, the platform automatically triggers a retry mechanism and reissues upgrade instructions and differential packages according to preset rules. If the upgrade still fails after retrying, the platform marks the device as an abnormal upgrade device and pops up a window to prompt maintenance personnel to handle it.

[0014] Preferably, the upgrade configuration command includes: The target equipment group is selected according to preset screening conditions, and the type of slave control module to be upgraded is specified. The slave control module type includes, but is not limited to, heating control module, grinding control module, and water outlet control module.

[0015] Based on the same concept, the present invention also provides a computer device including a memory and a processor, wherein the memory stores computer-readable instructions, which, when executed by the processor, cause the processor to perform the steps of a remote OTA upgrade method for a coffee kiosk as described in the embodiments.

[0016] Based on the same concept, the present invention also provides a storage medium storing computer-readable instructions, characterized in that, when the computer-readable instructions are executed by one or more processors, the one or more processors cause the one or more processors to perform the steps of a remote OTA upgrade method for a coffee kiosk as described in any one of the embodiments.

[0017] Compared with the prior art, the beneficial effects of the present invention are: This invention generates differential packets containing board number identifiers and function numbers based on the firmware versions of each slave control module of the coffee kiosk via OTA cloud, and encrypts the differential packets to form a secure upgrade package. This allows the upgrade to be completed by transmitting only the firmware differences, which greatly reduces the network transmission load and the storage space requirements of the slave control modules. While ensuring the upgrade function, it significantly reduces resource consumption and hardware costs. This invention enables the target slave module's APP program to perform row-level verification during the receiving process and temporarily store the verified data in a dynamic buffer. If the verification fails, the upgrade process is stopped, thus ensuring the integrity and accuracy of data transmission even in commercial environments with unstable networks. Combined with the flexible storage management of the dynamic buffer, it effectively avoids the excessive occupation of storage resources by traditional dual-partition solutions. This invention uses a bootloader program to perform final verification of the firmware written to the main program area. If the verification fails, it automatically rolls back to the old firmware and clears the upgrade flag, achieving second-level business recovery in the event of an upgrade failure. This ensures that the key functions of the coffee kiosk are not interrupted due to upgrade failure, greatly improving the reliability and business continuity of the system. This invention achieves end-to-end security protection from firmware source and transmission process to device writing through firmware identifier matching verification and full-process encryption mechanism, effectively preventing firmware flashing, recipe leakage and malicious code injection, and ensuring the safe and stable operation of the coffee kiosk system; This invention enables batch upgrade management of multiple devices and modules through an OTA cloud platform, achieving a closed-loop operation and maintenance system that automatically matches differential packages based on different hardware architectures, monitors upgrade status in real time, and performs intelligent retries. This significantly improves the operation and maintenance efficiency of large-scale coffee kiosk clusters and reduces manual maintenance costs. Attached Figure Description

[0018] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention.

[0019] Figure 1 This is a flowchart of the remote OTA upgrade method for coffee kiosks according to the present invention; Figure 2 This is another flowchart of the remote OTA upgrade method for coffee kiosks according to the present invention; Figure 3 This is a business process diagram of the remote OTA upgrade method for coffee kiosks according to the present invention; Figure 4 This is an architecture diagram of the remote OTA upgrade method for coffee kiosks according to the present invention; Figure 5 This is a schematic diagram of the firmware identifier of the present invention; Figure 6 This is a schematic diagram of the data space allocation for the BootLoader of the present invention; Figure 7 This is a flowchart of the firmware upgrade package line-level sending and error handling process of the present invention; Figure 8 This is a simplified flowchart of the APP backup process and a simplified flowchart of the BootLoader startup process of this invention. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention. Obviously, the described embodiments are only some, not all, of the embodiments described in this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without creative effort are within the scope of protection of this application.

[0021] Those skilled in the art will understand that, unless otherwise stated, the singular forms “a” and “an” used herein, and “the”, may also include the plural forms. It should be further understood that the term “comprising” as used in this specification means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0022] First Embodiment Please see Figure 1 , Figure 2 , Figure 3 and Figure 4As shown in the figure, this embodiment provides a remote OTA upgrade method for coffee kiosks, including the following steps: S1: The OTA cloud (OTA cloud server) generates a differential packet containing board number identifier and function number based on the current firmware version and target firmware version of each slave control module of the coffee kiosk, and encrypts the differential packet to form a security upgrade package. Specifically, in this embodiment, the slave control module is the OTA terminal. The OTA cloud calls the key management service to obtain the currently valid AES encryption key that matches the target device group, which is used for encryption and verification value generation of the differential packet. Based on the version dependency of the target firmware, a compatibility declaration is embedded in the upgrade package metadata, which is part of the security upgrade package.

[0023] Preferably, in step S1, generating a differential package including a board number identifier and a function number includes: S11: The OTA cloud uses the BSDiff differential algorithm to compare the current firmware version with the target firmware version and generate an initial differential package (i.e., a patch package). Specifically, in this embodiment, the OTA cloud receives an upgrade instruction, which specifies the type of the target slave control module to be upgraded (e.g., a grinding controller) and the target firmware version number to which the module needs to be upgraded. S12: The OTA cloud adds a firmware identifier, including the board number, version number, and function number, to the header of the initial differential packet. It then compresses the patch packet using the LZ77 compression algorithm to generate a differential upgrade package. Specifically, in this embodiment, the Hex file of the firmware to be upgraded is converted into a Bin file, which serves as the base file for generating the firmware upgrade package. Please refer to [link to relevant documentation]. Figure 5 As shown, the firmware identifier is 4 bytes long, using big-endian format, and is divided into three parts: a fixed value (2 bytes): for example, "48 69", used as the basic identifier for firmware validity; a module sub-function number (1 byte): distinguishing different functional modules, such as "00 cup dropper with cutter", "01 bar cup dropper module", etc., clarifying the scope of the upgrade function; and a board number / RS485 default address (1 byte): corresponding to the hardware module, such as "01 main control board", "0B new cup dropper", etc., determining the target hardware for the upgrade. In the coffee kiosk OTA upgrade process, it is used to accurately identify the compatible module (matching the board number) and functional scope (matching the sub-function number) of the upgrade package, ensuring that the secure upgrade package can be accurately sent to the corresponding slave control module and avoiding incompatible upgrades. S13: The OTA cloud uses the AES encryption algorithm to encrypt the differential upgrade package after adding the firmware identifier to obtain an encrypted differential package. At the same time, it calls the verification algorithm to calculate the verification value of the encrypted differential package. Specifically, in this embodiment, the firmware upgrade package generation tool is called to load the currently valid AES key obtained from the key management service, encrypt the Bin file, and generate an encrypted differential package containing differential information by combining the board number identifier and function number. The verification value is generated using a hash algorithm. S14: The OTA cloud encapsulates the encrypted differential packet, checksum, and firmware version information, including the new firmware version number and release time, into a complete security upgrade package. Specifically, in this embodiment, the packaged Dat file is generated after encapsulation.

[0024] Based on the 485 address definition, the board number field definition is shown in Table 1 below: Table 1: Board Number Field Board number / address Alias / Device Type illustrate 0x01 motherboard 0x02 Drop cup, pre-press powder 0x03 Add the batter and butter later, and make ice. 0x04 Stir 0x05 Pressure cap 0x06 1 cup 0x06 2 cups Same as cup 1 0x08 Temperature acquisition 0x09 coffee kiosk 0x0A Pre-dip slurry 0x0B Newly added cup powder particles 0x0C New cap 1 0x0D Drop cap and press cap 0x0E Cup and lid integrated 0x0F Power control 0x11 Milkway control board 0x12 Waterway control board The function number field is shown in Table 2 below: Table 2: Function Number Field Module Function number Alias illustrate Newly added cup powder particles 0x00 There is a control panel for cutting buckets and dropping cups. Successful cup drop detection 0x01 Bar counter cup drop module Successful detection without cup dropping 0x02 New five-barrel uncut barrel drop cup Successful cup drop detection Pour out the cup 0x00 542J controller dispenses cup Stepper motor version 0x01 556C controller dispenses cup Stepper motor version 0x02 EMC Cup DC motor version New cap 0x00 Cylinder gland with temperature control Preferably, before executing the upgrade process, the slave control module also includes verifying the firmware identifier in the security upgrade package: The APP program (Bootloader program) reads the hardware configuration information stored in its own memory. The hardware configuration information includes the local board number and the pre-configured local function number. After the hardware matching verification is passed, the APP program (Bootloader program) further parses the version dependency declaration and firmware identifier in the security upgrade package, extracts the upgrade package board number and upgrade package function number, and specifically, in this embodiment, performs version compatibility verification. Compare the local board number with the upgrade package board number, the local function number, and the upgrade package function number; If the board number is inconsistent or the function number is incompatible, the upgrade process will be terminated and an error code will be returned. If the comparison is consistent, the subsequent upgrade steps will continue. Specifically, in this embodiment, the Bootloader version (local version) is not lower than the minimum version required in the declaration, the local hardware driver version is in the declared compatibility list, and the current application version (function number) is within the declared range of allowed upgrade source versions. If any of the above verifications fails, the upgrade will be terminated immediately and a detailed version incompatibility error code will be returned.

[0025] S2: The OTA cloud sends the security upgrade package to the coffee kiosk main control board, which then forwards the security upgrade package to the target slave control module. Specifically, in this embodiment, the coffee kiosk main control board receives the differential upgrade package through a TLS encrypted channel and uses the AES key pre-installed in its secure storage area through a key lifecycle management mechanism to AES decrypt the differential upgrade package. Please refer to [link to relevant documentation]. Figure 6 As shown, the flash memory of the coffee kiosk's main control board is divided into a Bootloader area, an APP area, and a dynamic buffer. The Bootloader area, located on Page 0 (addresses 0x0800 0000-0x0800 8000), is the first program to run when the system starts, responsible for core processes such as firmware upgrades and application startup. The CFG (configuration area), adjacent to the Bootloader area, stores system configuration information and is the physical storage location for the detailed configuration structure on the right. The APP (application area) occupies most of the middle storage area (e.g., Pages 20 to 92) and stores the device's application firmware. The BKP1 (backup area), located in the high address region (Pages 92 to 127, addresses 0x0802 5000-0x0803), is also located in the high address region. The Bootloader partition (CFG_BKP1) is used for firmware backup and implements a rollback mechanism in case of upgrade failure. The CFG partition is further divided into two sub-regions: CFG_APP and CFG_BKP1, which manage the configuration information of the application and backup areas respectively. Each configuration includes the following fields: CHK: Verification identifier, used to verify the legality of the configuration data; ADDR: Starting address of the corresponding partition, enabling precise location of the storage area; PCBType: Hardware type identifier, ensuring compatibility between the configuration and the hardware; CRC: Cyclic Redundancy Check value, ensuring the integrity of the configuration data; SIZE: Partition data size, used for controlling the range of data read and write; DevID: Device ID, enabling differentiated management in multi-device scenarios. In addition, a write progress marker storage area is specially added to the Bootloader partition's configuration information to record the real-time progress of data writing to the main program area during firmware upgrades. This marker area uses non-volatile storage to ensure that data is not lost after power failure, providing crucial status information for the power failure recovery mechanism. Simultaneously, a secure key storage area is also provided in the CFG partition to store AES key materials initialized and updated through the key lifecycle management mechanism. Access to this area is protected by hardware or software mechanisms.

[0026] S3: The target slave module's APP program receives the security upgrade package. During the receiving process, it performs line-level verification and temporarily stores the verified data in the slave module's dynamic buffer. If the verification fails, the upgrade process stops. Specifically, in this embodiment, the received encrypted data line is decrypted using the AES key stored locally through a security mechanism. The board number and module number in the firmware identifier are verified to match the current device. If they do not match, the upgrade process is terminated.

[0027] Please see Figure 7 and Figure 8 As shown, in step S3, line-level verification is performed during the receiving process, and the verified data is temporarily stored in the dynamic buffer of the slave control module, including: S31: The APP program receives the data of the security upgrade package line by line according to the preset data line length in the security upgrade package, and starts an independent timeout timer for each line received. After each line of complete data is received, the preset verification algorithm is immediately called to calculate the checksum of the data of that line. Specifically, in this embodiment, the upgrade firmware package (Dat document) is opened, the upgrade package line number N is initialized to 0, and the Nth line of data is read line by line. If the first byte of the line is a # symbol, the data of that line is decrypted first and then sent; otherwise, the data of that line is sent directly, and then the program waits for the response from the lower-level machine. S32: The APP program extracts the preset checksum carried in the currently received data line and compares the checksum with the preset checksum for consistency. S33: If the comparison results are inconsistent, the upgrade process is stopped immediately, and an upgrade failure response containing the error code and the failed line number is returned to the main control board. Specifically, in this embodiment, if the error code is 0x06 / 0x011: the upgrade process is stopped, and a verification failure error is returned to the host computer. If the error code is 0x01 / 0x010 or the response times out: if the number of resends for this line is less than 3, the line is resent; otherwise, the process is stopped and a failure is reported. S34: If the comparison results are consistent, the target write address corresponding to the line of data is determined according to the address allocation rules of the dynamic buffer, and the line of data is written to the target address of the dynamic buffer. Specifically, in this embodiment, an error code of 0 indicates normal operation and the next step is continued. An error code of "other" indicates that the process is processed according to the flow logic. The line number N is incremented (N=N+1). If N is less than the total number of lines in the file, the "read-send-response processing" is executed in a loop. Otherwise, it is determined that the upgrade package has been sent, and a software reset command is sent as needed, and the process ends. S35: After the data is written, perform a readback verification to ensure that the write is correct; S36: When the first line of data is received and verified, the APP program first performs a complete sector erasure operation on the target sector in the dynamic buffer to store the data, clearing the old data remaining in the sector; the subsequently received verified data is written into the dynamic buffer in ascending order of the target address, without repeating the sector erasure. Specifically, in this embodiment, the storage sector of the backup area (BKP) is cleared to prepare for the writing of new data, and the currently running application firmware is written into the BKP sector.

[0028] S4: After the security upgrade package is received, the APP program sets the upgrade flag and resets the device. The Bootloader program writes the upgrade package data in the dynamic buffer into the main program area and performs a final verification on the written firmware. Specifically, in this embodiment, the integrity of the firmware written into the backup area is verified to ensure the backup is effective. The firmware configuration information (CONFIG) is synchronously written into the backup area to ensure the consistency between the configuration and the firmware. The system or host computer is asked to confirm that the backup is complete. After the backup is completed, the device is reset and enters the Bootloader process to prepare for subsequent upgrade or startup operations.

[0029] Please see Figure 8 As shown, in step S4, the Bootloader program writes the upgrade package data from the dynamic buffer into the main program area and performs final verification of the written firmware, including: S41: After the slave module is reset, the Bootloader program first reads the upgrade flag in the designated storage area of ​​the slave module and determines whether the upgrade flag is in a preset valid state. If the upgrade flag is invalid, the Bootloader program directly guides the slave module to run the firmware in the current main program area. Specifically, in this embodiment, after the device is reset, the Bootloader program first runs to determine whether the backup area has a device identifier configuration (Config-DevID). If it does not exist, it directly jumps to "Waiting for serial port firmware upgrade process"; if it exists, it proceeds to the next step; it performs CRC16 verification on the firmware data in the backup area to verify data integrity. If the verification fails, it also jumps to "Waiting for serial port firmware upgrade process"; if successful, it proceeds to the next step; it copies the firmware data in the backup area to the application running area (APP area); it verifies the firmware data in the running area again to ensure that the copying process is error-free. If the verification fails, it proceeds to "Initialize serial port → LED flashing → Waiting for serial port firmware upgrade process"; if successful, it proceeds to the next step; it clears the configuration flag in the backup area to avoid repeatedly executing the backup and recovery process; it guides the device to run the user application and completes normal startup. S42: If the upgrade flag is valid, the Bootloader program performs a sector erasure operation on the target storage area in the main program area where the new firmware is to be written. After erasure, it verifies whether the sector is erased cleanly. If it is not erased cleanly, the erasure is re-executed. Specifically, in this embodiment, if the upgrade flag is valid, the Bootloader program further reads the write progress marker to determine whether there is an incomplete upgrade task: if there is a valid write progress marker, it directly enters step S43 to execute breakpoint continuation writing according to the breakpoint position recorded by the marker (such as the written sector number and data block offset); if there is no breakpoint or the marker is invalid, the complete sector erasure process is executed: the sector erasure operation is performed on the target storage area in the main program area where the new firmware is to be written. After erasure, it verifies whether the sector is erased cleanly. If it is not erased cleanly, the erasure is re-executed. S43: After the sector erase verification is successful (or the erased sector is skipped in breakpoint resume mode), the Bootloader program reads the security upgrade package data continuously from the dynamic buffer in ascending order of address, and moves it in batches to the target storage area of ​​the main program area to ensure the continuity and integrity of data movement. During the movement process, the Bootloader program immediately updates the write progress flag and records the current write position and status after each successful write of a complete data block (such as a sector). S44: After the data transfer is completed, the Bootloader program reads the complete data of the new firmware that has been written in the main program area, calls the preset overall verification algorithm, and calculates the overall verification value of the new firmware. S45: The Bootloader program parses the target verification information carried in the upgrade package and compares the overall verification value with the target verification information for consistency. S46: If the comparison results are consistent, the final verification is deemed successful. The Bootloader program updates the firmware validity flag in the main program area and prepares to jump to the new firmware for execution. If the comparison results are inconsistent, the final verification is deemed unsuccessful. The firmware rollback mechanism is immediately triggered to terminate the startup of the new firmware.

[0030] Preferably, triggering the firmware rollback mechanism includes: If the final verification fails, the Bootloader program will immediately reset the upgrade flag in the storage area specified by the slave module to an invalid state; The bootloader program switches the program access address to the backup program area of ​​the slave module, calls the boot process of the old firmware stored in the backup program area, and attempts to boot the old firmware. The bootloader program determines whether the old firmware has started successfully by detecting the reset vector integrity and initialization completion signal of the old firmware. If the old firmware is detected as ready within a preset time, the startup is considered successful, and the control module is restored to its normal working state before the upgrade, and can respond normally to the function control commands of the coffee kiosk. After the old firmware boots successfully, the Bootloader program records the relevant information of this upgrade failure in the non-volatile log storage area of ​​the slave control module. The log content includes the upgrade failure timestamp, target firmware version number, old firmware version number, failure reason, and comparison result of the new firmware verification value in the main program area with the target verification information. After returning the upgrade failure result to the main control board, the Bootloader program shuts down its own running resources, transfers system control to the old firmware, and the slave module maintains normal working status, waiting for the main control board to forward the next OTA upgrade command.

[0031] S5: If the final verification passes, the slave module runs the new firmware and clears the dynamic buffer and upgrade flag. If the final verification fails, the bootloader program rolls back to the old firmware and clears the upgrade flag.

[0032] In a power outage recovery scenario, if an unexpected power outage occurs during step S43, the Bootloader program will detect that the upgrade flag is valid and there are incomplete write progress markers after the device is powered on again. At this time, the Bootloader program will not restart the entire upgrade process, but will continue writing from the breakpoint according to the markers until all data transfer is complete. If an exception occurs during the breakpoint continuation writing process (such as data verification failure, address out of bounds, etc.), the Bootloader program will immediately stop writing, clear the progress markers, and trigger the firmware rollback mechanism to ensure the system is safely restored to the old firmware version.

[0033] Preferably, the method further includes batch upgrade management: The OTA cloud platform pre-builds and maintains a multi-dimensional mapping relationship library. The mapping relationship library stores the association relationship between coffee kiosk device model, slave control module type, slave control module hardware architecture, target firmware version and corresponding differential package. It also supports dynamic updating of the mapping relationship library when adding a new device model or iterating the firmware version. Specifically, in this embodiment, the OTA cloud platform supports firmware version management for multiple hardware architectures such as ARM and MIPS. Maintenance personnel input upgrade configuration commands through the visual management interface of the OTA cloud platform; The OTA cloud platform responds to the upgrade configuration command and sends a board number query request to the main control board of each coffee kiosk in the target device group. It determines the corresponding hardware architecture through the slave control module board number fed back by the main control board, and then matches compatible differential packages for slave control modules with different hardware architectures based on the mapping relationship library. The OTA cloud platform sends upgrade instructions and matching differential packets to the target device group in batches according to the preset distribution strategy, and starts the real-time monitoring process. It collects upgrade status data of each device in real time through bidirectional communication links. The upgrade status data includes upgrade instruction reception status, differential packet transmission progress, row-level verification results, data writing status, final verification results, and rollback status. The OTA cloud platform aggregates the upgrade results of each device and generates upgrade result statistics, including the total number of upgraded devices, the number of successful upgrades, the number of failed upgrades, the classification of failure reasons, and the upgrade success rate. For devices that fail to upgrade, the platform automatically triggers a retry mechanism and reissues upgrade instructions and differential packages according to preset rules. If the upgrade still fails after retrying, the platform marks the device as an abnormal upgrade device and pops up a window to prompt maintenance personnel to handle it.

[0034] Preferably, the upgrade configuration command includes: The target equipment group is selected according to preset screening conditions, and the type of slave control module to be upgraded is specified. The slave control module type includes, but is not limited to, heating control module, grinding control module, and water outlet control module.

[0035] Even better, it also includes offline upgrade support mode: When the OTA cloud platform is unavailable for an extended period due to network or maintenance issues, or when emergency on-site repairs are required, maintenance personnel can generate an encrypted and integrity-verified offline upgrade package file from the platform and copy it to a USB flash drive. After inserting the USB flash drive into the main control board's USB port, the main control board automatically detects and verifies the legality of the offline upgrade package (including board number, version compatibility, encryption, and verification). Upon successful verification, the main control board will simulate the cloud-based distribution process, taking over the subsequent upgrade package forwarding and control flow, guiding the target slave module to complete the offline upgrade. This mode does not rely on a wide area network connection and is suitable for network isolation environments or emergency recovery scenarios.

[0036] Second Embodiment Based on the same concept, this embodiment also provides a computer device, including a memory and a processor, wherein the memory stores computer-readable instructions, which, when executed by the processor, cause the processor to perform the steps of a remote OTA upgrade method for a coffee kiosk as described in the embodiment.

[0037] Based on the same concept, the present invention also provides a storage medium storing computer-readable instructions, characterized in that, when the computer-readable instructions are executed by one or more processors, the one or more processors cause the one or more processors to perform the steps of a remote OTA upgrade method for a coffee kiosk as described in any one of the embodiments.

[0038] It is understood that, regarding the aforementioned remote OTA upgrade method for coffee kiosks, if all components are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer server or a network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0039] Computer-readable storage media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable storage medium may also be any readable medium other than a readable storage medium, capable of transmitting, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof. The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principle of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A remote OTA upgrade method for coffee kiosks, characterized in that, Includes the following steps: S1: The OTA cloud generates a differential packet containing board number identifier and function number based on the current firmware version and target firmware version of each slave control module of the coffee kiosk, and encrypts the differential packet to form a security upgrade package. S2: The OTA cloud sends the security upgrade package to the coffee kiosk main control board, and the coffee kiosk main control board forwards the security upgrade package to the target slave control module; S3: The APP program of the target slave module receives the security upgrade package, performs row-level verification during the receiving process, and temporarily stores the data that passes the verification into the dynamic buffer of the slave module. If the verification fails, the upgrade process is stopped. S4: After the security upgrade package is received, the APP program sets the upgrade flag and resets the device. The Bootloader program writes the upgrade package data in the dynamic buffer into the main program area and performs final verification on the written firmware. S5: If the final verification passes, the slave control module runs the new firmware and clears the dynamic buffer and upgrade flag. If the final verification fails, the bootloader program rolls back to the old firmware and clears the upgrade flag.

2. The remote OTA upgrade method for coffee kiosks according to claim 1, characterized in that, In step S1, generating the differential package, which includes the board number identifier and the function number, includes: S11: The OTA cloud uses a differential algorithm to compare the current firmware version with the target firmware version to generate an initial differential packet; S12: The OTA cloud adds a firmware identifier, including a board number field and a function number field, to the header of the initial differential packet; S13: The OTA cloud uses the AES encryption algorithm to encrypt the differential packet after adding the firmware identifier to obtain an encrypted differential packet, and at the same time calls the verification algorithm to calculate the verification value of the encrypted differential packet; S14: The OTA cloud encapsulates the encrypted differential packet, the verification value, and firmware version information, including the new firmware version number and version release time, into a complete security upgrade package.

3. The remote OTA upgrade method for coffee kiosks according to claim 1, characterized in that, Before executing the upgrade process, the slave module also includes verifying the firmware identifier in the security upgrade package: The APP program reads its own stored hardware configuration information, which includes the local board number and the pre-configured local function number. The APP program parses the firmware identifier in the security upgrade package and extracts the upgrade package board number and upgrade package function number; Compare the local board number with the upgrade package board number, the local function number, and the upgrade package function number; If the board number is inconsistent or the function number is incompatible, the upgrade process will be terminated and an error code will be returned. If they match, the subsequent upgrade steps will continue.

4. The remote OTA upgrade method for coffee kiosks according to claim 1, characterized in that, In step S3, line-level verification is performed during the receiving process, and the verified data is temporarily stored in the dynamic buffer of the slave control module, including: S31: The APP program receives the data of the security upgrade package line by line according to the preset data line length in the security upgrade package. After receiving each complete line of data, it immediately calls the preset verification algorithm to calculate the checksum of the data in that line. S32: The APP program extracts the preset checksum carried in the currently received data line and compares the checksum with the preset checksum for consistency. S33: If the comparison results are inconsistent, the upgrade process will be stopped immediately, and an upgrade failure response containing the error code and the failure line number will be returned to the main control board. S34: If the comparison results match, then according to the address allocation rules of the dynamic buffer, determine the target write address corresponding to the row of data, and write the row of data to the target address of the dynamic buffer; S35: After the data is written, perform a readback verification to ensure that the write is correct; S36: When the first line of data is received and verified, the APP program first performs a complete sector erasure operation on the target sector in the dynamic buffer to store the data, clearing the old data remaining in the sector; the subsequently received verified data is written into the dynamic buffer in ascending order of the target address, without repeating the sector erasure.

5. The remote OTA upgrade method for coffee kiosks according to claim 1, characterized in that, In step S4, the Bootloader program writes the upgrade package data from the dynamic buffer into the main program area and performs final verification of the written firmware, including: S41: After the slave module is reset, the bootloader program first reads the upgrade flag bit in the specified storage area of ​​the slave module and determines whether the upgrade flag bit is in a preset valid state. If the upgrade flag bit is in an invalid state, the bootloader program directly guides the slave module to run the firmware in the current main program area. S42: If the upgrade flag is valid, the Bootloader program performs a sector erasure operation on the target storage area in the main program area where the new firmware is to be written. After erasure, it verifies whether the sector is erased cleanly. If it is not erased cleanly, it performs erasure again. S43: After the sector erase verification is passed, the Bootloader program reads the security upgrade package data from the dynamic buffer continuously in ascending order of the address of the dynamic buffer, and moves it in batches to the target storage area of ​​the main program area to ensure the continuity and integrity of data transfer. S44: After the data transfer is completed, the Bootloader program reads the complete data of the new firmware that has been written in the main program area, calls the preset overall verification algorithm, and calculates the overall verification value of the new firmware. S45: The Bootloader program parses the target verification information carried in the upgrade package and performs a consistency comparison between the overall verification value and the target verification information; S46: If the comparison results are consistent, the final verification is deemed successful. The Bootloader program updates the firmware validity flag in the main program area and prepares to jump to the new firmware for execution. If the comparison results are inconsistent, the final verification is deemed unsuccessful. The firmware rollback mechanism is immediately triggered to terminate the startup of the new firmware.

6. The remote OTA upgrade method for coffee kiosks according to claim 5, characterized in that, The firmware rollback triggering mechanism includes: If the final verification fails, the Bootloader program will immediately reset the upgrade flag in the storage area specified by the slave module to an invalid state; The bootloader program switches the program access address to the backup program area of ​​the slave module, calls the boot process of the old firmware stored in the backup program area, and attempts to boot the old firmware. The bootloader program determines whether the old firmware has started successfully by detecting the reset vector integrity and initialization completion signal of the old firmware. If the old firmware is detected as ready within a preset time, the startup is considered successful, and the control module is restored to its normal working state before the upgrade, and can respond normally to the function control commands of the coffee kiosk. After the old firmware boots successfully, the Bootloader program records the relevant information of this upgrade failure in the non-volatile log storage area of ​​the slave control module. The log content includes the upgrade failure timestamp, target firmware version number, old firmware version number, failure reason, and comparison result of the new firmware verification value in the main program area with the target verification information. After returning the upgrade failure result to the main control board, the Bootloader program shuts down its own running resources, transfers system control to the old firmware, and the slave module maintains normal working status, waiting for the main control board to forward the next OTA upgrade command.

7. The remote OTA upgrade method for coffee kiosks according to claim 1, characterized in that, The method also includes batch upgrade management: The OTA cloud platform pre-builds and maintains a multi-dimensional mapping relationship library. The mapping relationship library stores the association relationship between coffee kiosk equipment model, slave control module type, slave control module hardware architecture, target firmware version and corresponding differential package, and supports dynamic updating of the mapping relationship library when adding a new equipment model or iterating the firmware version. Maintenance personnel input upgrade configuration commands through the visual management interface of the OTA cloud platform; The OTA cloud platform responds to the upgrade configuration command by sending a board number query request to the main control board of each coffee kiosk in the target device group. It determines the corresponding hardware architecture through the slave control module board number fed back by the main control board, and then matches compatible differential packages for slave control modules with different hardware architectures based on the mapping relationship library. The OTA cloud platform sends upgrade instructions and matching differential packets to the target device group in batches according to the preset distribution strategy, and starts the real-time monitoring process. It collects upgrade status data of each device in real time through the bidirectional communication link. The upgrade status data includes upgrade instruction reception status, differential packet transmission progress, row-level verification results, data writing status, final verification results, and rollback status. The OTA cloud platform aggregates the upgrade results of each device and generates upgrade result statistics, which include the total number of upgraded devices, the number of successful upgrades, the number of failed upgrades, the classification of failure reasons, and the upgrade success rate. For devices that fail to upgrade, the platform automatically triggers a retry mechanism, re-issuing upgrade instructions and differential packages according to preset rules; if the upgrade still fails after retrying, the platform marks the device as an abnormal upgrade device and pops up a window to prompt maintenance personnel to handle it.

8. The remote OTA upgrade method for coffee kiosks according to claim 1, characterized in that, The upgrade configuration instructions include: The target equipment group is selected according to preset screening conditions, and the type of slave control module to be upgraded is specified. The slave control module type includes, but is not limited to, heating control module, grinding control module, and water outlet control module.

9. A computer device, characterized in that, The device includes a memory and a processor, wherein the memory stores computer-readable instructions that, when executed by the processor, cause the processor to perform the steps of a remote OTA upgrade method for a coffee kiosk as described in any one of claims 1 to 8.

10. A storage medium storing computer-readable instructions, characterized in that, When the computer-readable instructions are executed by one or more processors, the one or more processors perform the steps of a remote OTA upgrade method for a coffee kiosk as described in any one of claims 1 to 8.

Images