Microcomputer, start control method of microcomputer, compiling apparatus, method of storing application program into microcomputer

Abstract

To provide a microcomputer configured to transfer an application program from an external memory to an internal memory, and execute the transferred application program without reboot.SOLUTION: A CPU core executes a start program stored in a nonvolatile internal memory when starting a microcomputer to initialize the microcomputer, executes, after execution of the start program, a first application program stored in the nonvolatile internal memory to load, in accordance with information on a management table stored in a first external memory connected to the microcomputer, a data sequence of a second application program from the first external memory to a volatile internal memory, and starts, after loading the second application program, executing the second application program.SELECTED DRAWING: Figure 3

Description

[Technical field]

[0001] The present invention relates to a microcomputer, a startup control method for a microcomputer, a compiling device, and a method for storing an application program in a microcomputer. [Background technology]

[0002] There is known a microcomputer that can selectively execute a plurality of startup programs stored in a plurality of external devices. This type of microcomputer has an internal memory in which a plurality of pre-processing programs corresponding to the plurality of startup programs are stored. The microcomputer selects and executes the pre-processing program corresponding to the external device in which the startup program to be executed is stored, and starts the startup program from the pre-processing program.

[0003] A method is known that allows devices to be developed without being restricted by the storage capacity of a microcomputer by transferring a portion of software stored in an external device connected to the microcomputer to the microcomputer's built-in memory.

[0004] There is known a one-chip microcomputer that executes a transfer program stored in a ROM (Read Only Memory) before executing a program, transfers the program on an external storage device to an internal high-speed RAM (Random Access Memory), and then executes the transferred program at high speed. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] JP 2008-65549 A [Patent Document 2] JP 2004-272393 A [Patent Document 3] Japanese Patent Application Publication No. 5-151369 Summary of the Invention [Problem to be solved by the invention]

[0006] In relatively small embedded microcomputers that do not incorporate an MMU (Memory Management Unit), it may be difficult to incorporate a boot loader that loads an application program from an external memory to an internal memory at startup. In addition, when using a boot loader, it is difficult to execute an application program immediately after it is transferred because a restart is required after the application program is transferred from the external memory to the internal memory. Furthermore, switching of the application program to be executed can be performed by using an OS (Operating System) that has multiple software services (functions) around the kernel in a microcomputer that incorporates an MMU, but in embedded microcomputers, it may be difficult to incorporate an OS that has multiple such services due to the limited storage capacity of the internal memory.

[0007] In order to solve the above-mentioned problems, an object of the present invention is to enable a microcomputer to transfer an application program from an external memory to an internal memory and to execute the transferred application program without rebooting the microcomputer. [Means for solving the problem]

[0008] A microcomputer in one embodiment has a non-volatile internal memory, a volatile internal memory, and a CPU core that executes programs stored in the non-volatile internal memory and the volatile internal memory, wherein when the microcomputer is started up, the CPU core executes a startup program stored in the non-volatile internal memory to initialize the microcomputer, and after executing the startup program, executes a first application program stored in the non-volatile internal memory to load a data string of a second application program from the first external memory to the volatile internal memory according to information in a management table stored in a first external memory connected to the microcomputer, and after loading the second application program, begins execution of the second application program. Effect of the Invention

[0009] In a microcomputer, an application program can be transferred from an external memory to an internal memory, and the transferred application program can be made executable without rebooting the microcomputer. [Brief description of the drawings]

[0010] [Figure 1] 1 is a block diagram showing an example of a system in which a microcomputer according to an embodiment of the present invention is installed. [Diagram 2] 2 is a block diagram showing an example of an information processing device that compiles and builds a program executed by the CPU of FIG. 1. [Diagram 3] 2 is a diagram showing an example of operations from start-up to execution of an individual program in the system of FIG. 1. FIG. [Figure 4] FIG. 4 is a diagram showing the continuation of FIG. [Diagram 5] 2 is a diagram showing an example of a flow of a program executed by the CPU in FIG. 1 being compiled and built and then stored in the CPU. [Figure 6]1. FIG. 4 is a diagram illustrating another example of the flow of a program executed by the CPU in FIG. 1 being compiled and built and then stored in the CPU. [Figure 7] 2 is a diagram showing an example of allocation of individual programs and the like to the external ROM in FIG. 1; [Figure 8] FIG. 8 is a diagram illustrating an example of the management table of FIG. [Figure 9] 11A and 11B are diagrams illustrating an example of calls between an individual program before an update, a common program, and a startup program. [Figure 10] 13 is a diagram showing an example of calls between an individual program after updating, a common program, and a startup program; FIG. [Figure 11] FIG. 11 is a diagram showing an example of operations from start-up to execution of an individual program in another system. [Figure 12] FIG. 11 is a diagram showing another example of operations from start-up to execution of an individual program in another system. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] Hereinafter, an embodiment of the present invention will be described with reference to the drawings.

[0012] Fig. 1 is a block diagram showing an example of a system equipped with a microcomputer according to an embodiment of the present invention. Fig. 1 shows an example in which the microcomputer is a CPU (Central Processing Unit). For example, the CPU 100 is a relatively small-scale processor for embedded use that does not have a boot loader and does not execute an OS (hereinafter simply referred to as an OS) that has multiple software services (functions) around the kernel.

[0013] 1 includes a system board 210 on which a CPU 100 and the like are mounted. Although not particularly limited, the system 200 is, for example, various sensors such as a radar sensor and a vital sensor, or a KVM (Keyboard, Video, Mouse) product, or the like.

[0014] The CPU 100 includes a CPU core 110, an internal ROM 120, and a static random access memory (SRAM) 130. The internal ROM 120 is an example of a non-volatile internal memory, and the SRAM 130 is an example of a volatile internal memory.

[0015] The CPU 100 also has UARTs (Universal Asynchronous Receiver / Transmitters) 141, 142, and 144, and a USB (Universal Serial Bus) interface (I / F) 143. The CPU 100 also has an Ethernet interface (I / F) 145, a SPI (Serial Peripheral Interface) 146, and an I2C (Inter-Integrated Circuit) interface 147. Ethernet is a registered trademark.

[0016] Each element mounted on the CPU 100, such as the CPU core 110, the internal ROM 120, the SRAM 130, and the UARTs 141 and 142, is connected to a bus 150. The CPU core 110 controls each element in the CPU 100 via the bus 150, and can input and output information to and from each element.

[0017] For example, the SRAM 130, the UARTs 141, 142, and 144, the USB interface 143, the Ethernet interface 145, the SPI 146, and the I2C interface 147 may be initialized when the CPU 100 is started or reset.

[0018] The system board 210 is equipped with the CPU 100, a Bluetooth module 211, a Wi-Fi module 212, connectors 213, 214, 215, an external ROM 216, and an EEPROM (Electrically Erasable Programmable Read Only Memory) 217. Bluetooth and Wi-Fi are registered trademarks. The external ROM 216 is an example of a first external memory, and the EEPROM 217 is an example of a second external memory. The Bluetooth module 211 and the Wi-Fi module 212 are examples of peripheral devices connected to the CPU 100.

[0019] For example, the internal ROM 120 is a flash memory in which data can be electrically rewritten. The internal ROM 120 stores programs and data executed by the CPU core 110. The internal ROM 120 has a memory area 121 in which a kernel, a driver, programs and data for initial setting, etc. are stored, and a memory area 122 in which common application programs, etc. are stored. The SRAM 130 stores application programs 132 executed by the CPU core 110.

[0020] Hereinafter, the kernel, the driver, and the program for initial setting stored in the memory area 121 are also referred to as a startup program 121. The common application program stored in the memory area 122 is also referred to as a common program 122. The common program 122 is an example of a first application program.

[0021] The common program 122 is executed after the startup program is started upon power-on or restart of the system 200 and the initial settings of various functions are completed. Hereinafter, power-on and restart of the system 200 are also referred to as startup of the system 200. The common program 122 has a function of loading, for example, an application program 132 stored in the external ROM 216 into the SRAM 130.

[0022] Moreover, the common program 122 has a function of switching the program to be executed to the application program 132 loaded in the SRAM 130, thereby executing the application program 132 without rebooting the system 200. For example, while the common program 122 is being executed, the CPU core 110 executes a branch instruction written in the common program 122, thereby executing the application program 132 loaded from the external ROM 216 to the SRAM 130.

[0023] Various application programs 132 can be selectively loaded from the external ROM 216 into the SRAM 130. The CPU 100 can realize various functions according to the application programs 132 loaded into the SRAM 130. Hereinafter, the application programs 132 loaded into the SRAM 130 from the external ROM 216 are also referred to as individual programs 132. The application programs 132 and the individual programs 132 are examples of a second application program.

[0024] In the following description, it is assumed that the CPU core 110 realizes the functions of the system 200 without executing an OS. For this reason, a boot loader or the like that loads the OS or the like from an external storage device into an internal memory such as the SRAM 130 when the system 200 is started up is not stored in the internal ROM 120.

[0025] The UART 141 is connected to a Bluetooth module 211. The UART 142 is connected to a Wi-Fi module 212. The USB interface 143 is connected to a connector 213 to which a USB memory 300 is detachably connected. The UART 144 is connectable to a UART mounted on a PC (Personal Computer) 400 or the like connected to the system board 210 via a connector 214. The Ethernet interface 145 is connected to a connector 215 to which a cable CBL is detachably connected.

[0026] The SPI 146 is connected to an external ROM 216. For example, the external ROM 216 is a serial memory having an SPI and being electrically rewritable, such as a flash memory. Although not particularly limited, for example, the storage capacity of the external ROM 216 is 1000 times or more the storage capacity of the internal ROM 120. The I2C interface 147 is connected to an EEPROM 217 via an I2C bus. The EEPROM 217 is a serial memory having an I2C interface.

[0027] When there is only one individual program 132 that can be loaded from the external ROM 216 to the SRAM 130, the same individual program 132 is always loaded into the SRAM 130 and executed by the CPU core 110 when the system 200 is started up. On the other hand, when there are multiple individual programs 132 that can be loaded from the external ROM 216 to the SRAM 130, the individual program 132 to be loaded into the SRAM 130 is selected from the multiple individual programs 132 stored in the external ROM 216.

[0028] In order to select the individual program 132, load program information LPI indicating which individual program 132 is to be loaded from the external ROM 216 when the system 200 is started is written in advance to the EEPROM 217 before the system 200 is started. Then, the common program 122 determines the individual program 132 to be loaded into the SRAM 130 by referring to the load program information LPI stored in the EEPROM 217 when the system 200 is started. The load program information LPI is an example of selection information.

[0029] For example, the individual program 132 may be transferred in advance from the USB memory 300 connected to the connector 213 on the system board 210 to the external ROM 216 before booting up the system 200. Note that the individual program 132 may be transferred from the PC 400 to the external ROM 216, or may be transferred to the external ROM 216 wirelessly via the Bluetooth module 211 or the Wi-Fi module 212.

[0030] Furthermore, the individual program 132 may be transferred from outside the system board 210 to the external ROM 216 by wired connection via the Ethernet interface 145. By transferring the individual program 132 using the Ethernet interface 145, the individual program 132 can be transferred from any location to the external ROM 216. The UARTs 141, 142, 144, the USB interface 143, and the Ethernet interface 145 are examples of communication interface circuits that communicate with the outside of the CPU 100.

[0031] When the individual program 132 is transferred only from the USB memory 300, the Bluetooth module 211, the Wi-Fi module 212, and the connectors 213, 214, and 215 do not have to be mounted on the system board 210. In this case, the CPU 100 does not have to have the UARTs 141, 142, and 144 and the Ethernet interface 145. In other words, the system board 210 and the CPU 100 are equipped with at least an interface used for transferring the individual program 132 to the external ROM 216.

[0032] When transferring the individual programs 132 from outside the system board 210 to the external ROM 216, it is preferable to encrypt or add a hash value, and add an error correction code, or both encrypt and add a hash value, from the viewpoint of preventing tampering and preventing data errors during transfer. If the individual programs 132 are encrypted, the common program 122 decrypts the individual programs 132 transferred from outside and then stores them in the external ROM 216. Also, the error correction code makes it possible to correct data errors to a certain extent.

[0033] Furthermore, if a hash value is added to the individual program 132, the common program 122 generates a hash value of the data string of the individual program 132 transferred from the outside. Then, the common program 122 compares the generated hash value with the hash value transferred from the outside together with the individual program 132. This makes it possible to confirm that the individual program 132 is correct. The hash value is an example of a check code. By decrypting the encrypted individual program 132 or checking the individual program 132 using the hash value, it is possible to prevent an incorrect individual program 132 from being stored in the SRAM 130 and executed by the CPU core 110. As a result, it is possible to improve the reliability of the system 200.

[0034] The method of compiling the startup program 121, the common program 122 and the individual programs 132 and building them on a memory map, and the method of extracting the individual programs 132 built on the memory map and transferring them to the external ROM 216 will be described with reference to FIGS.

[0035] Fig. 2 is a block diagram showing an example of an information processing device that compiles and builds a program executed by the CPU 100 in Fig. 1. The information processing device 500 shown in Fig. 2 has a CPU 510, a ROM 520, a RAM 530, a HDD (Hard Disk Drive) 540, an input interface unit 550, an output interface unit 560, an input / output interface unit 570, and a network interface unit 580. The elements in the information processing device 500 shown in Fig. 2 are connected to each other via a bus 590. For example, in Fig. 2, the frame showing the information processing device 500 indicates a motherboard.

[0036] For example, CPU 510 executes a compile program to operate information processing device 500 as a compile device. The compile program has an include function, a compile function, and a build function. The include function is a function for incorporating a header file into each of a plurality of source programs. The compile function is a function for compiling each of a plurality of included files to generate a plurality of object files (object code). The build function is a function for building a plurality of object files on a memory map to generate a program file.

[0037] The ROM 520 stores basic programs such as an OS, various parameters, etc. The RAM 530 stores a compilation program and data used in the compilation program, etc. The HDD 540 stores source files, header files, and object files generated by compilation. Note that the information processing device 500 may have a storage device such as an SSD (Solid State Drive) instead of the HDD 540.

[0038] An input device 610 such as a mouse and a keyboard is connected to the input interface unit 550. An output device 620 such as a display and a printer is connected to the output interface unit 560. An input / output device 630 such as a storage device capable of receiving a disk such as a USB memory or a DVD (Digital Versatile Disc) is connected to the input / output interface unit 570. The network interface unit 580 is connected to a network 700 such as the Internet or an intranet.

[0039] Figures 3 and 4 are diagrams showing an example of operations from start-up to execution of individual program 132 in system 200 in Figure 1. Figures 3 and 4 show an example of a start-up control method for a microcomputer. In Figures 3 and 4, operating elements and elements used are indicated by shading.

[0040] (State 1) shows a state at the time of booting up the system 200. The internal ROM 120 stores in advance a boot program 121 such as a kernel, a driver, and a program for initial setting, various initial data, a common program 122, etc. When the system 200 is booted up by turning on the power, etc., the CPU core 110 sequentially boots up the kernel and drivers, and performs initial settings for various functions.

[0041] Next, in (State 2), the CPU core 110 starts executing the common program 122 through the kernel and the driver after the initial setting. The common program 122 refers to the EEPROM 217 and determines (selects) the individual program 1 indicated by the load program information LPI stored in the EEPROM 217 as the program to be loaded. Then, the common program 122 loads the individual program 1 from the external ROM 216 into the SRAM 130.

[0042] After loading the individual program 1 into the SRAM 130, in (state 3) of FIG. 4, the CPU core 110 switches the destination of program execution from the common program 122 to the individual program 1, for example, by executing a branch command written in the common program 122. As a result, after loading the individual program 1 into the SRAM 130, execution of the individual program 1 can be started through the kernel and the driver without restarting the system 200. In other words, the common program 122 and the individual program 1 can be executed continuously as one program without interruption. Note that the CPU core 110 may execute the common program 122 while executing the individual program 132.

[0043] As a result, the time from when the system 200 is started in state 1 until execution of the individual program 1 begins can be made shorter than when the system 200 is rebooted. As a result, the performance of the system 200 can be improved. For example, when the OS and the individual program 1 are loaded from outside the CPU 100 using a boot loader, it is necessary to reboot the system 200.

[0044] By not using a boot loader and an OS, the amount of space used in the internal ROM 120 can be reduced. In other words, this embodiment can be applied even to a CPU 100 in which a boot loader cannot be incorporated due to limitations in the storage capacity of the internal ROM 120. In addition, the access latency of the SRAM 130 is usually smaller than that of the internal ROM 120. Therefore, by loading the individual program 1 into the SRAM 130 and executing it, the processing performance of the individual program 1 can be improved compared to the case of executing the individual program 1 stored in the internal ROM 120.

[0045] For example, by writing load program information LPI corresponding to the individual program 2 in the EEPROM 217, the individual program 2 can be loaded from the external ROM 216 to the SRAM 130 by the common program 122 when the system 200 is started and executed. Therefore, multiple functions can be realized by a small-scale CPU 100 for embedding, based on the load program information LPI stored in the EEPROM 217. In other words, multiple types of systems with different functions can be realized by a common system board 210, and multiple functions can be realized by switching between them, thereby suppressing an increase in system costs.

[0046] Fig. 5 is a diagram showing an example of a flow in which a program executed by CPU 100 in Fig. 1 is compiled and built and then stored in CPU 100. That is, Fig. 5 shows an example of a method for storing an application program in CPU 100. In Fig. 5, the startup program, common program, and individual program respectively indicate the startup program 121 (kernel, driver), common application program 122, and application program 132 (individual program 132) in Fig. 1.

[0047] First, source files such as the startup program, common program, individual program, and address conversion module are compiled using a development tool to generate object code. When compiling, a header file containing a document file describing declarations of variables, constants, functions, etc. used in the program is included in the source file.

[0048] Next, a configuration file (Make File) for building is created in advance so that the compiled programs and tables are within a predetermined address range on the memory map without overlapping with each other. For example, the configuration file includes the start address and end address of each program and table, and addresses indicating the positions of labels, constants, declarations, etc. in each program. For example, the addresses to which individual programs are assigned are included in the range of addresses assigned to SRAM 130 in Fig. 1. Then, as shown in Fig. 5(a), multiple object codes are built as one program file on the memory map indicating the memory space of CPU 100.

[0049] The address conversion module has an internal address conversion table, and is created corresponding to an individual program by referring to the address conversion table to convert addresses. For example, the address conversion module includes information that associates addresses before the update with addresses after the update (updated version) when the allocation of addresses in the individual program before and after the update (updated version) of the individual program is changed. Then, when an updated individual program is called from an unupdated startup program or common program, the address is converted to an updated address using the address conversion module. The unupdated startup program or common program is built together with the individual program before the update. This eliminates the inconsistency between addresses before and after the update, and allows the system 200 to operate normally. An example of converting addresses using the address conversion module will be described with reference to FIG. 10.

[0050] In addition, a management table TOC is created in parallel with the compiling and building. As will be described in FIG. 7, a plurality of storage areas SA capable of storing either a program (address conversion module+individual program) or data are allocated to the external ROM 216. For example, the size of the programs or data stored in the storage areas SA differs. For this reason, in order to load a program from the external ROM 216 to the SRAM 130 by the common program, a management table TOC including information for identifying the storage area SA in which the program to be loaded is stored and the size of the program is created in advance. An example of the management table TOC will be described in FIG. 8.

[0051] 5(b), the individual programs and the address conversion module (binary data) are extracted from the program integrated by the build and stored, for example, in a program storage area of ​​the USB memory 300. A separately created management table TOC is stored in a table storage area of ​​the USB memory 300. Furthermore, a control code indicating an area of ​​the external ROM 216 (storage area SA shown in FIG. 7) for storing the address conversion modules and the individual programs stored in the USB memory 300 is stored in a code area of ​​the USB memory 300.

[0052] 5(c), the management table TOC, the individual programs, and the address conversion module stored in the USB memory 300 are stored in a storage area indicated by a control code in the external ROM 216. The individual programs and the like are stored in the external ROM 216 when the USB memory 300 is connected to the connector 213 while the system 200 in FIG. 1 is started up.

[0053] The system 200 recognizes the connection of the USB memory 300, establishes communication with the USB memory 300, and then reads the control code from the USB memory 300. The system 200 stores the management table TOC, the address conversion module, and the individual program stored in the USB memory 300 in a storage area SA in the external ROM 216 that is indicated by the control code.

[0054] The address conversion module and the individual programs may be stored in the external ROM 216 using a memory device other than the USB memory 300. In this case, the memory device may be connected to the system 200 by wire or wirelessly.

[0055] Next, the system 200 is started, and the common program is executed after the system 200 is initialized. The start-up program, various initial data, the common program, and the like are stored in advance in the internal ROM 120. Note that when the management table TOC, the individual program, and the address conversion module are stored from the USB memory 300 to the external ROM 216, the system 200 has already started and the initial settings have been completed. Therefore, the system 200 may execute the common program based on the storage of the management table TOC, the individual program, and the address conversion module from the USB memory 300 to the external ROM 216.

[0056] Based on the information held in the management table TOC, the common program detects the storage area SA of the external ROM 216 in which the program to be loaded into the SRAM 130 is stored, and the size of the program stored in the storage area SA. Then, the common program executes a load process in which the program of the detected size is read from the detected storage area SA, and stored in order from the top address of the SRAM 130. As a result, even when the address conversion module and the individual programs are loaded into the SRAM 130 separately from the common program, etc., the same memory map as that built in FIG. 5(a) can be reproduced on the system 200 as shown in FIG. 5(d).

[0057] Then, as described in FIG. 4, after loading the individual program into SRAM 130, CPU core 110 executes the individual program following the common program without rebooting system 200, for example, by executing a branch instruction written in the common program.

[0058] Fig. 6 is a diagram showing another example of the flow of compiling and building a program executed by the CPU 100 in Fig. 1 and storing it in the CPU 100. That is, Fig. 6 shows an example of a method of storing an application program in the CPU 100. Detailed description of the same operations as those in Fig. 5 will be omitted.

[0059] First, as shown in FIG. 6(a), a plurality of programs including a plurality of individual programs 1 and 2 are compiled and built. Next, as shown in FIG. 6(b), one of the built programs is selected. Then, for example, the individual program 1 and the address conversion module 1 are extracted from the selected program and stored in the program storage area of ​​the USB memory 300. Next, the individual program 2 and the address conversion module 2 are extracted from the other program and additionally stored in the program storage area of ​​the USB memory 300. In addition, the management table TOC and the control code are stored in the table storage area and the code area of ​​the USB memory 300, respectively. As a result, they are stored as shown in FIG. 6(c). The operation thereafter is basically the same as FIG. 5, but in this case, which of the two sets is loaded into the SRAM as shown in FIG. 6(d) will be explained later.

[0060] Fig. 7 is a diagram showing an example of allocation of the individual programs 132, etc. to the external ROM 216 in Fig. 1. In order to enable the CPU 100 to selectively execute a plurality of types of individual programs 132, a management table TOC and a plurality of storage areas SA (for example, 16 storage areas SA0-SA15) are allocated to the external ROM 216. The storage areas SA can be used as a program area in which pairs of a plurality of address conversion modules and the individual programs 132 are stored, or as a data area in which data used by the system 200 is stored.

[0061] In Fig. 7, the size of the storage area SA is variable. The size (length) of the storage area SA can be set by the program length / data length (Fig. 8) area included in the management table TOC. Note that the data area does not have to be allocated to the storage area SA.

[0062] Each storage area SA is identified by an area number. In Fig. 7, the program area is assigned to the side with the smaller area number, and the data area is assigned to the side with the larger area number, but the program area and the data area can be assigned to any storage area SA. It is possible to determine which area the program area and the data area are assigned to by the management table TOC.

[0063] Although not limited to this, individual program 1 in storage area SA0 is a program used in testing system 200 before shipment. Individual program 2 (Ver. 1) in storage area SA1 is an unupdated program that realizes product function 1. Individual program 3 in storage area SA2 is a program that realizes product function 2 that is different from product function 1. Individual program 2 (Ver. 2) in storage area SA3 is an updated program that realizes product function 1.

[0064] The data area can store any data used in the system 200. For example, if the system 200 has a vital sensor function, the data area may store vital data measured by the vital sensor in real time. Furthermore, the external ROM 216 may store environmental data such as temperature, humidity, and air pressure in real time.

[0065] The external ROM 216 is an electrically rewritable non-volatile memory (for example, a serial flash memory). Therefore, various data stored in the external ROM 216 can be held without loss and can be read at any time.

[0066] For example, vital data etc. can be copied from the external ROM 216 to a USB memory 300 etc., and the USB memory 300 etc. to which the vital data etc. has been copied can be connected to a PC, whereby the vital data etc. can be displayed as a graph on the display of the PC. When accessing a data area allocated to the external ROM 216, the location of the data area to be accessed can be determined by referring to the management table TOC.

[0067] Fig. 8 is a diagram showing an example of the management table TOC shown in Fig. 7. The management table TOC has 16 entries ENT0-ENT15, which is the same as the number of storage areas SA0-SA15 of the external ROM 216.

[0068] Each entry ENT has a 32-byte area including a 2-byte TOC table, a 1-byte type area, a 1-byte SA number area, and a 28-byte header area. Note that only the TOC table of entry ENT0 is valid, and the TOC tables of entries ENT1-ENT15 are not used.

[0069] The TOC table has a bit corresponding to each entry ENT0-ENT15. ​​A "0" in a bit of the TOC table indicates that the corresponding entry ENT is invalid. A "1" in a bit of the TOC table indicates that the corresponding entry ENT is valid.

[0070] The 16 entries ENT correspond to any one of the 16 storage areas SA of the external ROM 216 shown in Fig. 7, which are identified by SA numbers. Usually, an individual program 132 or data is stored in a storage area SA of the external ROM 216 corresponding to an entry ENT that is enabled in the TOC table.

[0071] However, a valid individual program 132 or valid data may be stored in the storage area SA corresponding to an invalid entry ENT. This allows the storage area SA in which a valid individual program 132 or valid data is stored to be treated as invalid by the bit in the TOC table. Note that, in order to unify the structure of the entries ENT in the management table, for example, in the TOC table, only the TOC table of the entry ENT0 has a bit "1" set to correspond to a valid entry ENT, and in the TOC tables of the entries ENT1-ENT15 that do not need to be referenced, all bits are set to "0".

[0072] 7, when different versions of the same type of individual program 132 are stored in multiple storage areas SA, it is possible to hide the older version of the individual program 132 without deleting it from the storage area SA. As a result, when there is a problem with the newer version of the individual program 132, it is possible to temporarily disable the newer version of the individual program 132 and enable the older version of the individual program 132 by manipulating the bits in the TOC table.

[0073] The new version of the individual program 132 can be treated as invalid without being erased from the external ROM 216 by setting the corresponding bit in the TOC table to "0." Furthermore, by overwriting the storage area SA with the modified new version of the individual program 132 while the bit in the TOC table corresponding to the new version of the individual program 132 is set to "0," the individual program 132 can be used as is without rewriting the header area of ​​the entry ENT.

[0074] The type area stores a value indicating whether an address conversion module and an individual program 132, or data, is stored in the corresponding storage area SA of the external ROM 216. For example, a "0" stored in the type area indicates that an address conversion module and an individual program 132 are stored in the corresponding storage area SA. A "1" stored in the type area indicates that data is stored in the corresponding storage area SA.

[0075] The SA number area stores the number of the storage area SA (any of 0 to 15) to indicate which storage area SA in the external ROM 216 each entry ENT corresponds to.

[0076] The header area has areas for storing the total length, start address, program length / data length, and metadata length 0-metadata length 3. The total length indicates the length (size) of the storage area SA including the address conversion module and individual program 132 or data stored in the storage area SA indicated by the SA number, and additional information such as metadata and hash values. When md5 (Message Digest 5) is used as the hash function, the size of the hash value is 16 bytes.

[0077] The start address indicates the top address on the external ROM 216 of the storage area SA indicated by the SA number. Therefore, the top address is set within the range of addresses allocated to the storage area of ​​the external ROM 216. The program length / data length indicates the length of the main part of the address conversion module and the individual program 132, or the main part of the data, and does not include additional information such as metadata and hash values. Additional information such as metadata and hash values ​​is stored in the area indicated by metadata length 0 to metadata length 3. The program length is an example of size information. Each of metadata length 0 to metadata length 3 indicates the length of metadata that can store up to four types. When metadata length 0 to metadata length 3 is "0", it indicates that no metadata exists.

[0078] For example, in state 2 of Fig. 3, it is assumed that load program information LPI="1" is stored in the EEPROM 217. In this case, the common program 122 executes a process of loading the address conversion module and the individual program 2 (Ver.1) stored in the storage area SA="1" of the external ROM 216 of Fig. 7 into the SRAM 130.

[0079] The common program 122 first sequentially refers to the type area and SA number of the entry ENT corresponding to the bit value "1" in the TOC table in the management table TOC of Fig. 8. Then, the common program 122 finds an entry ENT (hereinafter, the target entry ENT) whose type is program and whose storage area SA corresponds to "1".

[0080] Next, the common program 122 acquires the total length and the start address from the header of the target entry ENT. Then, the common program 122 reads out the individual program 2 from the storage area of ​​the external ROM 216, starting from the acquired start address and using the acquired total length or program length / data length as the transfer length, and stores it in the SRAM 130. At this time, by using the hash value stored in the area indicated by metadata length 0-metadata length 3 that exists after the program length, it is possible to detect tampering or errors when storing in the SRAM 130.

[0081] Furthermore, when the function of the system 200 is switched by executing individual program 3 after the execution of the loaded individual program 2, the load program information LPI in the EEPROM 217 is rewritten to "2" corresponding to the storage area SA="2" in Fig. 7. After that, the system 200 is restarted. At the time of restart, the common program 122 loads the individual program 3 stored in the storage area SA="2" of the external ROM 216 corresponding to the load program information LPI="2" read from the EEPROM 217 from the external ROM 216 into the SRAM 130.

[0082] On the other hand, when the individual program 2 is updated and switched from Ver.1 to Ver.2, the load program information LPI in the EEPROM 217 is rewritten to "3" corresponding to the storage area SA="3" in Fig. 7. It is assumed that the individual program 2 (Ver.2) is pre-stored in the storage area SA of the external ROM 216.

[0083] After this, the system 200 is restarted. At the time of restart, the common program 122 reads out the load program information LPI="3" from the EEPROM 217. The common program 122 loads the individual program 2 (Ver.2) stored in the storage area SA="3" corresponding to the read out load program information LPI="3" from the external ROM 216 to the SRAM 130. At this time, the common program 122 refers to the management table TOC to obtain the address and program size on the external ROM 216 where the individual program 2 (Ver.2) is stored.

[0084] Furthermore, for example, if a problem occurs during execution of the individual program 2 (Ver. 2), the loaded program information LPI in the EEPROM 217 is rewritten to "1" and the system 200 is restarted. This allows the individual program 2 (Ver. 1) to be loaded into the SRAM 130 again.

[0085] As described above, by using the management table TOC when loading the individual programs 132 into the SRAM 130, it is possible to store a plurality of individual programs 132 in advance in the external ROM 216. Then, by referring to the load program information LPI in the EEPROM 217, it is possible to load any one of the plurality of individual programs 132 stored in the external ROM 216 into the SRAM 130. In other words, switching of application programs executable in a large-scale system that uses an OS can be realized by a small-scale embedded CPU 100 that does not use an OS.

[0086] Fig. 9 is a diagram showing an example of calls between pre-update individual program 132, common program 122, and startup program 121 (kernel, driver, etc.). In startup program 121 in Fig. 9, function A and function B start from addresses 0x00011000 and 0x00012000. Note that the symbol 0x indicates that the following numbers are hexadecimal numbers.

[0087] In the common program 122 of Fig. 9, the functions C and D start at addresses 0x00105000 and 0x00108000. In the individual program 132 of Fig. 9, the labels A, B, and C of the source program indicate addresses 0x10004000, 0x10007000, and 0x10009000.

[0088] In operation (a), if there is a statement that calls address 0x00012000 in a program starting from label A of individual program 132, function B starting from address 0x00012000 is called normally (arrow (a) in FIG. 9). After function B is executed, program execution is returned normally to the caller of function B.

[0089] In operation (a), if there is a statement that calls address 0x00108000 in a program starting from label B of individual program 132, function D starting from address 0x00108000 is called normally (arrow (b) in FIG. 9). After function D is executed, program execution is returned normally to the caller of function D.

[0090] In operation (b), if function A of startup program 121 contains a statement that calls address 0x10004000, label A indicating address 0x10004000 is called normally (arrow (c) in FIG. 9). After the program starting from label A is executed, the program is returned normally to the caller in function A.

[0091] In operation (b), if function C of common program 122 contains a statement that calls address 0x10007000, label B indicating address 0x10007000 is called normally (arrow (d) in FIG. 9). After execution of the program starting from label B, the program is returned normally to the caller in function C. Note that although the address conversion module is left blank in FIG. 9, if individual program 132 has not been updated, it is not necessary to load the address conversion module into SRAM 130.

[0092] Fig. 10 is a diagram showing an example of calls between the updated individual program 132, the common program 122, and the startup program 121 (kernel, driver, etc.). The startup program 121 and the common program 122 shown in operations (c) and (d) are the same as those in Fig. 9. Meanwhile, in the updated individual program 132 shown in operations (c) and (d), the labels A, B, and C of the source program indicate addresses 0x10007000, 0x10004000, and 0x10009000. That is, the addresses of the labels A and B have been swapped with those before the update shown in Fig. 9.

[0093] In this way, a function or label in the updated individual program 132 newly built and loaded into the SRAM 130 may be called from the startup program 121 or the common application program 122 already stored in the internal ROM 120. The address indicating the function or label in the individual program 132 may have changed before and after the update. However, the startup program 121 or the common application program 122 only recognizes the address indicating the function or label before the update.

[0094] For this reason, in operation (c), if function A of startup program 121 contains a statement that calls address 0x10004000, the updated label B will be called instead of the pre-update label A (arrow (a) in Figure 10). Since the same startup program 121 as in Figure 9 calls the address corresponding to the pre-update label A from function A, the correct call is not executed and the program will malfunction.

[0095] In operation (c), if function C of the common program 122 contains a statement that calls address 0x10007000, the updated label A will be called instead of the pre-update label B (arrow (b) in FIG. 10). The common program 122 shown in FIG. 9 calls the address corresponding to the pre-update label B from function D, so the correct call is not executed and the program malfunctions.

[0096] There are cases where the boot program 121 (kernel, driver, initial settings, etc.) or the common application program 122 already stored in the internal ROM 120 is called from the updated individual program 132 that has been newly built and loaded into the SRAM 130. In this case, the address of the call destination is the same before and after the update of the individual program 132, so that the boot program 121 or the common application program 122 can be normally called from the individual program 132.

[0097] Furthermore, when the individual program 132 calls the launch program 121 or the common application program 122, the return address in the individual program 132 is stored in a stack or the like. Therefore, after processing by the launch program 121 or the common application program 122, it is possible to normally return from the launch program 121 or the common application program 122 to the individual program 132.

[0098] A method for preventing the problem shown in operation (c) will be described below along with the operation of the address conversion module. In operation (d), the address conversion module executes address conversion to convert the address of the call destination of individual program 132 before the update to the address of the call destination of individual program 132 after the update. For example, when address 0x10004000 is called from function A of startup program 121, address conversion module converts address 0x10004000 to address 0x10007000 (arrow (c) in FIG. 10). As a result, the call destination becomes address 0x10007000, and label A can be called normally (arrow (d) in FIG. 10).

[0099] Similarly, when address 0x10007000 is called from within function C of common program 122, address 0x10007000 is converted to address 0x10004000 by the address conversion module (arrow (e) in Figure 10). As a result, the address to be called becomes address 0x10004000, and label B can be called normally (arrow (f) in Figure 10).

[0100] In practice, for example, in updated individual program 132, among a plurality of areas indicated by the addresses of functions or labels before the update, an instruction to call the corresponding area of ​​the address conversion module is inserted in an area whose address changes before and after the update. An instruction to call the address of the updated function or label is held in each of the areas in the address conversion module that are called from individual program 132. This makes it possible to convert the address of a function or label of individual program 132 called from startup program 121 or common application program 122 into the correct address after the update and call it.

[0101] Furthermore, when the processing described in the area indicated by the function or label in the updated individual program 132 is completed, it is possible to normally return to the caller, startup program 121 or common application program 122, via the address conversion module and the area of ​​the function or label before the update, in accordance with the return address stacked at the time of the call. As described above, even if the individual program 132 is updated multiple times and the correct address of the callee changes with each update, the program can be operated normally by calling the function or label via the address conversion module.

[0102] 9, if the position of function B or function D is changed, function B or function D will no longer be called normally from individual program 132 built in the past. Even if the position of a function or label in startup program 121 or common program 122 is changed, by using an address conversion mechanism, startup program 121 or common application program 122 can be called normally from individual program 132, and the problem of programs not working can be solved.

[0103] Fig. 11 is a diagram showing an example of operations from start-up to execution of an individual program in another system. In Fig. 11, operating elements and elements used are also shaded. The other system shown in Fig. 11 has a CPU 800 including a CPU core 810, an internal ROM 820, and an SRAM 830, and an external ROM 900.

[0104] In (Example 1), after being started, CPU 800, which is not connected to an external ROM, realizes the functions of the system by executing individual programs stored in internal ROM 820 by CPU core 810. In this case, since the individual programs are stored in internal ROM 820, which has a relatively small capacity, the system cost is low, but there is a limit to the functions that can be realized.

[0105] Therefore, as shown in (Example 2) as an improvement of (Example 1), an external ROM 900 is connected to the CPU 800, and the individual programs are divided and stored in the internal ROM 820 and the external ROM 900. The external ROM 900 is allocated to the memory space of the CPU 800. The CPU core 810 executes the divided individual programs stored in the internal ROM 820 and the external ROM 900, respectively.

[0106] This allows the program size of the individual programs to be increased, and the functions that can be realized by the individual programs to be increased compared to (Example 1). However, the access latency of the external ROM 900 is larger than the access latency of the internal ROM 820. This causes a problem that, for example, a wait is inserted when accessing the external ROM 900, which effectively limits the clock frequency of the CPU 800, resulting in a decrease in processing performance.

[0107] Without the function of inserting waits into the CPU 800, the clock frequency of the CPU 800 is lowered in accordance with the access latency of the external ROM 900, further degrading the processing performance. Also, for example, when the external ROM 900 is connected to the CPU 800 via a serial interface, the access latency of the external ROM 900 may become even larger, further degrading the processing performance.

[0108] Fig. 12 is a diagram showing another example of the operation from start-up to execution of individual program 132 in another system. In CPU 800 in Fig. 12, a boot loader is stored in internal ROM 820. In (Example 3-1), after CPU 800 is started, CPU core 810 executes the boot loader and loads the divided individual program stored in external ROM 900 into SRAM 830. After loading the divided individual program into SRAM 830, CPU 800 is restarted.

[0109] After rebooting, as shown in (Example 3-2), the CPU core 810 executes the divided individual programs stored in the internal ROM 820 and the external ROM 900. When a boot loader is used, the functions of the system can be changed by the divided individual programs loaded into the SRAM 830. However, since the system is rebooted after the divided programs are loaded into the SRAM 830, it takes time before the execution of the divided individual programs starts. For this reason, the example shown in FIG. 12 is used in a relatively large system that uses an OS and in which a boot loader is embedded, and is difficult to realize in a relatively small-scale embedded CPU in which a boot loader cannot be embedded.

[0110] As described above, in this embodiment, after the common program 122 loads the individual program 132 into the SRAM 130, for example, a branch instruction in the common program 122 switches the destination of program execution from the common program 122 to the individual program 132. As a result, after the individual program 132 is loaded into the SRAM 130, execution of the individual program 132 can be started without rebooting the system 200. In other words, the individual program 132 can be loaded into the SRAM 130 without using a boot loader, and the loaded individual program 132 can be executed without rebooting.

[0111] This allows the common program 122 and the individual program 132 to be executed continuously as one program without interruption. As a result, the time from when the system 200 is started to when the individual program 132 starts to be executed can be made shorter than when the system 200 is rebooted, and the performance of the system 200 can be improved.

[0112] By holding a plurality of individual programs 132 in the external ROM 216 so as to be identifiable by the load program information LPI stored in the EEPROM 217, any individual program 132 can be loaded into the SRAM 130 by the common program 122. As a result, for example, a plurality of functions can be realized by one system 200 without using an OS. In other words, a plurality of types of systems with different functions can be realized by a common system board 210, and an increase in system costs can be suppressed.

[0113] When the individual programs 132 are transferred from the USB memory 300 to the external ROM 216, the common program 122 generates a hash value of the data string of the transferred individual programs 132. The common program 122 can then verify that the individual programs 132 are correct by comparing the generated hash value with a hash value transferred from the outside together with the individual programs 132. As a result, it is possible to prevent an incorrect individual program 132 from being stored in the SRAM 130 and executed by the CPU core 110, and the reliability of the system 200 can be improved.

[0114] By transferring the address conversion module together with the individual program 132 from the external ROM 216 to the SRAM 130, even when only the individual program 132 is updated among the programs on the memory map, the updated individual program 132 can be executed normally. As a result, the system 200 can be operated normally.

[0115] Although the present invention has been described above based on the embodiments, the present invention is not limited to the requirements shown in the above embodiments. These points can be changed without departing from the spirit of the present invention, and can be appropriately determined according to the application form. [Explanation of symbols]

[0116] 100...CPU, 110...CPU core, 120...Internal ROM, 121. Storage area, startup programs, 122. Memory area, common application programs, common programs, 130 SRAM, 132 application program, individual program, 141, 142 UART, 143 USB interface, 144 UART, 145 Ethernet interface, 146 SPI, 147 I2C interface, 150 bus, 200 system, 210: system board, 211: Bluetooth module, 212‥Wi-Fi module, 213, 214, 215‥Connector, 216...External ROM, 217...EEPROM, 300...USB memory, 400 PC, 510 CPU, 520 ROM, 530 RAM, 540: HDD, 550: input interface section, 560: output interface section, 570: Input / output interface unit, 580: Network interface unit, 590... bus, 610... input device, 620... output device, 630... input / output device, 700 network, 800 CPU, 810 CPU cores, 820‥Internal ROM, 830‥SRAM, 900‥External ROM, CBL: Cable, ENT (ENT0-ENT15): Entry, LPI: Load program information, TOC: Management table

Claims

1. A microcomputer having a non-volatile internal memory, a volatile internal memory, and a CPU core that executes programs stored in the non-volatile internal memory and the volatile internal memory, The CPU core is When the microcomputer is started, the start-up program stored in the non-volatile internal memory is executed to initialize the microcomputer; After the startup program is executed, a first application program stored in the non-volatile internal memory is executed, whereby a data string of a second application program is loaded from the first external memory to the volatile internal memory according to information in a management table stored in a first external memory connected to the microcomputer, and after the second application program is loaded, execution of the second application program is started. Microcomputer.

2. The CPU core is selecting one of a plurality of entries included in the management table stored in the first external memory by executing the first application program; A data sequence of a second application program is loaded into the volatile internal memory according to information of the selected entry.

2. The microcomputer according to claim 1.

3. The CPU core selects one of the plurality of entries indicated by selection information stored in a second external memory connected to the microcomputer.

3. The microcomputer according to claim 2.

4. The CPU core executes the first application program to generate a check code for a data string of the second application program loaded into the volatile internal memory, and verifies that the second application program is correct by comparing the generated check code with a check code transferred from the first external memory together with the second application program.

4. The microcomputer according to claim 1.

5. The CPU core is when the volatile internal memory is overwritten with an updated version of the second application program by execution of the first application program, an address conversion module is loaded from the first external memory to the volatile internal memory, the address conversion module converting an address of a call destination of the second application program before the update, which is called from the startup program or the first application program stored in the non-volatile internal memory, into an address of a call destination of the updated version of the second application program; When the updated version of the first application program is called from the startup program or the first application program after the updated version of the second application program and the address conversion module are loaded into the volatile internal memory, the address conversion module is referenced to convert a call address corresponding to the second application program before the update into a call address corresponding to the updated version of the second application program.

2. The microcomputer according to claim 1.

6. a communication interface circuit for communicating with an external device of the microcomputer; When communication with the external device is established, the CPU core transfers the management table and the data string of the second application program stored in the external device to the first external memory.

2. The microcomputer according to claim 1.

7. 1. A startup control method for a microcomputer having a non-volatile internal memory, a volatile internal memory, and a CPU core that executes programs stored in the non-volatile internal memory and the volatile internal memory, comprising: The CPU core is When the microcomputer is started, a startup program stored in the non-volatile internal memory is executed to initialize the microcomputer and peripheral devices connected to the microcomputer; After the startup program is executed, a first application program stored in the non-volatile internal memory is executed, whereby a data string having a size indicated in a management table stored in a first external memory connected to the microcomputer is loaded from the first external memory to the volatile internal memory as a second application program, and after the second application program is loaded, execution of the second application program is started. A method for controlling the startup of a microcomputer.

8. 1. A compiling device that compiles a program to be executed by a microcomputer having a non-volatile internal memory, a volatile internal memory, and a CPU core that executes a program stored in the non-volatile internal memory and the volatile internal memory, compiling a boot program and a first application program to be stored in the non-volatile internal memory, and a second application program to be stored in the volatile internal memory; The object files generated by compiling are built on the memory map to generate a program file. extracting the second application program included in the program file as a data string; the startup program is a program for initializing the microcomputer, the program being executed by the CPU core when the microcomputer is started up; The first application program is a program that is executed by the CPU core after the startup program is executed, loads the data string of a second application program, the data string having a size indicated by size information included in a management table stored in a first external memory connected to the microcomputer, from the first external memory to the volatile internal memory, and starts execution of the second application program after loading the second application program. Compilation device.

9. A method for storing a second application program in a microcomputer having a non-volatile internal memory, a volatile internal memory, and a CPU core that executes programs stored in the non-volatile internal memory and the volatile internal memory, comprising the steps of: compiling a boot program and a first application program to be stored in the non-volatile internal memory, and a second application program to be stored in the volatile internal memory; The object files generated by compiling are built on the memory map to generate a program file. extracting the second application program included in the program file as a data string; storing the extracted data string and a management table including size information indicating the size of the data string in a first external memory connected to the microcomputer; The first application program executed after the microcomputer is initialized by the boot program loads a data string of the second application program having a size indicated by size information included in a management table stored in the first external memory from the first external memory to the volatile internal memory. A method for storing application programs in a microcomputer.

10. storing the extracted data string and the management table in an external device that is arranged outside the microcomputer and is capable of communicating with the CPU core; The data string and the management table stored in the external device are stored in a first external memory connected to the microcomputer.

10. A method for storing an application program in a microcomputer according to claim 9.

Images