DE102010016257A1 - Method for updating firmware of field programmable gate array utilized in e.g. programmable logical circuit for controlling industrial process, involves rejecting data file in dependent upon result of identifier verification - Google Patents

Abstract

The method involves receiving a new firmware data file at a field programmable gate array (FPGA) (10). The file comprises a hardware identifier, which characterizes a circuit configuration and is attached to a source of a firmware. The hardware identifier is verified in relation to a comparison identifier that is stored in the FPGA. The hardware identifier comprises a manufacturer identifier and/or revision number. The new firmware data file is accepted and stored in processor units (12, 14) i.e. FPGA units. The new firmware data file is rejected in dependent upon the result of verification. An independent claim is also included for a firmware updatable system that comprises an interface.

Description

Field of the invention

The present invention relates to methods and apparatus for updating firmware of a system having at least one programmable device.

State of the art

Programmable logic circuits, such as so-called FPGAs (Field Programmable Gate Arrays), are used to an ever increasing extent both for controlling industrial processes and in household electronics. One advantage of such programmable circuits is that by updating their firmware they can participate in technical advancements without having to replace the hardware.

However, updating firmware is by no means problem-free and risk-free in practice. In the experience, it is very common for a user to inadvertently replace the existing firmware file of the system with an incompatible or at least not completely compatible new firmware file. Such errors may be due to carelessness of the user as well as to exchanged version numbers or incomplete documentation of the firmware or the underlying hardware.

Since firmware files are often quite similar to one another, there is a risk that such an error will not be noticed during the update and that the previous firmware file will be replaced by a new firmware file that is incompatible with the hardware. As a result, the functionality of the system can be restricted or canceled. Particular dangers threaten when the system updated with a not completely system-compatible firmware after the update seems to work without interruption, so that the user can not immediately notice the error, but fails later in a critical situation. This is particularly dangerous because firmware programmable and updateable circuits are also widely used in safety critical applications such as controlling the braking system of motor vehicles or controlling flowmeters in power plants.

The prior art addresses this problem with updating methods in which, before overwriting the old firmware, an automatic synchronization between a system revision number and a revision number of the new firmware file takes place to ensure compatibility. This can be avoided, that erroneously a wrong firmware is loaded.

One such verification method is in the patent US 6,360,362 B1 described using the example of a digital camera: The camera manufacturer assigns its digital cameras revision numbers, each of which corresponds to one or more firmware identifiers. To update a firmware, the camera is connected via a proprietary interface to a host system, such as a user's personal computer. The host system queries the revision number of the connected camera via the interface and automatically selects the appropriate firmware, which is subsequently transmitted to the camera via the interface, where it replaces the previous firmware file.

A disadvantage of such a proprietary solution is, from the user's point of view, first, that a firmware update always requires connection to a host computer equipped and set up for revision comparison.

On the other hand, that protects in the US 6,360,362 B1 proposed solution against user error in the firmware update only insufficient. The weakness of the procedure can be seen by assuming that the camera manufacturer licenses its verification software to two other camera manufacturers who know nothing about each other, as often happens in practice. Both licensees will each develop their own camera model and assign revision numbers independently of each other for this hardware. There is therefore the risk that a camera of the first licensee is connected to the host program of the second licensee and therefore erroneously updated with the firmware of the second licensee, for example, the firmware, which the second licensee under the same camera vision number for his own cameras provides. The bootloader may not uncover this misconfiguration during testing, so the previous firmware will be replaced by incompatible firmware from the wrong manufacturer and the camera may become unusable.

A firmware update method of matching a firmware identifier to a hardware identifier that identifies or authenticates an individual computer user system is described in the application notes US 2009/0064125 A1 and US 2009/0247124 A1 described. Such methods require an individual identifier for each user system and therefore a complex identifier management.

In view of the background of the prior art, it is an object of the present invention to provide an improved and simplified method and system for updating a firmware, which avoids the aforementioned problems and allows a reliable compatibility check.

Overview of the invention

This object is achieved by the method according to the invention with the features of the independent claims 1 and 6 and by the system having the features of claim 8. The dependent claims relate to preferred embodiments.

An inventive method for updating a firmware of a system comprising at least one programmable device comprises the step of receiving at the system, the system, a new firmware file comprising at least one identifier associated with a source of the firmware and / or indicative of a circuit configuration A step of checking the identifier against at least one comparison identifier stored in the system, wherein the checking is performed in the system, and the step of accepting the new firmware file and placing the new firmware file in the programmable device or the step of rejecting the new one Firmware file, depending on a result of testing.

By associating the firmware file identifier with a source of firmware, such as a manufacturer, or identifying a circuit configuration of the system to which it is compatible, it allows for reliable system compatibility testing. In particular, the solution according to the invention effectively excludes errors in the compatibility check which result from the fact that different manufacturers often use identical revision numbers. For example, unique computer-readable hardware identifiers can be assigned worldwide. Such an identifier within the meaning of the invention is preferably not exclusively a manufacturer-specific revision number (although it may comprise such a revision number) and also no serial number or authentication identifier, which identify an individual system, but includes a manufacturer identification and / or encodes the circuit diagram of the system or represents the circuit diagram of the system.

By checking the identifier against a system-stored comparison identifier in the system, a compatibility check independent of the host system is enabled and, in addition, effectively ensuring that a firmware file in the system will not be without such a previous compatibility check by a new firmware file is replaced.

A system according to the invention is any configuration of analog and / or digital components wired according to a specific circuit diagram, wherein at least one of the components is programmable. The building blocks of such a system can be, for example, FPGAs, CPUs, RAM memory modules and / or flash memory modules. A system may also contain subsystems each with its own CPU, RAM and / or flash components that form, for example, a computer network.

The comparison identifier stored in the system, like the identifier of the firmware file, can identify a source of the firmware and / or a circuit configuration of the system. If the checking of the identifier comprises the comparison of the identifier with the comparison identifier, the identifier and the comparison identifier can correspond largely or completely to one another. It is then only a convention question, which of the two in the sense of this document as "identifier" and which is referred to as "comparison identifier".

Preferably, the firmware file comprises a plurality of identifiers and the checking of the identifier comprises comparing, in particular successively comparing, at least a subset of the plurality of identifiers with a comparison identifier stored in the system. The various identifiers may identify the different system configurations and / or revisions for which the firmware is appropriate.

In a further preferred embodiment, the checking of the identifier comprises comparing the identifier with a plurality of comparison identifiers stored in the system, for example with a list or table of comparison identifiers. This makes it possible to check quickly and reliably whether the new firmware file is compatible with the system.

The checking of the identifier preferably comprises loading the new firmware and loading the comparison identifier and / or a previous firmware file into a test element. In the test element can be checked in this way, the comparison identifier against an identifier of the firmware file.

The new firmware file can be stored in non-volatile memory, preferably in an EEPROM (Electrically Erasable Programmable Read-Only Memory).

In a further development, the method according to the invention comprises the deletion of a preceding firmware file from the programmable module, wherein the deletion takes place only in the case of the previous acceptance of the new firmware file. Checking the ID before deleting the previous firmware file ensures that the system is always equipped with system-compatible firmware, effectively and effectively avoiding system malfunctions.

In one development of the invention, the method may also include checking the successful filing of the new firmware file and optionally additionally documenting the successful filing by a check number, for example a so-called magic number.

In a preferred embodiment of the invention, the system includes memory for storing factory-preset factory programming. In the method according to the invention, in the case of the rejection of the new firmware file, the factory programming is loaded into the programmable module. This ensures that if the update fails, the system will fall back into system-compatible factory programming and remain operational. In a subsequent step, the system may be retried to update with a different firmware file.

In a development of the abovementioned embodiment, the method comprises a step of checking the successful loading of the factory programming into the programmable module and optionally additionally documenting the successful loading of the factory programming by a check number, for example by a so-called magic number.

In a preferred embodiment, before checking the identifier, the data format of the new firmware file is checked. Checking the data format of the new firmware file may represent a coarse grid that allows the fast rejection of obviously system incompatible firmware files without the need for tag matching.

In a preferred embodiment, the identifier comprises a manufacturer identifier and / or a revision number.

In one development of the invention, the method comprises connecting two systems, which each comprise at least one programmable module and in which in each case at least one comparison identifier according to one of the aforementioned embodiments is stored, to form an overall system, and assigning an overall comparison identifier to the overall system and storing the assigned overall comparison identifier in the overall system.

As a result, a common overall comparison identifier can also be assigned when assembling a plurality of subsystems to form an overall system, which enables a reliable compatibility check when updating the entire system and / or its subsystems with new firmware.

The method for assigning a comparison identifier for firmware updating to a composite system is an independent aspect of the invention and comprises connecting at least two individual systems to form an overall system, wherein at least one of the individual systems comprises at least one programmable module and stores at least one comparison identifier, wherein the comparison identifier is associated with a source of firmware and / or identifies a circuit configuration of the single system, and the step of assigning a total comparison identifier to the overall system and the step of storing the assigned overall comparison identifier in the overall system.

In particular, each of the at least two individual systems can comprise a programmable component.

The overall comparison identifier preferably identifies the circuit configuration of the overall system.

The invention also includes a firmware updatable system having an interface for receiving a firmware file, a programmable device in which the firmware file is storable, a memory configured to store at least one comparison identifier, the comparison identifier of a source the firmware is assigned and / or a circuit configuration of the system is characterized, and with a test element which is adapted to check the comparison identifier against at least one identifier of the firmware file.

As noted above, a system of the invention provides effective protection against inadvertent or intentional updating of the system with incompatible firmware, thereby preventing malfunction of the system.

In one development of the invention, the system comprises at least two programmable components and a memory which is set up to store an overall comparison identifier. wherein the overall comparison identifier identifies a circuit configuration of the system.

The invention also relates to an FPGA (Field Programmable Gate Array) with a system according to one of the aforementioned embodiments.

Detailed description of preferred embodiments

The features and numerous advantages of the method and system for updating firmware in accordance with the present invention are best understood by reference to a detailed description of the accompanying drawings, in which:

1 shows an FPGA implementing the method according to the invention; and

2 illustrated by an example the structure and the components of a firmware file format with hardware identifier.

The invention is illustrated below using the example of an FPGA (Field Programmable Gate Array). Such programmable logic circuits are increasingly being used to control industrial processes as well as domestic electronics. Key application examples include protocol implementations for parts of the Ethernet MAC warehouse, digital video encoding, data encryption, and error correction procedures. Particularly in areas where algorithms or protocols are subject to rapid technical development, the use of FPGAs is advantageous because they can be relatively easily adapted to new developments by updating their firmware, without having to change the hardware.

However, the invention is not limited to FPGAs, but can be applied to all systems comprising at least one programmable device. A system in the sense of the invention can be understood as any set of analog and / or digital components wired according to a predefined circuit diagram. Examples of systems are programmable logic circuits, but also technical systems in which such circuits are used, such as flow meters in a power plant or the braking system of a motor vehicle or even the entire motor vehicle itself.

This in 1 shown FPGA 10 includes a first programmable processor unit 12 and a second programmable processor unit 14 , However, the invention is not so limited and may equally well be used in systems that include only one programmable device or more than two programmable devices.

The first processor unit 12 controls via a first interface 16 a first application process while the second processor unit 14 via a second interface 18 controls a (possibly independent) second application process. For example, over the first interface 16 the FPGA 10 communicate with an Ethernet network via the second interface 18 in contrast, with a fieldbus system. The FPGA shown also includes other components such as a shared RAM RAM 20 , a test element 22 and a non-volatile memory 24 and optionally further (in the representation of 1 not shown) components. The electrical connection between the individual components of the FPGA 10 is in 1 symbolized by double arrows: A double arrow between two components indicates that these two components are connected directly to each other via an electrical connection.

Both the first processor unit 12 as well as the second processor unit 14 are operated with system-specific firmware, in the example shown with firmware for controlling the Ethernet or fieldbus communication. Regularly it will be necessary, the firmware of the first processor unit 12 to upgrade to the FPGA 10 to adapt to changing requirements or further developments of the Ethernet protocol. Also the firmware of the second processor unit 14 must be updated from time to time in practice to accommodate changes in the fieldbus system.

As described in the introduction with reference to the prior art, there is the risk with such firmware updates that intentionally or unintentionally an incompatible firmware is loaded, which impairs the functionality of the processor units and thus of the overall system.

Even if this problem is met by careful documentation or careful examination of the firmware version prior to the update, the result is the same difficulties and dangers arising from the fact that the new firmware for the first programmable processor unit 12 developed and tested, but the interconnection of the first processor unit 12 in the FPGA 10 only insufficiently taken into account, so that the communication with the second processor unit 14 whose firmware is not updated after the upgrade is disturbed. This also allows the FPGA 10 become useless.

The invention addresses these problems in the embodiment shown by a Firmware file format, which includes a system identifier and / or a manufacturer identifier, prior to the update with a corresponding, in the FPGA 10 stored comparison identifier can be compared.

The identifier may, for example, a device identifier for the first processor unit 12 and / or a device identifier for the second processor unit 14 include, which before updating with a corresponding, in the FPGA 10 stored comparison identifier are compared. In this way, it is possible, for example, to prevent that for the first processor unit 12 certain firmware inadvertently on the second processor unit 14 is played, or vice versa.

The identifier may also reflect the circuit configuration of the FPGA 10 including some or all components of the FPGA 10 and their interconnection. By comparison with a corresponding, in the FPGA 10 saved comparison identifier can be sure that the new firmware file not only to the first processor unit 12 or second processor unit 14 adapted, but with the FPGA is overall system compatible. In this way, firmware updates can cause malfunctions in the operation of the FPGA 10 effectively exclude.

Such an identifier can be unique worldwide and from the manufacturer of the FPGA 10 be assigned to. The same or another manufacturer sets the FPGA 10 along with other components in a larger system, this larger system can also be assigned a separate hardware identifier according to the same pattern, which then forms the basis of comparison for system compatibility checking in a firmware update of the enhanced system. In this way, a composite system for the firmware update can be assigned to a composite system, which identifies the circuit configuration of the entire system and stored in the overall system.

One on the FPGA 10 Tailored firmware file format is exemplary and schematic in the representation of 2 shown. The metadata are each represented by thick-bordered boxes. The number and length of the different firmware components and their exact coding are free within wide limits and depend solely on the application and configuration of the target system, such as the FPGA 10 ,

A first block 26 and a second block 28 include the firmware type or a description or version number. In a third block 30 is a hardware identifier coded. It can be the first processor unit 12 and the second processor unit 14 as well as other system components of an FPGA 10 possibly including the circuit configuration. The hardware identifier in block 30 can also use the FPGA 10 overall. The firmware file format may also provide for each programmable component of the system its own firmware, which may be compressed and / or encrypted, for example in block 34 for the first programmable processor unit 12 and in block 36 for the second programmable processor unit 14 , Optionally, the firmware may also include a certificate from the firmware manufacturer, as in block 38 shown.

The identifier in block 30 allows comparison with a corresponding one in the FPGA 10 stored comparison identifier for checking the system compatibility. Preferably, the comparison identifier is part of the so-called factory programming, so that it is protected against unintentional deletion or modification.

In the embodiment shown, the comparison identifier is in an EEPROM 24 saved. One over the first interface 16 or the second interface 18 at the FPGA 10 received new firmware file is first in the test element 22 cached. Subsequently, for the comparison, the comparison identifier from the non-volatile memory 24 in the test element 22 loaded. By comparing the firmware identifier against the comparison identifier, the test element checks 22 the system compatibility of the new firmware file.

The identifier in block 30 may also include a list of several different hardware identifiers that identify different system configurations for which firmware is appropriate. The checking then takes place, for example, by successive comparison of the hardware identifiers with the comparison identifier stored in the system until a match is found.

Alternatively, the test element 22 by successive comparison also check if the firmware identifier in block 30 in a table associated with the comparison identifier or list of identifiers associated with the FPGA 10 include compatible firmware identifiers.

Only when the review in the test element 22 Displays a system-compatible firmware, the new firmware file is accepted and the first processor unit 12 and / or the second processor unit 14 updated with the corresponding new firmware. The previous firmware file will only be deleted in the case of the previous one Accept the new firmware file in the test item 22 ,

Returns the check of the ID in the test element 22 that the new firmware file does not have a known identifier or is not system compatible, the new firmware file will be rejected. In this case, the previous firmware in the first processor unit 12 and / or the second processor unit 14 not replaced by the new firmware file. This effectively prevents the system from being erroneously or intentionally updated with non-system-compatible firmware.

Will when checking the identifier in the test element 22 exceeded a time limit, the test process can be aborted and the new firmware file can be rejected. Alternatively, the FPGA 10 also be set up so that in case of a time override in the test element 22 the first processor unit 12 and / or the second processor unit 14 the factory programming from the non-volatile memory 24 invites.

The successful filing of the new firmware file or the successful loading of the factory programming can be confirmed by a test number, eg. As a magic number to be displayed. The magic number is not written until all other data has been successfully written.

The described method for updating the firmware can take place via an open common programming interface and, depending on the application, be realized, for example, via an HTTP, TCP or FTP format.

LIST OF REFERENCE NUMBERS

10

FPGA

12

first processor unit

14

second processor unit

16

first interface

18

second interface

20

R.A.M.

22

A probe

24

non-volatile memory

26

firmware type

28

Firmware description and / or version number

30

Hardware identifier (s)

32

FPGA Firmware Image

34

Firmware image for first processor unit 12

36

Firmware image for second processor unit 14

38

Certificate Block

QUOTES INCLUDE IN THE DESCRIPTION

This list of the documents listed by the applicant has been generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Cited patent literature

• US 6360362 B1 [0006, 0008]
• US 2009/0064125 A1 [0009]
• US 2009/0247124 A1 [0009]

Claims (11)

Method for updating a firmware of a system ( 10 ), which has at least one programmable component ( 12 . 14 ), comprising the following steps: receiving a new firmware file which contains at least one identifier assigned to a source of the firmware and / or a circuit configuration ( 30 ), on the system ( 10 ); Checking the ID ( 30 ) against at least one in the system ( 10 stored comparison identifier, wherein the checking in the system ( 10 ) he follows; and accept the new firmware file and place the new firmware file in the programmable device ( 12 . 14 ) or rejecting the new firmware file, depending on a result of the check. The method of claim 1, wherein the firmware file comprises a plurality of identifiers, and the checking comprises successively comparing at least a subset of the plurality of identifiers with a comparison identifier stored in the system. Method according to Claim 1 or 2, in which the checking of the identifier ( 30 ) comparing the identifier with a plurality in the system ( 10 ) stored comparison identifiers. Method according to one of the preceding claims, comprising the step of deleting a preceding firmware file from the programmable component ( 12 . 14 ), with deletion only in case of previous acceptance of the new firmware file. Method according to one of the preceding claims, wherein the identifier comprises a manufacturer identifier and / or a revision number. Method according to one of the preceding claims, wherein before checking the identifier ( 30 ) the data format of the new firmware file is checked. A method for assigning a comparison identifier for firmware update to a composite system, comprising the steps of: Connecting at least two individual systems to form an overall system, wherein at least one of the individual systems comprises at least one programmable module and stores at least one comparison identifier, the comparison identifier being associated with a source of firmware and / or featuring a circuit configuration of the individual system; Assigning a total comparison identifier to the overall system; and Save the assigned overall comparison identifier in the overall system. The method of claim 7, wherein the overall comparison identifier identifies the circuit configuration of the overall system. With a firmware updatable system ( 10 ) with: an interface ( 16 . 18 ) for receiving a firmware file; a programmable device ( 12 . 14 ) in which the firmware file can be stored; a memory ( 24 ) arranged to store at least one comparison identifier, the comparison identifier being associated with a source of the firmware and / or a circuit configuration of the system ( 10 ); and a test element ( 22 ), which is set up, the comparison identifier against at least one identifier ( 30 ) to check the firmware file. System ( 10 ) according to claim 9 with at least two programmable components ( 12 . 14 ) and a memory ( 24 ) arranged to store a total comparison identifier, the overall comparison identifier being a circuit configuration of the system ( 10 ). Field Programmable Gate Array ( 10 ) with a system according to one of claims 9 or 10.

Images