KR101640207B1 - Bootloader and embedded system upgrade method - Google Patents

Abstract

A bootloader and a method of upgrading an embedded system are disclosed. According to an embodiment of the present invention, a bootloader embedded in an embedded system to upgrade an application program recorded in a memory includes: a system initializing unit initializing hardware installed on the embedded system; and an upgrading unit communicating with a host PC through a communication module, downloading an application program image to be upgraded, and upgrading the application program. A communication code transmitted to the host PC by the upgrading unit can be set as 2 to 4 bytes, and the communication code can be transmitted by a communication protocol of the communication module.

Description

Boot loader and embedded system upgrade method {Bootloader and embedded system upgrade method}

The present invention relates to a boot loader and a method for upgrading an embedded system.

Typical 8-bit microcontrollers include 8051, PIC, and AVR.

Among them, AVR is an 8-bit microcontroller developed by Atmel of the United States. It is a high-performance, low-power processor that exhibits a more advanced RISC architecture. AVR employs the Harvard Architecture to maximize CPU throughput by isolating the system address bus for the program and the data address bus for the data.

AVR supports self-programming commands. With the help of this command, the AVR can read and write various areas of memory. In some cases, even the EEPROM area can be written and read.

FIG. 1 shows a flash memory area of an AVR, FIG. 2 shows BOOTRST and BOOTSZ fuse bits, and FIG. 3 shows a boot loader operation process.

Referring to FIG. 1, the memory area of the AVR is divided into a read-while-write (RWW) section 10 and a no-read-while-write (NRWW) section 20. On the surface, the RWW section 10 is a memory area that can be read simultaneously with writing, and the NRWW section 20 represents a memory area that is not.

This means that the NRWW section 20 can not be written with magnetic programming instructions and can only be programmed using external download equipment (e.g., ISP, JTAG, etc.).

The boot loader is located in the NRWW section 20 because if the boot loader is in the RWW section 10, the boot loader code executed by the magnetic programming command can be overwritten.

The execution process of the boot loader is as follows.

The AVR sets the boot location with a BOOTRST fuse and a BOOTSZ fuse (see FIG. 2).

Normally, the AVR starts at address 0x00 when the reset button is pressed. However, when the BOOTRST fuse is active, the starting point is changed to the point indicated by BOOTSZ instead of address 0x00. BOOTSZ is responsible for determining the size of the NRWW section along with the start address.

2, when the BOOTSZ is set to Bootflash size = 512 words, when the NRWW section is 512 words (= 1024 bytes) and BOOTRST is on, the command is read from the address 0xFE00 instead of the address 0x00 Coming.

At this time, the NRWW section 20 receives the data, writes the data to the page buffer, and writes the data to the RWW section 10 in a manner of writing to the page buffer. Thereafter, a code for jumping to address 0x00 must be additionally executed so that it can be executed in the recorded memory.

Data is usually received via the USART, but for some bootloaders it may be done using SPI communications. Combined with USART and SPI communications, it can also receive and record data from Bluetooth and WLAN (mainly using SPI).

In case of AVR bootloader, it is easy to download program without ISP equipment. It is used for the first time for university education and novice. It can download the code using boot loader in the environment where it can not carry around with ISP equipment. do.

However, the boot loader alone has its limitations. First, in the case of AVR debugging, JATG overwrites the entire memory in the process of debugging, so that the pre-recorded boot loader can be deleted in this process. The same is true for downloading to an ISP.

Since the boot loader is a program that occupies memory capacity, if the size of the program is large, it invades the boot loader area. If the size of the program is large, the memory capacity shown in the AVR specification can not be used.

The above-described background technology is technical information that the inventor holds for the derivation of the present invention or acquired in the process of deriving the present invention, and can not necessarily be a known technology disclosed to the general public prior to the filing of the present invention.

As a prior art related to the boot loader, Korean Patent Laid-Open No. 10-2010-0136111 (boot method and apparatus for debugging in a portable terminal) discloses a technique of booting so that the boot loader area and the operating system area do not overlap each other.

Korean Patent Publication No. 10-2010-0136111

The present invention relates to a boot loader and an embedded system upgrading method which enables stable operation by enhancing compatibility with a memory structure of a PC x86 architecture by preserving a conventional HEX file by deactivating automatic download upon connection and changing a communication protocol .

The present invention is intended to provide a boot loader and an embedded system upgrade method which improves user convenience through log segmentation and resets registers after downloading to reduce potential compatibility problems.

Other objects of the present invention will become readily apparent from the following description.

According to an aspect of the present invention, there is provided a boot loader built in an embedded system for upgrading an application program recorded in a memory, the system comprising: a system initialization unit for initializing hardware installed in the embedded system; And an upgrading unit for communicating with the host PC through the communication module to upgrade the application program to download the application program image to be upgraded, wherein the communication code transmitted by the upgrading unit to the host PC according to the communication protocol through the communication module And the boot loader is set to 2 to 4 bytes.

When the communication with the host PC is completed, the upgrading unit can reset the register set for communication.

The upgrading unit may automatically cancel establishment of a communication connection through the communication module after upgrading the application program.

And an automatic execution control unit for controlling activation of the upgrading unit in accordance with a set value when a communication port having a USB power supply function is connected to the communication module.

According to another aspect of the present invention, there is provided a system upgrading method implemented by a boot loader that is built in an embedded system and upgrades an application program recorded in a memory, the method comprising: initializing the system when the boot loader is started; To a host PC; Receiving a response message informing that the transmission from the host PC is properly performed, collecting the device information of the embedded system, and sequentially transmitting the device information transmission message following the device information transmission message; Receiving a write command including a byte number and an address from the host PC corresponding to the device information; Receiving data for upgrading the application program from the host PC in accordance with the write command; Overwriting the received data in a memory in which the application program is stored; And transmitting a write completion message to the host PC when data overwriting is completed.

The device information may include information consisting of 2 to 4 bytes including at least one of a byte count, a page size, a processor ID, a memory size, and a boot loader start address.

The host PC continuously adds bytes at the time of data transmission corresponding to the write command and when the number of bytes exceeds 0xFF, the host PC obtains the original checksum by leaving only one byte through overflow processing, To compare the write checksum with the write checksum added to the byte immediately after the data byte, and to retry the data transfer if they do not match.

Other aspects, features, and advantages will become apparent from the following drawings, claims, and detailed description of the invention.

According to the embodiment of the present invention, automatic downloading during connection is disabled, existing hex file is saved, communication protocol is changed, compatibility with the memory structure of PC x86 architecture is improved, and stable operation is enabled.

In addition, log segmentation improves user convenience and resets registers after downloading to reduce potential compatibility issues.

1 shows a flash memory area of an AVR,
2 shows a BOOTRST, BOOTSZ fuse bit,
3 is a diagram illustrating an operation process of the boot loader,
4 is a configuration diagram of an embedded system including a boot loader according to an embodiment of the present invention;
5 is a flowchart of a system upgrade method according to an embodiment of the present invention;
6 is a diagram illustrating an example of a client program installed in a host PC according to an embodiment of the present invention;

While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail. It is to be understood, however, that the invention is not to be limited to the specific embodiments, but includes all modifications, equivalents, and alternatives falling within the spirit and scope of the invention.

It is to be understood that when an element is referred to as being "connected" or "connected" to another element, it may be directly connected or connected to the other element, . On the other hand, when an element is referred to as being "directly connected" or "directly connected" to another element, it should be understood that there are no other elements in between.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. The singular expressions include plural expressions unless the context clearly dictates otherwise. In this specification, the terms "comprises" or "having" and the like refer to the presence of stated features, integers, steps, operations, elements, components, or combinations thereof, But do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or combinations thereof.

The terms first, second, etc. may be used to describe various components, but the components should not be limited by the terms. The terms are used only for the purpose of distinguishing one component from another.

Also, the terms " part, "" module," and the like, which are described in the specification, mean a unit for processing at least one function or operation, and may be implemented by hardware or software or a combination of hardware and software.

It is to be understood that the components of the embodiments described with reference to the drawings are not limited to the embodiments and may be embodied in other embodiments without departing from the spirit of the invention. It is to be understood that although the description is omitted, multiple embodiments may be implemented again in one integrated embodiment.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Reference will now be made in detail to the preferred embodiments of the present invention, examples of which are illustrated in the accompanying drawings, wherein like reference numerals refer to the like elements throughout. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. In the following description, well-known functions or constructions are not described in detail since they would obscure the invention in unnecessary detail.

FIG. 4 is a configuration diagram of an embedded system including a boot loader according to an embodiment of the present invention, and FIG. 5 is a flowchart of a system upgrade method according to an embodiment of the present invention.

The boot loader 110 according to the embodiment of the present invention can exchange various codes by changing the communication protocol, while enhancing the compatibility with the memory structure of the x86 architecture of the host PC 200 such as a PC, .

In the present embodiment, the embedded system 100 is a microcontroller (MCU), for example, an AVR which is an 8-bit microcontroller. However, in addition to AVR, RENESAS, ARM Cortex-M series, Cortex- , A Cortex-A series CPU, and the like.

Referring to FIG. 4, the embedded system 100 includes a boot loader 110, an application program 120, and a communication module 130.

The boot loader 110 may be mounted on the NRWW section 20 of the memory and the application program 120 may be mounted on the RWW section 10. [

The application program 120 is a program embedded in the embedded system 100 and designed to perform predetermined functions by operating hardware and software, and may be, for example, firmware.

The boot loader 110 upgrades the application program 120 recorded in the memory of the embedded system 100 through the communication module 130 without using a programmer device such as an ISP.

The communication module 130 connects the embedded system 100 and the host PC 200 to enable data transmission and reception. For example, a communication method such as UART, USB, CAN, Ethernet, or USART is applied Can be.

The boot loader 110 basically includes a system initialization unit 112 and an upgrading unit 114. And may further include an automatic execution control unit 116 according to an embodiment.

The system initialization unit 112 initializes the hardware installed in the embedded system 100 so that the embedded system 100 can operate. For example, the communication module 130 may be initialized and communication with the host PC 200 may be established.

The system initialization unit 112 may be driven depending on whether a reset button that is implemented in hardware in the embedded system 100 is pressed or not. That is, when the reset button is pressed, the system initialization unit 112 can be recognized as a reset command to initialize the system.

The upgrading unit 114 communicates with the host PC 200 through the communication module 130 to upgrade the application programs 120 stored in the memory. A simple user interface is provided at the time of communication with the host PC 200, and an application program image to be upgraded can be exchanged.

The upgrading unit 114 may be activated after the system initialization unit 112 is activated, but may be activated through a separate operation.

For example, activation or non-activation may be determined depending on whether a download button that is implemented in hardware in the embedded system 100 is pressed. Or whether or not the download button implemented in software in the client program 210 installed in the host PC 200 is selected.

In order to download data for upgrading the system in the upgrading unit 114, a communication protocol for data exchange needs to be defined between the embedded system 100 and the host PC 200. [

Conventional bootloaders use communication codes to reduce the size of the binary to 1 byte. However, in the boot loader 110 according to the present embodiment, communication codes are set to 2 to 4 bytes so that more various codes can be transmitted. In addition, compatibility with the memory structure of the x86 architecture of the host PC 200 is enhanced to enable stable operation.

Referring to FIG. 5, a system upgrade method performed by the upgrading unit 114 is illustrated.

First, when the boot loader 110 is started (step 300), the system initialization is performed and the boot loader start message is transmitted to the host PC 200 only once (step 305). The boot loader start message is set to 2 to 4 bytes. However, if there is no program code previously input, the boot loader will be continuously executed from 0th place, and the boot loader may continue to be executed.

If the host PC 200 receives the boot loader start message, the host PC 200 transmits a response message indicating that the transfer has been properly performed (step 310). Here, the response message is set to 1 byte.

When the boot loader 110 receives the response message, the boot loader 110 collects and transmits the device information of the embedded system 100 (step 315). The device information such as the number of bytes, the page size, the processor ID, the memory size, and the boot loader start address may be sequentially transmitted following the device information transmission message.

The number of bytes is the device information that exists for integrity verification, and substitutes the size of the structure. The page size is the size of a page, which is the unit in which the boot loader 110 performs the actual write operation, and is sent in bytes. The processor ID is identification information (ID) of the current embedded system 100, and may have a value unique to each embedded system 100. Memory size indicates the current memory size in kilobytes (KB, KiloByte). The boot loader start address indicates the start address of the currently boot loader 110.

The device information may also be composed of 2 to 4 bytes as in the device information transmission message.

Upon receiving the device information, the host PC 200 transmits a write command in accordance with the device information (step 320). The write command tells the number of bytes (ByteCount). If the number of bytes is a predetermined 2 byte code (for example, 0xFFFF), it means that the data transmission is finished.

When the number of bytes ends, the address is also sent so that it can be immediately stored in memory.

The number of bytes consists of two bytes, and the address consists of two to four bytes.

When the address transmission is completed, data for system upgrade is transmitted (step 325).

If the system upgrade data is a HEX file, the host PC 200 internally converts the system upgrade data into Bin data and transmits the data.

And the original checksum is calculated at transmission (step 330). The original checksum can be computed in such a way that the bytes are added continuously, as calculated by the Intel HEX standard, and are automatically one byte through the overflow.

When the upgrade unit 114 receives the data from the host PC 200, it records the data in the memory (step 335). The data recording may be new writing or overwriting of the stored data.

When the data recording is completed, a write completion message indicating that the write operation is completed is transmitted (step 340).

You can add a byte-wide write checksum to the byte immediately after the write completion message. The host PC 200 checks whether the write checksum matches the original checksum calculated by the host computer 200 (step 345), and if not, the host PC 200 can retry the data transfer.

When the communication with the host PC 200 is completed, the upgrading unit 114 can reset the register set for communication. By resetting the registers used for communication, potential compatibility problems can be reduced.

In addition, the upgrading unit 114 may automatically cancel the communication connection establishment through the communication module 130 after the system upgrade.

For example, after downloading the HEX file created by the programmer for the UART communication monitoring test, the embedded system 100 can be disconnected from the inconvenience of disconnecting the connection again from the terminal to be monitored.

In other words, after downloading the HEX file that I created to do the UART communication monitoring test, the connection is automatically disconnected so that the follow-up work can be performed smoothly by connecting only at the terminal to be monitored.

Referring again to FIG. 4, the boot loader 110 may further include an automatic execution controller 116.

When the communication port having the USB power supply function is connected to the communication module 130 in the initial state, the automatic execution controller 116 automatically controls the boot loader 110 so as to prevent the data download for the system upgrade from being started have. That is, the upgrade unit 114 can maintain the inactivated state according to the set value.

The automatic execution setting can be performed through a simple operation such as a button push in the client program of the host PC 200. [

The conventional boot loaders have a problem in that when the communication port having the USB power supply function is connected in the initial state, the boot loader is automatically executed and the existing version of the HEX file is overwritten.

Therefore, in this embodiment, the automatic execution control unit 116 is provided so that connection with the host PC 200 is established, but data downloading is not performed, thereby preventing unwanted system upgrading from being performed.

The boot loader 110 may display the value of a register or a variable itself, or may include a debugging function such as a break function.

6 is a diagram illustrating an example of a client program installed in a host PC according to an embodiment of the present invention.

Client program includes HEX file selection, communication speed setting part, work part, setting part and progress indication part.

HEX file selection allows you to directly select a HEX file that is data to be transferred from the host PC to the embedded system.

It is possible to select the serial port and the communication speed through the communication speed setting part so that the communication can be smoothly performed.

Even if a communication connection is established between the host PC and the embedded system through the program download and execution button in the work portion, the download is not automatically executed, but the download is executed only when the corresponding button is selected and pressed. Thus, It is possible to prevent erasure by mistake.

In the setting section, the language can be set, and the language constituting the user interface can be changed to a language easily understood by the user.

In addition, whether the automatic download is to be performed when the embedded system is reset can be set through a check box so that the automatic execution control unit can operate according to whether or not the check box is checked.

The progress indicator can be used to show the progress of downloading the program, so that the download completion time can be predicted.

When the boot loader 110 according to the present embodiment performs a series of operations, the firmware / software is updated to the latest version, and an update operation for downloading the firmware / software from the external host PC 200 is performed.

Unlike a window update in which a separate update server is designated, the host PC 200 can designate a location for receiving a file for upgrade from the software of the host PC 200, and can update it offline.

Also, since the file format is HEX or BIN and the error checking routine is performing the checksum calculation with the received bytes, it differs from the window update that performs hash value checking.

In addition, in the case of the boot loader 110 according to the present embodiment, the log is divided, and a log can be produced in a text format instead of a list box, so that copying / pasting to other programs is possible, .

The client program 210 of the host PC 200 according to the present embodiment checks the integrity of the HEX file and may launch a message indicating that the HEX file is corrupted if the HEX file is corrupted due to various reasons.

Also, in the present embodiment, the HEX file encrypted by the boot loader 110 may be transmitted from the host PC 200, and the HEX file may be decoded by the boot loader 110.

In addition, after completion of loading after the boot loader transfer, the self communication program inside the client for the boot loader of the host PC 120 may be activated to freely change the serial communication mode and the boot loader downloader mode .

It will be apparent to those skilled in the art that various modifications and variations can be made in the present invention without departing from the spirit or scope of the invention as defined in the following claims And changes may be made without departing from the spirit and scope of the invention.

100: embedded system 110: boot loader
120: Application program 130: Communication module
112: System initialization unit 114:
116:
200: Host PC 210: Client program

Claims (7)

A boot loader built in an embedded system for upgrading an application program recorded in a memory,
A system initialization unit for initializing hardware installed in the embedded system; And
And an upgrade unit communicating with the host PC through the communication module to download an application program image to be upgraded and upgrade the application program,
A communication code transmitted from the upgrade unit to the host PC is set to 2 to 4 bytes according to a communication protocol through the communication module,
Further comprising an automatic execution control unit for controlling whether the upgrade unit is activated according to a set value when a communication port having a USB power supply function is connected to the communication module.
The method according to claim 1,
Wherein the upgrading unit resets the register set for communication when communication with the host PC is completed.
The method according to claim 1,
Wherein the upgrading unit automatically releases establishment of a communication connection through the communication module after upgrading the application program.
delete A system upgrade method performed by a boot loader that is embedded in an embedded system and upgrades an application program recorded in a memory,
Performing system initialization when the boot loader is started, and continuously transmitting a boot loader start message to the host PC;
Receiving a response message informing that the transmission from the host PC is properly performed, collecting the device information of the embedded system, and sequentially transmitting the device information transmission message following the device information transmission message;
Receiving a write command including a byte number and an address from the host PC corresponding to the device information;
Receiving data for upgrading the application program from the host PC in accordance with the write command;
Overwriting the received data in a memory in which the application program is stored; And
And transmitting a write completion message to the host PC when data overwriting is completed.
6. The method of claim 5,
Wherein the device information comprises information consisting of 2 to 4 bytes including at least one of a byte count, a page size, a processor ID, a memory size, and a boot loader start address.
6. The method of claim 5,
The host PC continuously adds bytes at the time of data transmission corresponding to the write command and, when exceeding 0xFF, obtains an original checksum in such a manner that only one byte is left through overflow processing,
Comparing the write checksum added to a byte immediately after the write completion message transmitted from the boot loader,
And if not, retrying the data transfer.

Images