Bootloader firmware failsafe update

Abstract

To improve a method of updating firmware.SOLUTION: A method of updating firmware stored in a non-volatile memory of a controller is disclosed. The non-volatile memory includes a first set of memory blocks configured to store a bootloader for the controller. The method includes storing a bootloader update application in a second set of memory blocks of the non-volatile memory, and storing a jump code in an initial memory block of the first set of memory blocks, where the jump code comprises an instruction to jump to an initial memory block of the second set of memory blocks.SELECTED DRAWING: Figure 4

Description

Technical Field

[0001] The present disclosure relates to a method for updating firmware of a system such as a fire protection system or an intrusion detection system.

Background Art

[0002] Systems such as fire protection systems and intrusion detection systems typically include a plurality of devices electrically connected, for example, in a loop configuration. For example, a fire protection system typically includes a fire protection control panel and one or more other fire protection devices such as fire detectors (such as smoke and heat sensors), manual call points, fire alarms, and fire extinguishing systems (such as sprinklers, fire barriers, smoke exhaust fans).

[0003] Each device of these systems can include an embedded microcontroller configured to execute an application that provides the base function of that device. This application can be provided as firmware, for example, the application code is stored in the non-volatile memory (such as flash memory) of the microcontroller.

[0004] In these systems, a so-called bootloader may also be provided as firmware, for example, the bootloader code is also stored in non-volatile memory. The bootloader is responsible for loading (starting) the application and also provides the device with the ability to update or replace the application code.

[0005] The applicant believes that there is room for improvement in the method for updating firmware.

Summary of the Invention

Means for Solving the Problems

[0006] The present invention relates to a method for updating firmware stored in the non-volatile memory of a controller, wherein the non-volatile memory comprises a first set of memory blocks configured to store a boot loader relating to the controller, and the method is The bootloader update application is stored in a second set of non-volatile memory blocks, Storing a jump code in the first memory block of a first set of memory blocks, wherein the jump code contains an instruction to jump to the first memory block of a second set of memory blocks. This provides a method that includes [something].

[0007] The present invention is a system, A controller having non-volatile memory, wherein the non-volatile memory is configured to store firmware relating to the controller, and the non-volatile memory comprises a first set of memory blocks configured to store a boot loader relating to the controller, The system The bootloader update application is stored in a second set of non-volatile memory blocks, Storing a jump code in the first memory block of a first set of memory blocks, wherein the jump code contains an instruction to jump to the first memory block of a second set of memory blocks. This also provides a system that is configured to update the firmware.

[0008] Various embodiments relate to methods for updating firmware stored in the non-volatile memory of a controller, such as a microcontroller, and in particular to methods for updating the firmware of a bootloader relating to a controller. According to this method, a bootloader update application is stored in a specific (second) set of memory blocks of the non-volatile memory. That is, the second set of memory blocks includes a first memory block, optionally one or more intermediate memory blocks, and a last memory block. The bootloader update application is an application that can operate to update (e.g., replace) an existing bootloader stored in a first set of memory blocks of the non-volatile memory. That is, the first set of memory blocks includes a first memory block, optionally one or more intermediate memory blocks, and a last memory block.

[0009] The applicant acknowledges that when the bootloader is being updated using conventional techniques, there is a significant risk that the (micro)controller may become inoperable (i.e., "bricked"), for example, if the controller loses power or is restarted in a different manner while the bootloader is being updated.

[0010] Therefore, according to various embodiments, as a step in updating the bootloader (i.e., as a step in the bootloader update application), the first memory block of a first set of memory blocks (i.e., the memory block of non-volatile memory that stores the bootloader's first data block) is replaced (overwritten) with jump code. Here, the jump code includes an instruction to jump to the first memory block of a second set of memory blocks (i.e., the memory block of non-volatile memory that stores the bootloader update application's first data block). The jump code may also include minimal startup code (i.e., code necessary to set the vector table and stack pointer) along with an instruction to jump to the first memory block of the second set of memory blocks.

[0011] In this regard, the applicant understands that if the controller loses (external) power, it may be possible to provide the controller with sufficient energy internally (for example, stored in one or more capacitors of the controller) to enable successful erasure and writing to at least one (or more) memory blocks of nonvolatile memory (for example, at least one group (e.g., rows) of memory blocks). This property effectively ensures that even if the controller loses power, the jump code will be successfully stored in the first memory block of the first set of memory blocks.

[0012] Furthermore, storing the jump code in the first memory block of the first set of memory blocks (i.e., replacing the first data block of the bootloader with the jump code) means that if the controller loses power or restarts otherwise while the (other) memory blocks containing the existing bootloader are being updated (replaced), when the controller restarts, the controller's processing will return to the bootloader update application via the jump code, bypassing the potentially erroneous or incomplete bootloader. The bootloader update application can then resume its operation and complete its update of the bootloader.

[0013] Therefore, it should be understood that various embodiments provide a fail-safe (i.e., power loss-resistant) method for updating the bootloader firmware.

[0014] The controller can be any suitable controller, such as an embedded controller for a device like a fire protection device or an intrusion detection device. The controller may be provided as a single integrated circuit (IC) chip, for example, a microcontroller or a system-on-a-chip.

[0015] This device may form part of a system such as a fire protection system or an intrusion detection system. The system may comprise multiple such devices, which may be electrically connected, for example, in a loop configuration.

[0016] For example, if the system is a fire protection system, it may comprise a fire control panel and multiple fire protection devices connected to the fire control panel. Therefore, the controller may be an embedded (micro) controller for fire protection devices such as fire detectors, smoke detectors, heat detectors, manual call points, fire alarms, fire protection devices, sprinklers, fire barriers, and smoke exhaust fans. If the system is an intrusion detection system, it may comprise an intrusion detection control panel and multiple intrusion detection devices connected to this intrusion detection control panel. Therefore, the controller may be an embedded (micro) controller for intrusion detection devices such as motion sensors and contact sensors.

[0017] A controller (for example, a microcontroller) may have a processor core along with one or more input / output stages. Optionally, the controller may also include random access memory (RAM) accessible from the processor core.

[0018] A controller (for example, a microcontroller) contains non-volatile memory. Non-volatile memory may consist of any suitable non-volatile memory, such as flash memory. Non-volatile memory may consist of multiple memory cells arranged in multiple memory blocks (alternatively known as memory "pages"). That is, here, each memory block (page) contains a subset of (different, non-overlapping) memory cells. Each memory block may be configured to store blocks of data (data blocks). Non-volatile memory may be configured such that each memory block can be written to independently of the other memory blocks. Therefore, a memory block (page) is the smallest set of memory cells that can be written in a single (write) operation. Non-volatile memory may consist of any suitable number of memory blocks.

[0019] Non-volatile memory may be configured such that each memory block can be erased independently of each other. However, more generally, non-volatile memory may be configured such that each group of multiple (e.g., four) memory blocks (e.g., each row of a memory block) can be erased independently of each other in the other groups of memory blocks (e.g., each row).

[0020] Each memory block may have its own address. Therefore, a sequence of memory addresses may be provided and defined for non-volatile memory, where each memory address in the sequence corresponds to (or relates to) an individual memory block of multiple memory blocks. Memory addresses may have either virtual or physical addresses.

[0021] Non-volatile memory may be configured (and may be configured) to store controller firmware, for example, in the form of appropriate code (e.g., machine-readable or other low-level code).

[0022] Firmware generally includes one or more applications along with a bootloader. Therefore, non-volatile memory may (and may) be configured to store one or more applications and bootloaders, for example, in the form of application code and bootloader code.

[0023] One or more applications may consist of any suitable applications or multiple applications, such as applications configured to provide the basic functionality of the device.

[0024] The bootloader may include any suitable bootloader, but in certain embodiments, the bootloader is a single-stage bootloader. It is also possible to use this bootloader as the first (earliest) stage of a multi-stage bootloader. The bootloader may be configured to load an application (to start it), and may also be configured to update or replace the application (code).

[0025] The controller may be configured such that a first set of memory blocks (of a plurality of memory blocks) is configured to store the bootloader (e.g., such that the first set of memory blocks is assigned to store the bootloader). The first set of memory blocks may include an initial memory block, optionally one or more intermediate memory blocks, and a final memory block. The first set of memory blocks may be a contiguous set of memory blocks (physically and / or logically), but this is not necessary.

[0026] The first set of memory blocks may have a first set of memory addresses (may be addressed by the first set of memory addresses). The first set of memory addresses may include an initial memory address, optionally one or more intermediate memory addresses, and a final memory address. The first set of memory addresses may be a contiguous set of memory addresses. The first set of memory addresses may be the earliest memory address in a sequence of memory addresses for non-volatile memory, but this is not necessary.

[0027] The controller may be configured such that memory blocks of a plurality of memory blocks other than the first set (i.e., memory blocks having addresses other than those of the first set) are configured to store one or more applications.

[0028] When the controller is powered on, it may be configured such that the bootloader is executed first. This may be achieved in any suitable manner. In various specific embodiments, when the controller is powered on, it is configured to execute the code stored in the first set of memory blocks, i.e., by first executing the code stored in the first memory block of the first set of memory blocks. For example, if the first memory block of the first set of memory blocks is a memory block of non-volatile memory having the earliest (first) memory address in the sequence of memory addresses for the non-volatile memory, the controller may be configured to execute the code stored in the memory block having the earliest (first) memory address in the sequence of memory addresses for the non-volatile memory when powered on.

[0029] After the controller executes the code stored in a particular block, it may then also be configured to execute the code stored in the next memory block (i.e., the memory block having the next memory address in the sequence of memory addresses for the non-volatile memory), etc. (except when the code being executed includes a jump instruction, as described in more detail below). In this way, if desired, the controller may execute the entire bootloader that may be stored across the first set of (multiple) memory blocks when powered on.

[0030] The bootloader may be configured to determine, for example, whether it is desired to update (e.g., replace) the application (code) by checking (external) signals (which may be sent, for example, from the control panel to the controller) and / or by checking the state of flags in non-volatile memory, or by other means. If it is determined that this is not necessary (unnecessary), the application may then be loaded (started), for example, by executing the appropriate application code stored in non-volatile memory.

[0031] However, if it is determined that updating (for example, replacing) the application (code) is desirable, the application (code) may be updated (replaced) (instead of loading the application), for example, by writing a block of new application code to non-volatile memory.

[0032] As stated above, the applicant acknowledges that in addition to updating the application, it may be necessary to update the bootloader, but that conventional techniques for updating the bootloader carry a significant risk of the controller becoming inoperable (i.e., "bricked") if, for example, the controller loses power or restarts in a different way while the bootloader is being updated or replaced (especially if the bootloader being updated is a single-stage bootloader or the first stage of a multi-stage bootloader).

[0033] Therefore, the embodiment provides a bootloader update application that may be operable to update (replace) an existing bootloader stored in non-volatile memory with new bootloader code. The bootloader update application may be configured to update the bootloader in a fail-safe (i.e., power loss resistant) manner.

[0034] The bootloader update application may be initially provided to the controller and stored in non-volatile memory. This may be done using the process described above to update the application.

[0035] Therefore, the (existing) bootloader may be executed, and external signals and / or flags may be set to cause the bootloader to determine that the application should be updated. The application may then be updated (for example, at least partially replaced) by the bootloader updating the application by writing a new block of code to non-volatile memory (at least partially in place of the existing application code).

[0036] The bootloader update application (code) is stored in a second set of memory blocks in non-volatile memory. This second set of memory blocks may be different from (non-overlapping with) the first set of memory blocks. The second set of memory blocks may include the first memory block, optionally one or more intermediate memory blocks, and the last memory block. The second set of memory blocks may, but does not have to be, a contiguous set of memory blocks (physically and / or logically).

[0037] A second set of memory blocks may have a second set of memory addresses (or may be addressed by a second set of memory addresses). The second set of memory addresses may include the first memory address, optionally one or more intermediate memory addresses, and the last memory address. The second set of memory addresses may be a contiguous set of memory addresses.

[0038] The bootloader update application (code), stored in the second set of memory blocks, may contain multiple data blocks. Similarly, jump code may also be stored in the second set of memory blocks.

[0039] Furthermore, the new bootloader code itself (or the parts of the bootloader code that will be replaced) may be stored in a second set of memory blocks. Alternatively, the instructions or a set of instructions that cause the controller to download the new bootloader code (or the parts of the bootloader code that will be replaced) from an external device, such as a control panel, and / or via a network connection, may be stored in a second set of memory blocks. The new bootloader code will consist of multiple data blocks, including an initial data block, optionally one or more intermediate data blocks, and a final data block.

[0040] Once the bootloader update application (and jump code and optionally a new bootloader) is stored in a second set of memory blocks, the controller may then execute the bootloader update application, for example, by executing the appropriate application code stored in the second set of memory blocks.

[0041] In various embodiments, the bootloader update application is configured to store jump code in the first memory block of a first set of memory blocks. The jump code may be stored in only the (single, earliest) first memory block of the first set of memory blocks, or it may be stored in a set of multiple memory blocks of the first set of memory blocks, including the (single, earliest) first memory block of the first set of memory blocks. For example, the jump code may be stored in the first group of memory blocks (e.g., a row) of memory blocks in the first set of memory blocks.

[0042] Therefore, when the bootloader update application runs, the controller stores the jump code in the first memory block of the first set of memory blocks. This may include a controller that copies the jump code stored in the second set of memory blocks (as described above) to the first memory block of the first set of memory blocks. Copying the jump code to the first memory block may include erasing the first memory block (for example, erasing the first group (e.g., rows) of memory blocks that contain the first memory block) and writing the jump code to the first memory block (for example, writing the jump code to the first group (e.g., rows) of memory blocks).

[0043] Jump code may include minimal startup code (i.e., startup code required to set up the vector table and stack pointer) and an instruction to jump (branch) to the first (first) memory block (i.e., the first (first) memory address) of a second set of memory blocks (i.e., the memory block where the first data block of the bootloader update application code is stored). This means that, when executed by a controller, the jump code causes the controller to branch to the bootloader update application stored in the second set of memory blocks.

[0044] Therefore, as a step to update the bootloader (i.e., as a step in the bootloader update application), the first memory block of the first set of memory blocks (i.e., the memory block of non-volatile memory that stores the bootloader's first (first) data block) is replaced (overwritten) by jump code. Here, the jump code contains an instruction to jump to the first memory block of the second set of memory blocks (i.e., the memory block of non-volatile memory that stores the bootloader update application's first (first) data block).

[0045] In this regard, the applicant understands that if the controller loses (external) power, it may be possible to provide the controller with sufficient energy internally (for example, by being stored in one or more capacitors of the controller or by being provided otherwise) to enable successful erasure and writing to at least one (or more) memory blocks (such as at least one (or more) groups (rows) of memory blocks) of nonvolatile memory. This characteristic effectively ensures that even if the controller loses power, the jump code will be successfully stored in the first memory block of the first set of memory blocks.

[0046] Furthermore, storing the jump code in the first memory block of the first set of memory blocks (i.e., replacing the first data block of the bootloader with the jump code) means that if the controller loses power or restarts otherwise while the (other) memory blocks containing the existing bootloader are being updated, and the controller restarts, the controller's processing will potentially return to the bootloader update application via the jump code, while bypassing the potentially erroneous or incomplete bootloader. The bootloader update application can then resume its operation and complete its update of the bootloader.

[0047] Therefore, it should be understood that various embodiments provide a fail-safe (i.e., power loss-resistant) method for updating the bootloader firmware.

[0048] In each embodiment, the controller may be configured such that one or more memory blocks of non-volatile memory can be reprogrammed (erased and written) without the controller receiving external power. For example, the controller may be configured such that two, four, six, eight, ten, or more memory blocks of non-volatile memory can be reprogrammed (erased and written) without the controller receiving external power. The controller may be configured such that one group (row) of memory blocks, or two or more groups (rows) of memory blocks, can be reprogrammed (erased and written) without the controller receiving external power. For example, the controller may be configured such that two, four, six, eight, ten, or more groups (rows) of memory blocks can be reprogrammed (erased and written) without the controller receiving external power. Configuring the controller so that two or more memory blocks of non-volatile memory can be programmed (erased and written) without the controller receiving external power provides a degree of redundancy to its advantage.

[0049] In each embodiment, before storing the jump code in the first memory block of the first set of memory blocks, the controller may determine whether the controller is currently receiving (external) power (and the bootloader update application may be configured to make this determination). If it is determined that the controller is currently receiving (external) power, the controller may proceed to the step of storing the jump code in the first memory block of the first set of memory blocks (and the bootloader update application may be configured to proceed to this step). If it is determined that the controller is not currently receiving (external) power (otherwise), the controller may not proceed to this step (otherwise) by, for example, canceling the bootloader update process or pausing the bootloader update process (in particular, pausing the storage of the jump code in the first memory block of the first set of memory blocks) until it is determined that power is present (and the bootloader update application may be configured not to proceed to this step). This ensures that the controller has sufficient power to successfully store the jump code.

[0050] Once the jump code is stored in the first(or more) memory block(s) of the first set of memory blocks, the controller may then store new bootloader data blocks (i.e., the intermediate and last memory blocks that do not include the first(or more) data block(s)) in the memory blocks of the first set of memory blocks other than the first(or more) memory block(s) (and the bootloader update application may also be configured to store them). In other words, the controller may store new bootloader data blocks (excluding the first(or more) data block(s)) in the memory blocks of the first set of memory blocks other than the first(or more) memory block(s) of the first set of memory blocks (which contains the jump code).

[0051] If the controller loses power or restarts otherwise during this process, please understand that when the controller restarts, it will return to running the bootloader update application, bypassing any potentially erroneous or incomplete bootloaders. The bootloader update application can then complete its operation to fully update the bootloader.

[0052] In various embodiments, before the above step of determining whether the controller is currently receiving power, the controller may determine whether the jump code is already stored in the first memory block(s) of a first set of memory blocks (and the bootloader update application may be configured to do so). If it is determined that the jump code is already stored in the first memory block(s) of a first set of memory blocks, the controller may proceed to the above process of storing the new bootloader data blocks, excluding the first data block(s), in the memory blocks of the first set of memory blocks, excluding the first (first) data block(s) (and the bootloader update application may be configured to do so). This determination may be made if the controller lost power or was restarted in a different way during a previous attempt at updating the bootloader.

[0053] On the other hand, if it is determined that the jump code is not yet stored in the first(or more) memory block of the first set of memory blocks (and is not to be stored there), the controller may proceed to the above step of determining whether the controller is currently receiving (external) power (and then, for example, storing the jump code in the first(or more) memory block of the first set of memory blocks) (and the bootloader update application may also be configured to proceed).

[0054] When new bootloader data blocks other than the initial data block(s) are stored in the first set of memory blocks (other than the initial memory block(s)), the controller may then determine (again) whether the controller is currently receiving (external) power (and the bootloader update application may be configured to do so).

[0055] If the controller is determined to be currently receiving (external) power, it may store the first data block(s) of the new bootloader in the first memory block(s) of the first set of memory blocks (i.e., by overwriting jump code) (and the bootloader update application may be configured to do so). If the controller is determined to be not currently receiving (external) power (otherwise), the controller may not proceed to this step (or not proceed) by, for example, canceling the bootloader update process or pausing the bootloader update process (in particular, pausing the storage of the first data block(s) of the new bootloader in the first memory block(s) of the first set of memory blocks) until power is determined to be present (and the bootloader update application may be configured not to proceed to this step). This ensures that the controller has sufficient power to successfully store the first data block(s) of the new bootloader in the first memory block(s) of the first set of memory blocks (even if the controller loses power).

[0056] The bootloader update process is complete when the first data block(s) of the new bootloader is stored in the first memory block(s) of the first set of memory blocks, and the functionality of the bootloader update application may be disabled. It should be understood that upon restart, the controller will now execute the new bootloader.

[0057] In various embodiments, before the above step of determining whether jump code is already stored in the first memory block(s) of the first set of memory blocks, the controller may determine whether a new bootloader is (completely) stored in the first set of memory blocks (and the bootloader update application may be configured to make this determination).

[0058] If the controller determines that the new bootloader has been (completely) stored in the first set of memory blocks, it may proceed to the above step of disabling the functionality of the bootloader update application (and the bootloader update application may be configured to proceed). This determination may be made during a previous attempt to update the bootloader, for example, if the controller lost power before or during the disabling step. This determination may also be made when an attempt is made to update the bootloader if this has already been done, or instead.

[0059] On the other hand, if the controller determines that the new bootloader is not fully stored in the first set of memory blocks (i.e., is not stored there), the controller may proceed to the above step of determining whether the jump code is already stored in the first memory block (or more) of the first set of memory blocks (and the bootloader update application may be configured to proceed to this step).

[0060] All aspects and embodiments described herein may, as necessary, include one or more or all of the preferred and optional features described herein, and the same applies to each embodiment.

[0061] The methods described herein may be carried out, at least in part, using software, such as a computer program. Therefore, in further aspects, the present invention may be found to provide computer software specifically adapted to carry out the methods described herein when installed on a data processing means; computer program elements including a code portion of the computer software for carrying out the methods described herein when the program elements are executed on the data processing means; and computer programs including code means adapted to carry out the steps of the methods described herein, or all of the steps of the multiple methods, when the program is executed on a data processing system. The data processing system may be a microprocessor, a programmable FPGA (field-programmable gate array), and the like.

[0062] When used to operate a fire protection system or intruder detection system including a data processor, the present invention also extends to a computer software carrier including such software that, in association with the data processor, causes the system to perform steps of the method described herein. Such a computer software carrier may be a physical recording medium such as a ROM chip, CD-ROM, or disk, or it may be a signal such as an electronic signal transmitted over a wire, or an optical signal or a wireless signal transmitted to a satellite or the like.

[0063] It is not necessary to perform all steps of the methods described herein by computer software; therefore, from a broader aspect of the present invention, it should be further understood that computer software for performing at least one of the steps of the methods described herein, and such software installed on a computer software carrier, may be provided.

[0064] The present invention may therefore be appropriately embodied as a computer program product for use in a computer system. Such embodiments may include a set of computer-readable instructions fixed on a tangible medium, such as a non-temporary computer-readable medium, for example, a diskette, CD-ROM, ROM, or hard disk. Such embodiments may also include a set of computer-readable instructions that can be transmitted to a computer system via a modem or other interface device, via a tangible medium, including, but not limited to, optical or analog communication lines, or intangibly using wireless technology, including, but not limited to, microwave, infrared, or other transmission techniques. A set of computer-readable instructions embodies all or part of the functions described herein.

[0065] Such computer-readable instructions can be written in multiple programming languages ​​for use in many computer architectures or operating systems. Furthermore, these instructions may be stored using any existing or future memory technology, including, but not limited to, semiconductor, magnetic, or optical, or transmitted using any existing or future communication technology, including, but not limited to, optical, infrared, or microwave. Such computer program products may be distributed as removable media with print or electronic documentation, such as shrink-wrapped software; pre-loaded into computer systems, such as system ROM or fixed disks; or distributed across networks from servers or electronic bulletin boards, such as the Internet or the World Wide Web.

[0066] Specific preferred embodiments of the present invention will be described with reference to the following drawings for illustrative purposes only. [Brief explanation of the drawing]

[0067] [Figure 1]These are schematic diagrams of fire protection systems according to various embodiments. [Figure 2] This is a flowchart showing the traditional method for updating the bootloader firmware. [Figure 3] This flowchart shows a fail-safe method for updating bootloader firmware according to various embodiments. [Figure 4] This is a flowchart showing methods according to various embodiments. [Figure 5] This is a schematic diagram of bootloader update firmware according to various embodiments. [Figure 6] Figures A through E are schematic diagrams showing states of non-volatile memory during the bootloader update process according to various embodiments. [Figure 7] This is a schematic diagram of a method for determining the number of programmable pages by the microcontroller after power loss. [Modes for carrying out the invention]

[0068] Figure 1 is a schematic diagram of a fire protection system according to various embodiments. As shown in Figure 1, the system comprises a set of fire protection devices 12 and a power source (loop driver) 11 electrically connected in a loop configuration. Each fire protection device 12 may be, for example, a fire detector, smoke detector, heat detector, manual call point, fire alarm, fire extinguishing component, sprinkler, fire barrier, smoke exhauster, etc. The power source (loop driver) 11 may be controlled by and / or part of another part of the fire protection system 10, such as a (fire) control panel.

[0069] In the embodiment shown in Figure 1, the system is a fire protection system, but it should be understood that the system can be any suitable system, such as an intrusion detection system. If the system is an intrusion detection system, it may include an intrusion detection control panel and multiple intrusion detection devices connected to this intrusion detection control panel. Each intrusion detection device may be a motion sensor, a contact sensor, etc.

[0070] Each device 12 in the set of devices may be electrically connected to and receive power from a power source (loop driver) 11 by wiring, for example, a pair of conductors 13 and 14. The conductors 13 and 14 may act, for example, as a neutral wire and a wire carrying current, respectively. As can be seen in Figure 1, the wiring may be arranged in a loop configuration, that is, so that each conductor 13 and 14 starts and ends at the power source (loop driver) 11. Thus, power may be supplied by the power source (loop driver) 11 at both ends of the loop wiring.

[0071] The fire protection system is configured such that each device 12 can communicate with the fire protection control panel 10, for example, via wiring 13, 14 and a loop driver 11. Specifically, as shown in Figure 1, the control panel 10 can send update requests and data to one or more of the devices 12, or each of them, via, for example, the loop driver 11 and wiring 13, 14.

[0072] Similarly, as shown in Figure 1, one or more, or each, of the devices 12 includes an embedded microcontroller 15 configured to run an application that provides the base functionality of the device. This application is provided as firmware, where the application code 17 is stored in the non-volatile memory 16 of the microcontroller 15 (e.g., self-programmable flash memory).

[0073] The so-called bootloader is also provided as firmware, and here, the bootloader code 18 is also stored in the non-volatile memory 16. The bootloader is responsible for loading (starting) the application and also provides the device 12 with the ability to update or replace the application code 17. This enables on-site updates of the application firmware. In each embodiment, the bootloader is a single-stage bootloader, but it is also possible to make this bootloader the first stage of a multi-stage bootloader.

[0074] As similarly shown in Figure 1, a first set of memory blocks (or "pages") of the non-volatile memory 16 stores the bootloader code 18, and the remaining memory blocks store the application code 17. When the microcontroller 15 is started (powered on), the bootloader code 18 is executed first by executing the code stored in the first set of memory blocks.

[0075] The bootloader may determine whether it is desired to update (e.g., replace) the application code 17 by checking external signals received from the control panel 10 or another location, and / or by checking the state of flags in the non-volatile memory 16. If this is not desired, the application is then started by executing the appropriate application code 17 stored in the non-volatile memory 16. However, if it is determined that it is desired to update (e.g., replace) the application code 17, the application code 17 can be updated (replaced) by overwriting the existing application code 17.

[0076] Application code updates are always possible with an active bootloader. As stated above, the applicant recognizes that in addition to updating application code 17, it may be necessary to update bootloader code 18, for example, to fix bugs in the bootloader code or to extend its functionality.

[0077] However, as shown in Figure 2, conventional techniques for doing this carry a significant risk that the microcontroller 15 may become inoperable (i.e., "bricked"). As shown in Figure 2, during such a conventional process, the microcontroller 15 is started (step 20), the bootloader is started (step 21), the bootloader update process is initiated (step 22), and then the bootloader code is updated (replaced) by overwriting the existing bootloader code 18 (step 23). However, if the microcontroller 15 loses power or restarts in a different way while the new bootloader code is being copied (step 24), the device may become unusable (i.e., "bricked") (step 25).

[0078] Each embodiment provides a bootloader update application that can be operated to update existing bootloader code 18 stored in non-volatile memory 16 with new bootloader code. Each embodiment can replace the bootloader firmware in a fail-safe manner, that is, it can be replaced in a manner that is adaptable to malfunctions such as power loss or unexpected restarts.

[0079] According to various embodiments, the bootloader update application is first provided to the microcontroller 15 and stored as an application in non-volatile memory 16. This may be done in a fail-safe manner using a conventional process for updating the application code 17. The bootloader update application code is stored in a specific (second) set of memory blocks in non-volatile memory 16 and in a specific (second) set of memory addresses relating to non-volatile memory 16.

[0080] Once the bootloader update application is stored in the non-volatile memory 16, the controller may then activate (execute) the bootloader update application. This process is illustrated in Figure 3. As shown in Figure 3, in this process, the microcontroller 15 is started (step 30), the bootloader is started (step 31), and the bootloader update process is started (step 32).

[0081] Next, the first (earliest) memory block of the first set of memory blocks (i.e., the memory block in non-volatile memory 16 that stores the earliest data blocks of the bootloader code 18) (for example, the memory block at address zero) is replaced (overwritten) with jump code (step 33). This may involve erasing the first (earliest) group (row) of the memory block and then writing the jump code to the first (earliest) group (row) of the memory block. The jump code may be stored only in the first (earliest) memory block, but it is also possible to store the jump code in two or more of the first (earliest) memory blocks (i.e., two or more memory blocks in the first (earliest) group (row) of the memory block). The jump code includes minimal startup code (i.e., startup code required to set the vector table and stack pointer) and an instruction to jump to a first address where the bootloader's update application code is stored in non-volatile memory 16.

[0082] In this regard, the applicant recognizes that if the microcontroller 15 were to lose (external) power, sufficient energy could be initially supplied to the microcontroller 15 (for example, stored in one or more capacitors of the microcontroller 15) so that at least one memory block (or at least one group (row) of memory blocks, etc.) of the non-volatile memory 16 could be successfully programmed. This property effectively ensures that the jump code would be successfully stored even if the microcontroller 15 were to lose power. In other words, the jump code copy step (step 33) is effectively a "minute" operation, as its duration can be considerably shorter than the discharge time of the power supply circuit of the microcontroller 15.

[0083] Next, the bootloader code is updated (replaced) by overwriting the existing bootloader code 18 (step 34).

[0084] As shown in Figure 3, if the microcontroller 15 loses power or restarts otherwise while the new bootloader code is being copied (step 35), upon restarting, the microcontroller 15 first executes a jump code (step 36), thereby causing the microcontroller 15 to then execute the bootloader update application, allowing the copying of the new bootloader code to continue (step 37), while bypassing potentially erroneous or incomplete bootloader code. Once this bootloader update process is successfully completed, the bootloader update application can be disabled (step 38), and the new bootloader can be started (step 39).

[0085] It should be understood that each embodiment provides a bootloader update application that can operate to update existing bootloader code 18 stored in non-volatile memory 16 with new bootloader code in a fail-safe manner. Specifically, the bootloader update process is resistant to power loss or unexpected restarts.

[0086] Figure 4 is a more detailed flowchart illustrating the operation of the bootloader update application.

[0087] As shown in Figure 4, when the bootloader update application is started, the first step is to determine whether the new bootloader has already been (completely) copied to the first set of memory blocks (step 40).

[0088] If it is determined that the new bootloader has been (completely) stored in the first set of memory blocks, the bootloader update application may be disabled (step 47), and the process may terminate. This determination is made during a previous attempt to update the bootloader, for example, if the microcontroller 15 lost power before or during the disabling step (step 47). This determination may also be made if an attempt is made to update the bootloader after this has already been done.

[0089] On the other hand, if in step 40 it is determined that the new boot loader is not fully stored in the first set of memory blocks, the determination may be made based on whether the jump code is already stored (programmed) in the first memory block (or more) of the first set of memory blocks (step 41).

[0090] If it is determined that the jump code is already stored in the first memory block(s) of the first set of memory blocks, the process may proceed to store the new bootloader data blocks, excluding the first data blocks(s), in the memory blocks of the first set of memory blocks, excluding the first (first) memory block(s) (where the jump code is stored) (step 44). In other words, the microcontroller 15 may store the new bootloader data blocks, excluding the first data blocks(s), in the memory blocks of the first set of memory blocks, excluding the first (first) memory block(s) of the first set of memory blocks, excluding the first data blocks(s). This determination is made when the controller loses power or restarts in a different way during a previous attempt to update the bootloader.

[0091] On the other hand, if it is determined that the jump code is not yet stored in the first memory block (or more) of the first set of memory blocks, a check is performed to determine if the microcontroller 15 is currently receiving external power (step 42).

[0092] If the microcontroller 15 determines that it is currently receiving external power, it can proceed to the step of storing a jump code in the first memory block(s) of the first set of memory blocks (step 43). In other words, the microcontroller 15 first verifies that power is present, and then replaces the first flash page of memory 16 with a jump code to the address of the bootloader update application.

[0093] If the microcontroller 15 is determined not to be receiving external power, it may not proceed to this step by, for example, canceling the bootloader update process or pausing the bootloader update process (in particular, pausing the writing of jump code to the first memory block(s) of the first set of memory blocks) until power is determined to be present. This ensures that the microcontroller 15 has sufficient power to successfully complete the writing of the jump code.

[0094] Once the jump code is stored in the first memory block(s) of the first set of memory blocks, the bootloader update application can proceed to the process of storing the new bootloader data blocks, other than the first data blocks(s), in the memory blocks of the first set of memory blocks other than the first memory block(s) (step 44). If the microcontroller 15 loses power during this process, it should be understood that when the microcontroller 15 is restarted, it will return to execution of the bootloader update application, bypassing the bootloader which may contain errors or be incomplete. The bootloader update application can therefore complete its operation of updating or replacing the bootloader (completely).

[0095] Therefore, after the jump code is programmed, the application can safely begin copying the new bootloader pages to the first set of memory pages, except for the first page.

[0096] Once new bootloader data blocks other than the initial data block(s) are stored in the first set of memory blocks, the controller may then check again whether the controller is currently receiving external power (step 45).

[0097] If the microcontroller 15 determines that it is currently receiving external power, the microcontroller 15 may store the first data block(s) of the new bootloader in the first memory block(s) of the first set of memory blocks (i.e., it may store them by overwriting the jump code) (step 46). In other words, before replacing the first flash page, the application verifies that power is present and then programs the first page with the new bootloader data.

[0098] If the microcontroller 15 determines that it is not receiving external power, it may not proceed to this step by, for example, canceling the bootloader update process or pausing the bootloader update process (in particular, pausing the writing of the first data block(s) of the new bootloader to the first memory block(s) of the first set of memory blocks) until it determines that power is present. This ensures that the microcontroller 15 has sufficient power to successfully complete the writing of the first data block(s) of the new bootloader to the first memory block(s) of the first set of memory blocks.

[0099] When the first data block(s) of the new bootloader is stored in the first memory block(s) of the first set of memory blocks, the bootloader update process is complete and the bootloader update application is disabled (step 47). Upon restart, the microcontroller 15 will execute the new bootloader (in the manner described above).

[0100] Figure 5 shows a configuration for providing a bootloader update application according to each embodiment. As shown in Figure 5, the bootloader update application code 50 may be provided together with jump code 51 and also together with new bootloader code 52. The bootloader update code 50 is the code that executes the logic of the bootloader update application described above. The jump code 51 can be (e.g., minimal) code that needs to be executed (on a particular device) in order to perform a jump (branch) to the bootloader update application code.

[0101] These three elements may be combined to form bootloader update firmware 53, which is stored (in the manner described above) in a second set of memory blocks in non-volatile memory 16. As shown in Figure 5, bootloader update firmware 53 can be formed by linking the compiled update bootloader code with jump code and the binary of the new bootloader firmware. The jump object and the binary of the bootloader firmware may be placed at addresses predetermined by the linker.

[0102] However, various other embodiments are possible. For example, the bootloader code 52 does not need to be provided as part of the bootloader update firmware 53 stored in the non-volatile memory 16. The bootloader update firmware 53 could instead include one or more instructions for downloading the new bootloader code 52, for example, from a control panel and / or via a network connection.

[0103] Figure 6 schematically shows the state of the non-volatile memory 16 during the various steps of the bootloader update process described above. As shown in Figure 6A, the non-volatile memory 16 initially stores the old bootloader code 18 and the application firmware code 17. As shown in Figure 6B, the application 17 is then overwritten by the bootloader update firmware 53. In this embodiment, this bootloader update firmware 53 includes the bootloader update logic, jump code, and a new bootloader.

[0104] As shown in Figure 6C, the jump code is copied to the first memory address of the non-volatile memory 16. Next, as shown in Figure 6D, the old bootloader code 18 is updated with the new bootloader code (except for the first block(s)). Finally, as shown in Figure 6E, the jump code is overwritten with the first block(s) of the new bootloader code. Upon restart, the microcontroller 15 will now execute the new bootloader as desired.

[0105] As described above, each embodiment relies on a power supply circuit of the microcontroller 15 to provide sufficient energy to safely program at least one (or more) flash pages after the microcontroller 15 has been disconnected from the power source. Based on this characteristic, the update logic first replaces the first page of the old bootloader with jump code to the address of the update firmware code. This update firmware code ensures that the bootloader update process continues even after an unexpected interruption (e.g., power loss).

[0106] Therefore, in order to provide a fail-safe update process that is resistant to power loss, the device must be configured such that its power source provides sufficient energy for the safe programming of at least one flash page after the loss of external power.

[0107] Figure 7 shows a process for determining the number of memory blocks in the non-volatile memory 16 that can be programmed when the microcontroller 15 is not receiving external power. The provided algorithm measures the duration of the power-off period and the number of pages programmed during that period. As shown in Figure 7, in this process, the microcontroller 15 is first started up (step 60), then the power supply function is disabled (step 61), and the microcontroller 15 is made to program multiple pages (step 62). If the microcontroller 15 is eventually restarted due to power loss (step 63), the number of pages successfully programmed can be determined (step 64).

[0108] If the number of programmed pages during the power-off period is greater than a certain minimum desired threshold (e.g., >8), the bootloader update algorithm can be safely applied in the field. However, if the number of programmed pages is less than the desired threshold, the capacitance on the printed circuit board can be increased to satisfy the above condition.

[0109] It should be understood that various embodiments provide bootloader update firmware that is resistant to power loss during the bootloader update process.

[0110] The detailed description above is provided for illustrative and explanatory purposes only. It is not intended to be exclusive or to limit the Art to any strict form of disclosure. Many variations and modifications are possible in light of the teachings above. The embodiments described have been selected to best illustrate the principles of the Art and its practical applications, thereby enabling other persons skilled in the art to best utilize the Art in various embodiments and with various modifications appropriate to specific conceivable uses. The scope is intended to be defined by the appended claims.

Claims

1. A method for updating firmware stored in the non-volatile memory of a controller, wherein the non-volatile memory comprises a first set of memory blocks configured to store a boot loader relating to the controller, and the method is The boot loader update application is stored in a second set of memory blocks of the aforementioned non-volatile memory, The storage of a jump code in the first memory block of a first set of memory blocks, wherein the jump code includes an instruction to jump to the first memory block of a second set of memory blocks. Includes, In the event that the controller loses external power, energy is internally supplied to the controller so that, in order to ensure that the jump code is stored correctly, the controller can erase and write at least one memory block of the non-volatile memory without receiving external power. method.

2. The method according to claim 1, wherein storing a jump code in the first memory block of the first set of memory blocks includes replacing the first memory block of the first set of memory blocks with the jump code.

3. The method according to claim 1 or 2, wherein the controller is configured such that it can store data in one or more memory blocks of the non-volatile memory without receiving external power.

4. The method according to any one of claims 1 to 3, further comprising determining whether the controller is receiving external power before storing the jump code in the first memory block of the first set of memory blocks.

5. The method according to any one of claims 1 to 4, further comprising determining whether the jump code is already stored in the first memory block of the first set of memory blocks before storing the jump code in the first memory block of the first set of memory blocks and / or before determining whether the controller is receiving external power.

6. The method according to any one of claims 1 to 5, further comprising determining whether a new boot loader is stored in the first set of memory blocks before storing the jump code in the first memory block of the first set of memory blocks, and / or before determining whether the controller is receiving external power, and / or before determining whether the jump code is already stored in the first memory block of the first set of memory blocks.

7. The method according to any one of claims 1 to 6, further comprising storing the new boot loader relating to the controller in the non-volatile memory by storing the data blocks of the new boot loader, other than the first data blocks of the new boot loader, in the memory blocks of a first set of memory blocks other than one or more of the first memory blocks.

8. The method according to claim 7, further comprising determining whether the controller is receiving external power before storing the one or more first data blocks of the new boot loader in the one or more first memory blocks of the first set of memory blocks.

9. A method for updating firmware stored in the non-volatile memory of an embedded controller of a fire protection device or intrusion detection device, wherein the method includes updating the firmware of the embedded controller using the method according to any one of the prior claims.

10. A computer program, which includes computer software code for carrying out the method described in any one of the prior claims when the program is executed by a data processing means.

11. A controller configured to carry out the method described in any one of claims 1 to 9.

12. A fire protection device or intrusion detection device comprising the controller described in claim 11.

13. It is a system, A controller comprising non-volatile memory, wherein the non-volatile memory is configured to store firmware relating to the controller, and the non-volatile memory comprises a first set of memory blocks configured to store a boot loader relating to the controller, The aforementioned system The boot loader update application is stored in a second set of memory blocks of the aforementioned non-volatile memory, The storage of a jump code in the first memory block of a first set of memory blocks, wherein the jump code includes an instruction to jump to the first memory block of a second set of memory blocks. The firmware is configured to be updated accordingly. In the event that the controller loses external power, energy is internally supplied to the controller so that, in order to ensure that the jump code is stored correctly, the controller can erase and write at least one memory block of the non-volatile memory without receiving external power. system.

14. The system is configured such that the controller can store data in one or more memory blocks of the non-volatile memory without receiving external power, The system according to claim 13, wherein the system is configured to determine whether the controller is receiving external power before storing the jump code in the first memory block of the first set of memory blocks.

15. The aforementioned system The first set of memory blocks, excluding one or more initial memory blocks, stores the data blocks of the new boot loader, excluding one or more initial data blocks of the new boot loader, The controller is to determine whether it is receiving external power, The one or more first data blocks of the new boot loader are stored in the one or more first memory blocks of the first set of memory blocks, The system according to claim 13 or 14, wherein the non-volatile memory is configured to store the new boot loader for the controller.

16. The system according to any one of claims 13, 14, or 15, wherein the system is a fire prevention system or an intrusion detection system.

Images