WO2015071507A1 - Method and device for efficiently updating data in electronic devices - Google Patents

Abstract

The invention relates to a method and a device for efficiently updating data in electronic devices, solving problems presented by existing techniques in a simple manner. The invention allows the device to be updated rapidly, with low energy consumption, and minimising the number of times the non-volatile memory unit (for example, flash) is erased, at a profitable cost.

Description

 METHOD AND DEVICE FOR EFFICIENT UPDATING OF DATA IN ELECTRONIC DEVICES

D E S C R I P C I O N

TECHNICAL FIELD OF THE INVENTION

The present invention has its field of application in the efficient updating of data in electronic devices and more specifically, in the efficient updating of software in electronic devices, especially in embedded electronic devices (also called embedded electronic devices). Embedded electronic system is called electronic circuits that perform specific tasks in a certain more complex electronic system, such as the electronic control unit (ECU, Electronic Control Unit) of a car.

BACKGROUND OF THE INVENTION

Electronic devices such as mobile phones, PDAs (Personal Digital Assistants), tablets, televisions, routers ... store different types of software (for example, applications or operating system) supplied either by the manufacturers themselves electronic device, telecommunication operators or third parties that, in many cases, must be updated often.

An example of a type of software stored by electronic devices is firmware. The firmware can be defined as a set of machine instructions for specific purposes, recorded in a memory, which establishes the lower level logic that controls the operation (for example, controls electronic circuits) of an electronic device of any type. It is strongly integrated with the electronics of the device. That is, the firmware is the software responsible for controlling and operating the device to correctly execute the external instructions or in other words, it is the software that has direct interaction and controls the hardware.

Traditionally, the firmware is stored in ROM or Flash memory chips. For this reason (stored in Flash / ROM memory chips), software that runs on embedded or embedded systems is often considered firmware. This code includes both the startup code and the operating system. In some applications, the application software is even considered as an element of the system firmware.

The electronic devices consist of electronic data storage units (memory) to store these software instructions and in general any type of data they need. There are numerous types of memories, known from the state of the art. These units must be configured to receive electronic data from an external or internal source, preserve the data for a certain time and supply it when requested.

There are for example, a type of memory units that are volatile (that is, they are erased if there is an interruption in the power supply) such as RAM (from the Random Access Memory, Random Access Memories). These memories are cheap and fast, but they must be continuously powered so as not to lose the information they store. This makes RAM memories expensive to operate and consume a lot of power. Therefore, this type of memory is used for short-term storage, to facilitate the rapid transfer of data that will be used quickly in devices electronic and are modified frequently.

There are other types of memory units that are non-volatile (that is, they keep storing the information even without power supply). An example of this type of non-volatile memory is the so-called flash memory, formed by non-volatile chips for the storage of information that can be electronically erased and programmed. Other examples of non-volatile memory are the ROM and the EEPROM. These memories, unlike RAM, can preserve data for a long time without having to maintain the power supply, but they are more expensive and require, as we will see, a more complex operating interface.

For obvious security reasons, being fundamental to the operation of the device, the firmware is normally stored in non-volatile memory units.

On the other hand, to ensure proper operation of the device, the firmware of a device is usually updated frequently (for example, when there is a new version of it) and this poses problems, since, as we said the operation interface with the Non-volatile memories are complex and are more thought to save data in the long term and not to be updated frequently.

Software modifications to update the version or to correct errors (what is generally known as updating the software) can be a very critical point in the operation of electronic devices. In devices where consumption is an important factor, such as wireless devices, it is important that the update process be efficient. An efficient update will allow us to increase the useful life of the device by reducing its consumption during the update. This is especially important when we talk about fundamental software that is updated frequently as is the firmware. These updates are usually made through communication networks that communicate the electronic device to be updated with the node (server) where the new software is located. This network can be a cable, fiber, wireless network, a mobile telephony network, fiber optic network or any other type of communication network to which the electronic device is connected and which allows it to communicate. Optionally the updates can be loaded directly into the device, for example by means of an external memory unit (such as a USB, a CD or any other) that is inserted into the device.

Currently, there are different strategies when updating the firmware. The simplest way is to fully load all the new firmware. This technique is one of the most used because it allows to update the firmware in a very simple way. However, the power consumption in the transmission and during the update is very high because it is necessary to transmit all the firmware for each update. In addition, as a previous erase of the non-volatile memories (such as flash or EEPROM) is necessary, the life of said memories whose erase cycles are limited is reduced (the manufacturer does not guarantee that the device will work after a certain number of years). deleted).

Because of this, techniques have been developed to reduce the size of the updates. These techniques have an important impact on the energy consumption used during the transmission, and therefore, in the lifespan of these devices, which are usually powered by batteries. Within the technique of reducing the size of the update there are two different methods. The first method consists in the development of the firmware in a modular way, in such a way that it is only necessary to transmit the modules that are required. The second method consists of incremental updates, where only the changes with respect to the old software (the one that is already stored in the device at the time of the update) are transmitted. An example of these techniques can be seen in the document "Efficient code distribution in wireless sensor networks" by N. Reijers and K.Langendoen published in the "WSNA Ό3 Proceedings of the 2nd ACM international conference on Wireless sensor networks and applications", 2003 , where the authors use an update technique based on the differences between the old and the new firmware. Updates are made by building the new firmware from the old one (the one that is currently running on the device) by means of a script (usually known as a "script") with the differences between the updated firmware and the one currently running on the device. device. This script generated with the differences between the code of the new firmware and that of the old one, will be the update that is transmitted through a communications network.

The problem with this type of technique is that the size of the update scripts is not necessarily congruent with the actual extension of the update. This is because a small change in one of the instructions may result in a shift of the positions of the instructions in the memory. This makes it necessary to reorder the code to match the jumps and calls to functions (sets of instructions that allow to carry out a certain action or function in the electronic device), so a large part of the code has to be modified , resulting in a very large script when what is really updated is very little.

This problem attempts to be solved in other documents of the state of the art as in "Remote Incremental Linking for Energy-Efficient Reprogramming of Sensor Networks" of J. Koshy and R. Pandey published in "Proceedings of the Second European Workshop on Wireless Sensor Networks" , 2005, where the authors propose the introduction of a "space of reservation" or "slop space" between the functions of the firmware in a way that allows the function to increase size without changing the positions of the other functions. This allows writing the new function in the same initial position without shifting the positions of the instructions of other functions and, therefore, without the need to update the references to the positions of the functions. This has the disadvantage that in the event that the growth of the function is greater than its "slop space", then the positions of the instructions of other functions are displaced and, therefore, it has to be necessary to update more references that would be necessary at the beginning.

Other update techniques are based on the use of virtual machines (as described for example in "VM *: Synthesizing scalable runtime environments for sensor networks" by J. Koshy and R. Pandey, Proc. 3rd ACM Conf. Embedded Networked Sensor Systems (SENSYSV05), 2005). These techniques propose the use of virtualization technology and present the problem of its complexity. The power consumption during the compilation at run time, the link and the execution process is much higher than if native code were used, so the extra cost in terms of energy use is prohibitive.

There are other techniques based on the use of dynamic linkage, where different modules are dynamically loaded into the device using code independent of the position. For this, the modules send messages and communicate through a table of jumps.

A work on this field is "Zephyr: Efficient incremental reprogramming of sensor nodes using function cali indirections and difference computation" of RK Panta, S. Bagchi, and S. Midkiff, in USENIX Ό9, 2009, where the authors present a combination of the two most effective techniques so far: the use of indirect calls to functions (code independent of the position) and the use of differences between firmwares to generate a linking script. The The main improvement of this technique is that it reduces the size of the update script but its main problem lies in the dependency between functions. In other words, even if the code is independent of the position, this does not mean that within the same code, if a function calls another function that has changed position due to an update, the call address is not recalculated at run time , but you have to modify the call addresses of all the functions that use the new function. Using this technique it is necessary to erase and completely rewrite the flash memory every time there is an update, since this technique does is that from the current firmware (the old one) and the update script generates a new firmware inside of the device and replaces it in the memory, deleting the previous firmware (that is, it does not reuse the parts already recorded in the flash memory that are the same). Due to this it is necessary to completely erase the flash memory to record the updated firmware even when the changes in it are minimal, so that the time spent and, above all, the consumption are greatly affected when updating. This is a serious problem since what is sought in these types of systems is a fast update and with a low consumption. If we add to this the handicap that the useful life of a flash memory is reduced by the number of deletions that are made, it gives us as a result that this type of update is not the most appropriate.

In addition, the writing in flash memory presents some particular aspects that must be taken into account. Before writing to the flash memory, it is necessary to erase the block of memory or bank in which it is going to be written. Erasing a block is a process that requires not only time but also a certain amount of energy. Once a block is deleted, it is only possible to write once in a memory location. If you want to rewrite a memory location, you must delete the entire memory block again and rewrite the block positions that you do not want to modify. The present invention has in account this behavior to reduce rewrites and thereby reduce consumption and communication and operation time.

In summary, as we have seen, in the state of the art there are several solutions for updating the software, ranging from the simplest techniques consisting in updating all the firmware (they are very inefficient in time and consumption), to more technical complex that do not require changing all the firmware, some of which have been described above. All these techniques show different weaknesses such as excessive time or consumption of the update.

Therefore, what is sought is a technique that allows software updates in an electronic device to be reduced in time and consumption and that this update be made through more efficient processing (and therefore with a lower energy consumption) ), with the purpose, among others, of increasing the useful life of the electronic device. And this is the purpose of the present invention.

The technique proposed in the present invention to solve these problems can be used by any device but is especially beneficial in devices without MMU Memory Management Unit, since the devices with Memory Management Unit They can solve part of these problems with other resources. Most processors of embedded systems do not have a Memory Management Unit and therefore the present invention is especially directed to these embedded devices. SUMMARY OF THE INVENTION

The present invention proposes a method and system that solves, in a simple manner, the problems presented by the firmware update in the existing devices. Said solution allows updating the software in a fast way, with low power consumption and that minimizes the number of deletions of the non-volatile memory unit (for example, flash) at an advantageous cost.

In a first aspect, the present invention describes a method for the efficient updating of data in an electronic device connected to a communication network, where the electronic device consists of at least a first non-volatile memory unit and a second non-volatile memory unit. volatile type memory that stores data sets and a processor, where in the first memory unit is stored a first table with at least one entry for each data set with a position field indicating a position in one of the memory units of said data set and a validity field indicating whether said entry is valid or not, where the method comprises the following steps: a) Receive through the communications network, an update data file that includes a new version of at least one of the data sets stored in the memory units b) For each data set that includes a new version in the update file: b1) Store this new version of the data set in free positions of one of the memory units b2) Add to the first table an entry for said data set indicating in the position field, the position of the new version of said data set in the memory unit where the new version of said data set has been stored. indicating in the field of validity that said entry is valid and in the rest of entries of said table for said data set indicate in the validity field that they are not valid c) Based on the information in the first table, update a second table stored in the second memory unit with an entry for each data set, where for each data set, it indicates its valid (ie updated) position in one of the memory units (that is, for each set of data it indicates the position in memory of the most updated version of said data set).

 That is, the new version of a data set can be stored in the first or second memory units and in the entry corresponding to said data set in the second table, the position in the corresponding memory unit is indicated where it is stored. has stored said new version of said data set

The first memory unit can be of the flash type and the second memory unit can be of the RAM type.

In one embodiment, said data sets are part of the firmware of the device.

In one embodiment, the update data file is sent by a server to the electronic device through the communications network. In an embodiment, prior to step a), a comparison of a new version of the data sets with the data sets stored in the device is produced and from said comparison the update data file is obtained.

Said data sets can be data objects that can be functions, variables or any other type of data objects.

Said second field can not only indicate if the entry is valid or not, but in the case of being invalid it can indicate a new position in the table for said data set.

In the first table there may be a field for each entry indicating the version number of the data set to which that entry belongs or a field for each entry indicating the index of the second table it refers to.

Said free positions in which the new version of the data set is stored may be at the end of all the data sets stored in the memory unit where it is to be stored.

The electronic device can be an electronic device can be an embedded electronic device and / or without Memory Management Unit MMU (English Memory Management Unit).

In a second aspect, the present invention describes an electronic device for the efficient updating of data, where said electronic device is connected to a communications network and comprises:

At least one first memory unit of non-volatile type and a second unit of volatile type memory that store data sets;

wherein the first memory unit also stores a first table with at least one entry for each data set with a position field indicating a position of said data set in the memory units (in the first or in the second) and a validity field that indicates if said entry is valid or not;

where the second memory unit stores a second table with an entry for each data set that indicates for each data set, the valid position in the memory units (in the first or the second) of said data set

 A receiver for receiving via the communications network, an update data file that includes a new version of at least one of the data sets stored in the memory units and

a processor connected to the receiver and to the at least first and second memory units.

In one embodiment, the processor contains means to analyze the update file and, for each data set from which a new version is included in the update file, store the new version of said data set in free positions of one of the units of memory, add to the first table an entry for said data set indicating in the position field the position in the memory unit where said new version has been stored and indicate in the validity field that said entry is valid and in the Other entries of said table for said data set indicate in the validity field that said entry is not valid and, based on the information in the first table, update the second table stored in the second memory unit in a manner that in the entry corresponding to each data set from which a new version is included in the update file, the position in the unit is indicated of memory where it has stored said new version

Said electronic device can be a mobile phone, a tablet, a PDAs (of English, Personal Digital Assistants, Personal Digital Assistant), MP-3 player, a digital camera, an intelligent television, wireless network node or similar device.

In a third aspect, the present invention describes a computer program product comprising computer executable instructions for performing any of the methods described above when the program is executed on a computer.

In a fourth aspect, the present invention discloses a digital data storage medium that encodes a program of instructions executable by machine, to perform any of the methods described above.

For a more complete understanding of the invention, its objects and advantages, reference may be made to the following specification and the accompanying drawings.

DESCRIPTION OF THE DRAWINGS

To complement the description that is being made and in order to help a better understanding of the characteristics of the invention, according to preferred examples of practical embodiments thereof, an assembly of drawings is included as an integral part of this description. where, with illustrative and non-limiting character, the following has been represented: Figure 1 shows schematically part of the update process according to an embodiment of the present invention.

Figure 2 shows schematically the process of accessing a function through an address table.

Figure 3 schematically shows the address tables that are part of the update process according to an embodiment of the present invention.

Figure 4 shows schematically part of the update process in an address table according to an embodiment of the present invention.

Figure 5 schematically shows the address tables that are part of the update process according to an embodiment of the present invention.

Figure 6 shows a block diagram where the update process according to an embodiment of the present invention is described.

DETAILED DESCRIPTION OF THE INVENTION

The term "electronic device" is used in the present text to refer to any type of mobile or fixed electronic device, such as a mobile phone, a tablet, a PDA (of English, Personal Digital Assistants, personal digital assistants), MP-player. 3, digital cameras or smart televisions among others. The present invention is not limited to the devices named above since the embodiments of the present invention They can be used in a wide variety of electronic devices.

The electronic devices can be adapted to access nodes (for example servers) through a communication network (mobile or fixed) to obtain update information to change the software stored in their memory units.

The update information may comprise information that modifies, changes or corrects the firmware of the device or any other software component stored in the electronic device. In one embodiment this update information can be an executable set of instructions that can be used to add new services to the electronic device (at the request of the user, the service provider or the device manufacturer) and / or to improve or correct errors in some existing function of the electronic device.

The present invention proposes a method and device for safely, rapidly updating software (eg firmware) in an electronic device.

In an embodiment of the present invention, said electronic device includes at least one processor or CPU (from the English Computer Processing Unit), at least one first memory unit (or a group of first memory units) and a second memory unit ( or a group of second memory units). The electronic device may also consist of a communications interface that allows you to access a communications network to send and receive information.

In one embodiment, the first memory units are of the nonvolatile type (e.g., a flash memory) and the second are of the volatile type (e.g., a RAM).

These memory units can be connected via a communication bus with the rest of the units of the device.

In one embodiment, the firmware to be updated is stored in one or more of the first memory units (flash type memory). In alternative embodiments, the firmware to be updated may be stored in one or more of the second memory units or part in one or more of the first memory units and part in one or more of the second memory units. According to the present invention, the position of each firmware element in the memory units must be known, so each firmware function must be carefully placed in a known memory location (or from the default positions) in order to be able to generate an address table that identifies the location in the memory of each function. For this, for example, you can separate each object (functions, data ...) during the linking of the firmware in a separate section for each object. This will help to identify each object more easily.

One of the characteristics on which the invention is based is in the rewriting of the functions updated in the free spaces of the non-volatile memory (flash memory). Thanks to this, we avoid the problems of code displacement and will only change the position of the updated functions while the non-updated functions will remain in the same memory position they had before the update.

An example of this process can be seen in Figure 1, where a map of the original memory is shown on the left (before the update) and on the right a map of the memory after the update. In the illustrated case in Figure 1, the function to be updated is function 1. This updated function 1 may have been received by the electronic device of a server through the communication network (for example, a mobile telephone network) to the one that the electronic device is connected to.

This updated function 1 is copied at the beginning of the free space (which may be, for example, at the end of the current firmware). Thanks to this, as can be seen in the memory on the right of figure 1, no address of the other functions (the non-updated ones) is altered, since the displacement problem does not affect them.

This new function will be copied by the device in the address that is told (for example the user can decide) by updating. The update sent to the device contains information about the address where each part of the new code should be copied. This process of copying is done by the device itself (the processor) in the space that the user indicated when generating the update.

To write this new function it will not be necessary to delete the previous function and the calls of other functions to said updated function can be done without errors, since the access will be done through a table of addresses. The technique of the address table allows correct addressing to a function independently of the actual position of the instructions (code) that constitute that function in the memory). An example of this access by address table is shown in Figure 2.

This figure shows an example in which function 1 needs to jump (also known as "call", in English "cali") to function 3 (that is, one of the actions of function 1 is to carry out the function 3 or in other words, one of the instructions of function 1 is to perform the instructions of function 3). This jump or call is made through this intermediate address table. As seen in Figure 3, in this table is stored for each function stored in memory, the position of that function (also called the address) in memory. Then, the function that wants to call another function (in the case of the figure, function 1), instead of indicating the actual position in the memory (the address) of the function it is calling (in this case the function 3) what it does is indicate the position of the table corresponding to said function. When executing function 1, instead of going directly to the position of function 3, it will go to the position of the table indicated by function 1, the address of function 3 will be obtained and a jump will be made to this address ( that of function 3), as shown in figure 2.

Therefore, before an update in the manner proposed above, it will not be necessary to change the addresses of the functions that call the updated function, but only to modify the entry of the table so that they point to the new address is sufficient.

When a function is updated and, therefore, as shown in Figure 1, the memory position of a function changes, the entry in the table for that function would have to be changed and the new address of said function should be set. But if the process were done this way, we would arrive at the same problem described above: that an update of a function would suppose to delete and rewrite the table in flash again.

To avoid this deletion, what is proposed is not to update the same entry in the table, but it is invalidated and a new entry is added just as it is done when a function is updated (as shown in figure 1) . For this to be done more easily and effectively, a second table will be used in a second RAM-type memory unit, which has an access reading and writing much faster (that is, the memory access time is much shorter in RAM) and therefore a lower consumption, besides that it can be erased and rewritten as many times as desired without significantly affecting the useful life of memory.

To do this, when starting the firmware load (when the device is booted, restarted or updated) the table will be copied into the RAM, processing it to eliminate the old entries and leaving only the valid entries, since when the device is turned off the RAM is deleted, so it is necessary to re-copy the table to RAM. In addition, each time a new update is made, the new entries in the RAM memory must be renewed in order for the updated firmware to start functioning.

Figure 3 shows an example of the proposed process. As you can see after entering the update, an address table is kept in the first memory unit (flash memory). In the example of the figure, the update has consisted of the introduction of a new function 2, this update has caused its position in the flash memory to change (from being in Direction 2 to being in Direction 4) and therefore , the table where your address appears in the memory must be modified. What is done is to remove the old reference of this function from the address table and the subsequent inclusion of a new entry at the end of the table with the new reference. Thanks to this, it has only been necessary to add new information in the flash memory without needing to erase it. Once this has been done, the update is complete and the only thing missing is that this new table is passed to the second memory unit (RAM) with a process that removes the old entries (in this case, the function) 2) and write only the updated addresses without changing the position of each function in this second table. With this process, in this second table, the address of each function will be correct even after an update of the function and its position within the table will not change, so calls to a function will always point to that position in the table and you will not need to change these calls even if the function is updated and therefore change the location of the function in the flash memory.

Of course, calls to a function will not be made through the first table (the one in the flash memory) but to this second table stored in RAM.

In an embodiment, in order to perform the update, an update file (script) will be generated that will be obtained from the difference between the new firmware that is to be installed in the electronic device and the firmware that is stored at that moment in the device. This update file can be generated by the same server in which the new firmware is stored or in another node of the communications network.

This update file generated with the differences between the code of the new firmware and that of the old one, will be the update that is transmitted through the communications network.

In order for the update file to be generated with the smallest possible size and for the position of each firmware element in memory to be easily and without error known, the parts of the firmware code must be ordered correctly.

For a correct ordering of firmware objects, one option is to separate the objects (functions, variables ...) during the linking of the firmware in a different section each. In one embodiment these sections would be Operating System, drivers and applications. This separation is a proposal of example that facilitates the correct understanding of the technique that is going to be described next, but the Separation can be done in other ways that the firmware designer sees fit and that are known in the state of the art. One could even not separate the parts, since it is not necessary for the correct operation of the present invention.

In one embodiment, a free space will be introduced between each section of the firmware stored in the memory of the device. The larger the free size of the flash memory, the better as you will have more space to update the functions without having to erase and rewrite the flash memory.

The address table can be more complex than described in the examples presented so far. In an embodiment, this first address table (the one stored in the flash memory) will have at least three fields, for each object (for example a function) the first one will indicate the position of the object in memory (the address of the object in the memory), the second will indicate if the entry in the table is valid or has been updated and the third party will keep the index in the second table (the table stored in the RAM) to which it refers (to avoid losing references during the update, since the position in the RAM table should not be altered since it helps to be more efficient when doing a direct search (positional access) in the RAM table of the address.

For the second field for example, you can choose a value so that if it has that value (in Figure 4 FFF..FF), the entry will be valid and if it has another value it will be an indication that the entry is not valid . Optionally this second field will not only indicate if the entry is valid or not, but in the case of being invalid it will indicate the new position in the table for said function (see figure 4).

In case the table is updated with a new reference, it is will add in the last position of the table, and the previous entry to the table will be indicated as invalid by marking the new position of the reference in the table. This can be seen in Figure 4, where on the left the table can be seen before the update and on the right, the table can be seen after having updated function 2. Having updated function 2, its address will change so that its initial entry has been set to invalid (placing a new position in the second current position field and a new entry is created in the table (in position X + 1) with the new address.

This addition of a new entry to the table does not imply the erasure of flash memory since it writes about "clean" positions all the time. Until now this table is stored in Flash, so that the changes are persistent, but now it would enter the process of passing this table to the second memory unit (RAM), for which a process will be responsible for reading the table and eliminate invalid entries, leaving only valid entries in RAM. These actions are performed by the device's processor when an update arrives.

This reduces the size of RAM used (by only storing valid entries). Figure 5 shows the table saved in the flash memory after the update (on the left) and the table stored in the RAM memory. You can see how the table stored in RAM is minimal, since it will only contain the memory addresses where each function is located, since the identifier of each function can even be its position in the table. (In one embodiment, each function has a unique numeric identifier which is its position in the RAM table).

In addition to these specified fields, it is optional to add a firmware version field that allows to delay firmware versions without having to update nothing or help recover the system of failed updates. For this a process similar to the one used would be followed, adding a new field in the Flash memory table indicating in which version that entry was added, and in case it is necessary to make an outdated, the process of copying the Flash memory table RAM will be responsible for omitting entries higher than that version and keeping the old ones.

In summary, thanks to the proposed invention, for each update it will only be necessary to send the new updated function (or functions), adding it in an empty space of the first memory (flash), for example at the end, add the new address in the entry of the table in the first memory and update the table in the second RAM from this first table (eliminating the invalid entries and remaining in RAM only the valid entries).

A complete diagram of an embodiment of the present invention all this technique is shown in Figure 6, from the comparison of the two firmwares to the execution of the updated firmware.

The first step shown is the comparison (603) of the two firmwares (the current 601 and the new 602) to identify the objects (for example, functions or variables) that are modified with the new firmware and generate an update with these new objects Once said update is identified, it is sent to the electronic device (for example, by means of a communication network) (604). The new firmware can be supplied by the manufacturers of the electronic device, telecommunication operators or third parties and the node that compares these firmwares, generates the update file and sends it to the electronic device, it can be a server belonging to the supplier of the firmware or a server external to the firmware provider. The device stores these new objects in the holes that are not written in the flash memory (605) and adds the new address in the memory (or addresses if several objects are updated) of the object, creating a new entry in the table of the flash memory (606). Once this is done we can say that the system would be updated. It would only be possible to pass the address table to the RAM by deleting the old (invalid) entries 607 in order to execute the code (608) without errors in the addresses.

With the data update technique described in the present invention, the updates are achieved in a simple, fast and efficient way, with low power consumption and minimizing the number of deletions of the non-volatile memory unit, so that , for all these characteristics, the useful life of the electronic device is increased.

Although many of the disclosed embodiments of the present invention relate to updating the firmware, the application of the present invention is not limited to updating the firmware but can be applied to the updating of any data stored in the electronic device.

Although many of the disclosed embodiments of the present invention relate to flash type memories and RAM, the application of the present invention is not limited to this type of memories but can be applied to a wide variety of memory types.

Some preferred embodiments of the invention are described in the following claims.

In this text, the word "comprises" and its variants (such as "understanding", etc.) must not be interpreted in an exclusive manner, that is, they do not exclude the possibility that what is described includes other elements, steps, etc. Having sufficiently described the nature of the invention, as well as the manner in which it is carried out in practice, it is necessary to state the possibility that its different parts may be manufactured in a variety of materials, sizes and shapes, and it may also be introduced in its constitution or procedure, those variations that the practice advises, as long as they do not alter the fundamental principle of the present invention.

The description and the drawings simply illustrate the principles of the invention. Therefore, it should be appreciated that those skilled in the art will be able to devise various provisions which, although not explicitly described or shown in this document, represent the principles of the invention and are included within its scope. In addition, all the examples described in this document are provided primarily for pedagogical reasons to help the reader understand the principles of the invention and the concepts contributed by the inventor (s) to improve the technique, and should be considered as non-limiting. with respect to such examples and conditions described specifically. In addition, everything set forth in this document related to the principles, aspects and embodiments of the invention, as well as the specific examples thereof, encompass equivalences thereof.

Although the present invention has been described with reference to specific embodiments, those skilled in the art should understand that the foregoing and various other changes, omissions and additions in the form and detail thereof may be made without departing from the spirit and scope of the invention. the invention as defined by the following claims.

Claims

one . Method for efficiently updating data in an electronic device connected to a communication network, where the electronic device consists of at least one first non-volatile memory unit and a second volatile-type memory unit and a processor, where data sets are stored in the memory units, where in the first memory unit a first table with at least one entry is stored for each data set with a position field indicating a position in one of the units of data. memory of said data set and a validity field indicating whether said entry is valid or not, where the method comprises the following steps: a) Receive through the communications network, an update data file that includes a new version of at least one of the data sets stored in the memory units b) For each data set from which a new version is included tion in the update file: b1) Store this new version of the data set in free positions of one of the memory units b2) Add to the first table an entry for said data set indicating in the position field the position in the memory unit where the new version of said data set has been stored and indicating in the validity field that said entry is valid and in the rest of entries of said table for said data set indicate in the validity field that no They are valid c) Based on the information in the first table, update a second table stored in the second memory unit with an entry for each data set, where for each data set, it indicates its valid position in one of the units of data. memory. Method according to any one of the preceding claims wherein the first memory unit is of the flash type and the second memory unit is of the RAM type. Method according to any of the preceding claims wherein said data sets form part of the firmware of the device. Method according to any of the preceding claims wherein the update data file is sent by a server to the electronic device through the communication network. Method according to any of the previous claims, where previously to step a), a comparison of a new version of the data sets with the data sets stored in the device is produced and from said comparison the update data file is obtained . Method according to any one of the preceding claims wherein said data sets are data objects that can be functions, variables or any other type of data objects. Method according to any of the preceding claims wherein said second field not only indicates whether the entry is valid or not, but that in the case of being invalid it will indicate a new position in the table for said set of data. Method according to any of the preceding claims wherein in the first table there is a field for each entry indicating the version number of the data set to which said entry belongs. 9. Method according to any of the preceding claims wherein in the first table there is a field for each entry indicating the index of the second table to which it refers. Method according to any of the preceding claims wherein the electronic device is an electronic device without Memory Management Unit (MMU). 11. Electronic device for the efficient update of data, where said electronic device is connected to a communications network and comprises: - at least a first non-volatile type memory unit and a second volatile type memory unit that stores data sets, where the at least one first non-volatile memory unit stores a first table with at least one entry for each data set with a position field indicating a position of said data set in one of the memory units and a validity field indicating whether said entry is valid or not; and the at least one second volatile-type memory unit stores a second table with an entry for each data set indicating for each data set, the valid position in one of the memory units of said data set; - a receiver for receiving via the communications network, an update data file that includes a new version of at least one of the data sets stored in the memory units; Y - a processor connected to the receiver and to the at least first and second memory units. The electronic device according to claim 11, wherein the processor contains means for analyzing the update file and, for each data set from which a new version is included in the update file, storing the new version of the said data set in free positions of one of the memory units, add to the first table an entry for said at least one data set indicating in the position field the position in the memory unit where said new version has been stored and indicate in the field of validity that said entry is valid and in the rest of entries of said table for said data set indicate in the validity field that said entry is not valid and, based on the information in the first table, update the second table stored in the second memory unit so that in the entry corresponding to each data set of which a new version is included in the fich update, the position in the memory unit where the new version has been stored is indicated. 13. Electronic device according to any of the preceding claims 11 or 12 wherein said electronic device is a mobile phone, a tablet, a PDAs (of English, Personal Digital Assistants, Personal Digital Assistant), MP-3 player, digital camera, an intelligent television, wireless network node or similar device. 14. A computer program product comprising executable computer instructions for performing the method according to any of claims 1 to 10, when the program is executed on a computer. 15. A digital data storage medium that encodes a program of instructions executable by machine, to perform a method according to any of claims 1 to 10.