Bootloader method based on small-capacity Flash design

Abstract

The invention discloses a Bootloader method based on a small-capacity Flash design. The Bootloader method comprises the following steps: S1, setting a starting address and a stopping address of a corresponding partition through a boot program in an MCU (Microprogrammed Control Unit) or a corresponding link file, and carrying out partition configuration on the Flash; through fine partition division, peripheral function cutting and protocol flow simplification, Bootloader development of ultra-small code quantity is realized, meanwhile, expansibility and flexibility of products can be extended, communication protocols in a company are unified, tedious adaptation and compatibility for compatibility with protocols of old equipment are not needed, and if it is found that BUG exists in an MCU, the communication protocol of the company can be compatible with the communication protocol of the old equipment. And the local technology does not need to support on-site upgrading, or the product is not required to be sent back to an updating program, or is not required to be disassembled for programming, so that the sustainable development of the product is greatly expanded, and the maintenance cost of the product of a company is saved.

Description

Technical Field

[0001] The invention relates to the technical field of building intercom equipment, and in particular to a Bootloader method based on small-capacity Flash design. Background Art

[0002] In the existing building intercom equipment, there is at least one or more MCU chips to process different functions, such as keypad, card swiping, Bluetooth door opening, sleep wake-up and other independent modules. Therefore, when selecting chips, MCUs with small-capacity Flash are generally selected. As a result, the official bootloader method is not applicable, resulting in these MCUs not supporting remote functions. The program is solidified in the device after leaving the factory. If the program needs to be updated, it needs to be updated through a dedicated burning tool and burned after disassembly. If the old protocol is incompatible with a new protocol formulated by a third-party customer or a new product, it is necessary to redevelop a product or return it to the factory for update. This will cause a waste of the company's product maintenance costs and labor costs. For this reason, this application proposes a Bootloader method based on small-capacity Flash design. Summary of the invention

[0003] Based on the technical problems existing in the background technology, the present invention proposes a Bootloader method based on small-capacity Flash design.

[0004] The present invention proposes a Bootloader method based on a small-capacity Flash design, comprising the following steps:

[0005] S1: Set the starting address and ending address of the corresponding partition through the boot program in the MCU or the corresponding link file to partition the Flash;

[0006] S2: For MCUs that do not support custom interrupt vectors, a fixed address is used. The interrupt address needs to be redirected by Flash address positioning. For MCUs that support custom interrupt vectors, it is directly set to 0x00 on the bootloader side and placed in the front position.

[0007] S3: Design the software upgrade function. The specific upgrade design process includes the following steps:

[0008] S301: The cloud server issues a request for software upgrade in the device;

[0009] S302: The CPU waits for an upgrade instruction. If no upgrade instruction is received, it indicates a timeout and the device needs to be restarted.

[0010] S303: After receiving the instruction, the CPU downloads it to the Flash or EMMC via Ethernet or WiFi, and sends the firmware to the MCU according to the established protocol via the UART, I2C, or SPI bus;

[0011] S304: The MCU parses the instruction sent by the CPU. After the MCU parses the instruction as an upgrade command, it modifies the flag data of the Flag partition and determines whether the current packet is the last packet. If so, it rewrites the Flag partition parameters. After the write is successful, it exits the boot mode and then hard restarts the device through the device watchdog.

[0012] S305: After the device is powered on, it enters the boot mode first, and then determines whether it stays in the bootloader program through the flag of the Flag partition;

[0013] S306: Initialize the uart and watchdog peripheral modules, and burn the program through the pre-negotiated upgrade protocol;

[0014] S307: Parse the upgrade data, where the first frame is the firmware parameter information: data[0]: chunks indicates the total number of blocks, each block is 64 bytes, data[1] / data[2]: crc is the check value, data[3] is the XOR check value, and the second frame and the following are the firmware data;

[0015] S308: After parsing, the software is upgraded in the bootloader mode, and during the upgrade process, the watchdog timeout is used as a reset device state.

[0016] Preferably, in S1, the Flash is partitioned and configured in order to solidify the upgrade program bootloader at a fixed address in the Flash. The Bootloader is used to guide the startup and upgrade functions of the APP function program. The APP mainly stores the business function program. The Flash is a flag for storing the power-on operation mode. When the value of the corresponding address is the special flag 0x55AA55AA, the upgrade mode is entered.

[0017] Preferably, in S2, the interrupt vector table in the MCU chip is generally fixed, and a part of it supports setting the offset address. For the MCU, the bootloader and the app are completely independent programs, and their interrupt vector addresses need to be completely independent. When the MCU supports custom interrupt vectors, the app can customize the offset address, and its custom offset address only needs to be not in the program space of the bootloader.

[0018] Preferably, in S2, when redirecting the interrupt address of the MCU, a RAM method can be used for relocation.

[0019] Preferably, in S306, the program to be burned includes a UART packet protocol format, an upgrade command and upgrade data, and the UART packet protocol format is as follows:

[0020] typedef struct{

[0021] uint8_t sync;

[0022] uint8_t length;

[0023] uint8_t cmd;

[0024] uint8_t data

[64] ; / / data[length-4] is the XOR value of other data

[0025] }mcu_cmd_t;

[0026] The upgrade command is CMD:0x06, and the upgrade data is CMD:0x07.

[0027] Preferably, in S308, the watchdog timeout period is set to 216 ms.

[0028] Preferably, in S305, the bootloader program is divided into a boot function and a firmware loading and burning loader function.

[0029] Compared with the prior art, the present invention has the following beneficial effects:

[0030] The present invention realizes the development of Bootloader with ultra-small code volume through fine partition division, peripheral function tailoring and simplified protocol flow, and can also extend the scalability and flexibility of the product, unify the communication protocol within the company, and eliminate the need for tedious adaptation and compatibility for the protocol of old equipment. If a bug is found in the MCU, there is no need to ask local technical support to upgrade on-site, or send the product back for updating the program, or disassemble and burn it, which greatly expands the sustainable development of the product and saves the company's product maintenance costs. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 A flowchart of a Bootloader method based on a small-capacity Flash design proposed by the present invention;

[0032] Figure 2The present invention provides a flowchart for designing a software upgrade function in a Bootloader method based on a small-capacity Flash design. DETAILED DESCRIPTION

[0033] The present invention will be further explained below in conjunction with specific embodiments.

[0034] Example

[0035] Reference Figure 1-2 This embodiment proposes a Bootloader method based on a small-capacity Flash design, including the following steps:

[0036] S1: Set the starting address and ending address of the corresponding partition through the boot program in the MCU or the corresponding link file to partition the Flash;

[0037] The purpose of configuring Flash partitions is to solidify the upgrade program bootloader at a fixed address in Flash. Bootloader is used to guide the startup and upgrade functions of APP function programs. APP mainly stores business function programs. Flash is used to store the power-on operation mode flag. When the corresponding address value is 0x55AA55AA special flag, it enters the upgrade mode.

[0038] For example, take the STML103 MCU chip as an example. This MCU has 8KB of programmable Flash space, of which 6KB can be used to store code segments and data (global variables and static variables) segments, and the other 2KB is EEPROM which can only store data. Since the bootloader program cannot be too large, otherwise it will waste MCU resources, the reserved space should be relatively small. The ROM is divided into Bootloader: 0x8000-0x86FF, a total of 1792Byte; APP: 0x8700-0x97BF, a total of 4288Byte; Flag: 0x97c0-0x97ff, a total of 64Byte;

[0039] S2: For MCUs that do not support custom interrupt vectors, a fixed address is used. The interrupt address needs to be redirected by Flash address positioning. For MCUs that support custom interrupt vectors, it is directly set to 0x00 on the bootloader side and placed in the front position. When redirecting the interrupt address of the MCU, RAM can also be used for relocation;

[0040] The interrupt vector table in the MCU chip is generally fixed, and some of them support setting the offset address. For the MCU, the bootloader and the app are completely independent programs, and their interrupt vector addresses need to be completely independent. When the MCU supports custom interrupt vectors, the app can customize the offset address as long as the custom offset address is not in the program space of the bootloader;

[0041] S3: Design the software upgrade function. The specific upgrade design process includes the following steps:

[0042] S301: The cloud server issues a request for software upgrade in the device;

[0043] S302: The CPU waits for an upgrade instruction. If no upgrade instruction is received, it indicates a timeout and the device needs to be restarted.

[0044] S303: After receiving the instruction, the CPU downloads it to the Flash or EMMC via Ethernet or WiFi, and sends the firmware to the MCU according to the established protocol via the UART, I2C, or SPI bus;

[0045] S304: The MCU parses the instruction sent by the CPU. After the MCU parses the instruction as an upgrade command, it modifies the flag data of the Flag partition and determines whether the current packet is the last packet. If so, it rewrites the Flag partition parameters. After the write is successful, it exits the boot mode and then hard restarts the device through the device watchdog.

[0046] S305: After the device is powered on, it enters the boot mode first, and then determines whether it stays in the bootloader program through the flag of the Flag partition. The bootloader program is divided into the boot function and the firmware loading and burning loader function;

[0047] S306: Initialize the uart and watchdog peripheral modules, and burn the program through the pre-negotiated upgrade protocol;

[0048] The program to be burned includes the UART packet protocol format, upgrade command and upgrade data. The UART packet protocol format is as follows:

[0049] typedef struct{

[0050] uint8_t sync;

[0051] uint8_t length;

[0052] uint8_t cmd;

[0053] uint8_t data

[64] ; / / data[length-4] is the XOR value of other data

[0054] }mcu_cmd_t;

[0055] The upgrade command is CMD:0x06, and the upgrade data is CMD:0x07;

[0056] S307: Parse the upgrade data, where the first frame is the firmware parameter information: data[0]: chunks indicates the total number of blocks, each block is 64 bytes, data[1] / data[2]: crc is the check value, data[3] is the XOR check value, and the second frame and the following are the firmware data;

[0057] S308: After parsing, the software is upgraded in the bootloader mode. During the upgrade process, the watchdog timeout is used as a reset device state, and the watchdog timeout is set to 216ms.

[0058] This embodiment achieves the development of Bootloader with ultra-small code volume through fine partitioning, peripheral function cutting and simplified protocol flow, and can also extend the scalability and flexibility of the product, unify the communication protocol within the company, and eliminate the need for tedious adaptation and compatibility for the protocols of old devices. If a bug is found in the MCU, there is no need for local technical support to perform on-site upgrades, or to send the product back for program updates, or to disassemble and burn it, which greatly expands the sustainable development of the product and saves the company's product maintenance costs.

[0059] The above description is only a preferred specific implementation manner of the present invention, but the protection scope of the present invention is not limited thereto. Any technician familiar with the technical field can make equivalent replacements or changes according to the technical scheme and inventive concept of the present invention within the technical scope disclosed by the present invention, which should be covered by the protection scope of the present invention.

Claims

1. A Bootloader method based on small capacity Flash design, characterized in that: The following steps are involved: S1: Set the starting address and ending address of the corresponding partition through the boot program in the MCU or the corresponding link file to partition the Flash; S2: For MCUs that do not support custom interrupt vectors, a fixed address is used. The interrupt address needs to be redirected by Flash address positioning. For MCUs that support custom interrupt vectors, it is directly set to 0x00 on the bootloader side and placed in the front position. S3: Design the software upgrade function. The specific upgrade design process includes the following steps: S301: The cloud server issues a request for software upgrade in the device; S302: The CPU waits for an upgrade instruction. If no upgrade instruction is received, it indicates a timeout and the device needs to be restarted. S303: After receiving the instruction, the CPU downloads it to the Flash or EMMC via Ethernet or WiFi, and sends the firmware to the MCU according to the established protocol via the UART, I2C, or SPI bus; S304: The MCU parses the instruction sent by the CPU. After the MCU parses the instruction as an upgrade command, it modifies the flag data of the Flag partition and determines whether the current packet is the last packet. If so, it rewrites the Flag partition parameters. After the write is successful, it exits the boot mode and then hard restarts the device through the device watchdog. S305: After the device is powered on, it enters the boot mode first, and then determines whether it stays in the bootloader program through the flag of the Flag partition; S306: Initialize the uart and watchdog peripheral modules, and burn the program through the pre-negotiated upgrade protocol; S307: Parse the upgrade data, where the first frame is the firmware parameter information: data[0]: chunks indicates the total number of blocks, each block is 64 bytes, data[1] / data[2]: crc is the check value, data[3] is the XOR check value, and the second frame and the following are the firmware data; S308: After parsing, the software is upgraded in the bootloader mode, and during the upgrade process, the watchdog timeout is used as a reset device state.

2. According to claim 1, a Bootloader method based on small capacity Flash design is characterized in that: In S1, the Flash is partitioned and configured in order to solidify the upgrade program bootloader at a fixed address in the Flash. The Bootloader is used to guide the startup and upgrade functions of the APP function program. The APP mainly stores the business function program. The Flash is used to store the power-on operation mode flag. When the corresponding address value is the special flag 0x55AA55AA, it enters the upgrade mode.

3. The Bootloader method based on small capacity Flash design according to claim 1, characterized in that: In S2, the interrupt vector table in the MCU chip is generally fixed, and some of them support setting the offset address. For the MCU, the bootloader and the app are completely independent programs, and their interrupt vector addresses need to be completely independent. When the MCU supports custom interrupt vectors, the app can customize the offset address, and its custom offset address only needs to be not in the program space of the bootloader.

4. The Bootloader method based on small capacity Flash design according to claim 1, characterized in that: In S2, the MCU may be redirected to an interrupt address by using a RAM method for relocation.

5. The Bootloader method based on small capacity Flash design according to claim 1, characterized in that: In S306, the program to be burned includes a UART packet protocol format, an upgrade command and upgrade data, and the UART packet protocol format is as follows: typedef struct{ uint8_t sync; uint8_t length; uint8_t cmd; uint8_t data[64]; / / data[length-4] is the XOR value of other data }mcu_cmd_t; The upgrade command is CMD:0x06, and the upgrade data is CMD:0x07.

6. The Bootloader method based on small capacity Flash design according to claim 1, characterized in that: In S308, the watchdog timeout period is set to 216 ms.

7. The Bootloader method based on small capacity Flash design according to claim 1, characterized in that: In S305, the bootloader program is divided into a boot function and a firmware loading and burning loader function.

Images