Method for managing the extended standby mode of an embedded system

Abstract

Method for managing the hibernation of an embedded system. This description relates to a method for managing the hibernation of an embedded system (100), comprising the steps of: - determining an electrical load value used, during a hibernation of the system, for saving software context data in a non-volatile memory (116) of the system; - determining a current value used, during a hibernation of the system, for saving in a volatile memory (114) of the system; - determining, from the previously determined values, a threshold value defining a duration beyond which the electrical consumption generated by the saving in the non-volatile memory is less than that in the volatile memory; - saving the software context data in the non-volatile or volatile memory depending on the planned duration of the system's hibernation.Figure for the summary: Fig. 3.

Description

Title of the invention: Method for managing the prolonged standby of an embedded system Technical field

[0001] The present description generally relates to the prolonged standby of an embedded system. Prior art

[0002] An embedded system is an autonomous computer and electronic system intended to perform one or more specific tasks within a device, such as for example a vehicle, a connected object, into which it is integrated.

[0003] For many embedded systems, minimizing its power consumption is an important point to manage.

[0004] When the embedded system is active, all the system memories are available, electrically powered and synchronized by clock signals. The system software executes normally and its execution context, that is to say all the data used by the tasks executed by the software (such as for example the data present in the stacks, in the registers or the timing data), are continuously updated.

[0005] In order to reduce the power consumption of the system, the latter can be put into deep sleep mode. In this mode, most of the system's components are no longer powered, in particular the system's core(s). Only a few elements remain powered, such as the real-time clock and the wake-up block. The duration of this deep sleep mode is variable, for example between 10 seconds and 213 days with multiple possible values ​​such as 1 hour, 2 hours, 1 day, etc., in the case of an embedded system communicating according to a NB-IoT (Narrowband Internet of Things) type protocol.

[0006] Prior to the power cut that prolonged standby implies, certain data stored in the system, called “software context”, such as for example the data present in the stacks, in the registers or the timing data, must be saved so that they can be restored when the system comes out of this prolonged standby and allow the execution of the system tasks to resume at the point where they were interrupted when the system was put into standby. in hibernation.

[0007] A first possibility is to save this software context data in the system's random access memory (RAM). During prolonged standby, because the system's RAM is volatile, it remains weakly powered by a dedicated regulator so that the data remains statically stored in the RAM. This current required to maintain the data is sensitive to the temperature at which the RAM is located.

[0008] A second possibility is to save this software context data in the system's Flash memory. To perform this backup, the Flash memory must first undergo a step of erasing the data stored in it. Erasing data stored in Flash memory and writing software context data to it requires significant power consumption and time to complete. In addition, Flash memory has a limited number of write / erase cycles before its reliability is impaired. Finally, managing data locations within Flash memory requires a file system, which can be complex to manage. Summary of the invention

[0009] There is a need to propose a solution to address the problems encountered with existing solutions.

[0010] A particular embodiment addresses at least some of these problems and proposes a method for managing the prolonged standby of an embedded system, comprising at least the steps of:

[0011] - determination of an electrical charge value ConsoNon_Voia intended to be used, during a prolonged sleep of the embedded system, for a potential saving of software context data in a non-volatile memory of the embedded system;

[0012] - determination of a value of a current CourantSauv_Voia intended to be used, when of a prolonged standby of the embedded system, for a potential saving of software context data in a volatile memory of the embedded system, at a first temperature;

[0013] - determination, from the values ​​of electrical load ConsoNonVoia and current CourantSauv_Vola previously determined, of a threshold value SeuilConso defining a duration beyond which an electrical consumption intended to be generated by the potential saving of software context data in the non-volatile memory is lower than that intended to be generated by the potential saving of software context data in the volatile memory;

[0014] - saving software context data in non-volatile memory when an expected hibernation duration of the embedded system is greater than the previously determined ThresholdConso threshold value, or in volatile memory when the expected hibernation duration is less than or equal to the previously determined ThresholdConso threshold value.

[0015] According to a particular embodiment, the electrical charge value ConsoNon_Vola intended to be used for the potential saving of software context data in the non-volatile memory is expressed in Coulomb and determined by the equation:

[0016] [Math.l] Cons0^pa_yOia — [ Courant(,1a, x dprni, _Yaia) + ( CourantEff_^ian_vata x Oe / + (Coiiratltcopiejyan_voia x dcapie_.N0n_Vvd)

[0017] with CourantPmg_Non_Voia: value of the current used for programming the non-volatile memory, in amperes;

[0018] dProg_Non Voia: duration of non-volatile memory programming, in seconds;

[0019] CourantEff_Non_voia- value of the current used to erase a part of the non-volatile memory, in amperes;

[0020] dEff_Non_voia: duration of erasure of a part of the non-volatile memory, in seconds;

[0021] CurrentCopy_Non_voia - value of the current used for copying software context data into non-volatile memory, in amperes;

[0022] dCopie_Non_voia: duration of copying software context data into non-volatile memory, in seconds.

[0023] According to a particular embodiment, the threshold value SeuilConso is determined by the equation:

[0024] [Math.2] ç 'ï __ ('mirant yv ; in.tr u / u Sanv yoia

[0025] According to a particular embodiment, the saving of the software context data in the non-volatile memory is further conditioned on the fact that the expected prolonged standby duration is less than or equal to a minimum prolonged standby duration dMin guaranteeing a desired lifespan of the non-volatile memory and expressed by the equation:

[0026] [Math.3] . _ < / y',cx365x24x3600xra / / / fic„„(eJ.ff, Min N^xJ'yde.^T'aiiTJ Memory

[0027] with dVie: desired lifetime of the non-volatile memory, in years;

[0028] Context size: size of software context data;

[0029] NMax_cydeS ■ theoretical maximum number of write / erase cycles of non-volatile memory before its degradation;

[0030] Free Memory Size: Free memory size in non-volatile memory.

[0031] In a particular embodiment, the saving of the software context data in the non-volatile memory is further conditioned on the fact that the value of a parameter NCycies_vie defined by the equation:

[0032] [Math.4] X rxf T^tlleCotilt'Op N Cycles Life — N Cycles Counter Size^ 7"

[0033] is less than the theoretical maximum number of write / erase cycles of the non-volatile memory before its degradation,

[0034] with Ncyciesjcompteur ■ number of write / erase cycles already performed by the non-volatile memory;

[0035] Context size: size of software context data;

[0036] FreeMemorySize: Free memory size in non-volatile memory.

[0037] According to a particular embodiment, the saving of the software context data in the non-volatile memory comprises the implementation of the following steps:

[0038] - programming a DNon_Voia flag indicating that saving data from software context is carried out in non-volatile memory;

[0039] - determining a start address for writing in the non-volatile memory;

[0040] - writing software context data into non-volatile memory, from the previously determined write start address;

[0041] - subtraction of the expected duration of prolonged standby of the embedded system, of a duration of implementation of the previous step of writing the software context data into the non-volatile memory;

[0042] - stopping the power supply to the volatile memory.

[0043] According to a particular embodiment, the method further comprises an exit from prolonged standby of the embedded system including at least the implementation of the following steps:

[0044] - reading the value of the DNon_Vota flag;

[0045] - if the value of the DNon_Vota flag indicates that saving the context data software has been performed in volatile memory, the embedded system is put directly into the active state, or

[0046] - if the value of the DNon_Vota flag indicates that saving the context data software has been performed in non-volatile memory, the software context data is read from the non-volatile memory from the write start address and written to the volatile memory, and then blocks of the non-volatile memory in which the software context data has been saved are erased.

[0047] According to a particular embodiment, the exit from prolonged standby of the embedded system further comprises, before or after the step of reading the value of the flag, a step of resuming the power supply to the volatile memory.

[0048] According to a particular embodiment, the exit from hibernation of the embedded system further comprises, before the step of reading the value of the flag DNon_voia, a step of determining a cause of the exit from hibernation of the embedded system, then:

[0049] - if the exit from standby is due to a reset of the on-board system, a initial boot of the embedded system, a software update via FOTA, or a monitoring event, the embedded system is put directly into the active state without reading the flag value, or

[0050] - if the exit from sleep is not due to a system reset embedded, an initial boot of the embedded system, a software update via FOTA, or a monitoring event, reading the flag value is implemented.

[0051] According to a particular embodiment, an on-board system is proposed comprising means for implementing the above method.

[0052] According to a particular embodiment, the non-volatile memory is a Flash memory, and the volatile memory is a RAM.

[0053] According to a particular embodiment, a computer program product is proposed comprising instructions which, when the program is executed by an embedded system, cause the latter to implement the above method.

[0054] According to a particular embodiment, a computer-readable medium is provided comprising instructions which, when executed by an embedded system, cause the latter to implement the above method. Brief description of the drawings

[0055] These characteristics and advantages, as well as others, will be explained in detail in the following description of particular embodiments given without limitation in relation to the attached figures among which:

[0056] - [Fig. 1] schematically represents an example of the embodiment of a system embedded in which a system extended standby management method is implemented;

[0057] - [Fig.2] schematically represents examples of current consumption of volatile memory and non-volatile memory during a switch between an active mode and a deep sleep mode in which one of these memories is used for saving software context data;

[0058] - [Fig.3] schematically represents the steps of an example of a method of management of hibernation of an embedded system;

[0059] - [Fig.4] represents, for different temperatures, the value of a current intended for be used, during a hibernation of an embedded system, for a potential backup of software context data in a volatile memory of the embedded system;

[0060] - [Fig.5] represents, for different temperatures, threshold values ​​defining a duration beyond which an electrical consumption intended to be generated by a potential saving of software context data in the non-volatile memory of the system is lower than that intended to be generated by the potential saving of software context data in the volatile memory of the embedded system. Description of the embodiments

[0061] The same elements have been designated by the same references in the different figures. In particular, the structural and / or functional elements common to the different embodiments may have the same references and may have identical structural, dimensional and material properties.

[0062] For the sake of clarity, only the steps and elements useful for understanding the embodiments described have been represented and are detailed. In particular, the coding necessary for implementing the different steps of the method for managing the hibernation of the embedded system is not detailed. Those skilled in the art will be able to carry out the different functions of the method in detail from the functional description given here.

[0063] Unless otherwise specified, when referring to two elements connected to each other, this means directly connected without intermediate elements other than conductors, and when referring to two elements connected (in English "coupled") to each other, this means that these two elements can be connected or be connected by means of one or more other elements.

[0064] Unless otherwise specified, the expressions "about", "approximately", "substantially", and "of the order of" mean to within 10%, preferably to within 5%.

[0065] An exemplary embodiment of an embedded system 100 implementing a hibernation management method described later is shown in [Fig.l]. In [Fig.l], only some of the elements of the system 100 are shown and described below.

[0066] In the exemplary embodiment described here, the embedded system 100 communicates according to a NB-IoT type protocol and is for example intended to be integrated into loT type devices for which the management of electrical consumption is important.

[0067] The system 100 according to this exemplary embodiment comprises a first core 102, or central circuit, managing in particular the security functions and controlling the others elements of system 100.

[0068] The system 100 according to this exemplary embodiment also comprises a second core 104, or central circuit, carrying out the various functions, or applications or tasks, performed by the system 100. The second core 104 manages, for example, the IP, MQTT, TLS protocols, etc. The second core 104 can also manage simple functions such as measurements.

[0069] The system 100 according to this exemplary embodiment also comprises a third core 106, or central circuit, managing and carrying out the communications of the system 100 with the external environment. The third core 106 is coupled to one or more memories which, in this example, correspond to a first volatile memory 108 (for example a random access memory) and a first non-volatile memory 110 (for example a Flash memory), and also to the first core 102.

[0070] The system 100 according to this exemplary embodiment also comprises a power supply management unit 112 controlled by the first core 102 and also coupled to an RTC (“Real-Time Clock” in English, or real-time clock) block 113.

[0071] The system 100 according to this exemplary embodiment also comprises a second volatile memory 114, for example a so-called retention RAM (also called RETRAM), and a second non-volatile memory 116 (for example a Flash memory) coupled to the first and second cores 102, 104.

[0072] Alternatively, the architecture of the system 100 may be different from that described above and shown in [Fig. 1], and may include additional circuits or elements or may not include some of the elements or circuits previously described.

[0073] Furthermore, the elements of the system 100 may be different from those described above. For example, the first RAM 108 and / or the second RAM 114 may correspond to another type of volatile memory. According to another example, the first Flash memory 110 and / or the second Flash memory 116 may correspond to another type of non-volatile memory, for example of the EEPROM type (“Electrically-Erasable Programmable Read-Only Memory”).

[0074] [Fig. 2] schematically represents the electrical consumption of a volatile memory and a non-volatile memory of an embedded system during different successive phases (active mode and prolonged standby mode). In this schematic figure, the durations of the different phases and the amplitudes of the currents used during these different phases are not represented to scale relative to each other.

[0075] Diagram a) of [Fig.2] represents the evolution over time of the intensity of an electric current used by the second volatile memory 114 of the system 100 at during different phases of use of the system 100. References 10 designate the current used by the second volatile memory 114 when the system 100 is in active mode (two distinct active mode phases are shown in [Fig.2]), and reference 20 designates the current used when the system 100 is in hibernation (between the two active mode phases) with a backup of the software context data in the second volatile memory 114.

[0076] Diagram b) of [Fig.2] represents the evolution over time of the intensity of an electric current used by the second non-volatile memory 116 of the system 100 during different phases of use of the system 100. As in diagram a), the references 10 designate the current used by the second non-volatile memory 116 when the system 100 is in active mode. The references 30 designate the current used by the second non-volatile memory 116 during an erasure of a part of its blocks, such an erasure being implemented during a transition from prolonged standby to an active mode of the system 100. The references 40 designate the current used by the second non-volatile memory 116 during the writing of the software context data therein before the definitive entry of the system 100 into prolonged standby.

[0077] Thus, diagrams a) and b) of [Fig. 2] illustrate the fact that when the software context data are saved in the second volatile memory 114, the energy consumption linked to this backup corresponds to the current consumed by the memory during prolonged standby (designated by the reference 20 in diagram a) of [Fig. 2]), while when the software context data are saved in the second non-volatile memory 116, the energy consumption linked to this backup corresponds to the current consumed by the memory during the erase and write operations implemented therein just before prolonged standby and at the end of the latter (corresponding to the consumptions designated by the references 30 and 40 in diagram b) of [Fig. 2]).

[0078] [Fig. 3] represents the steps of an example of a method for managing the hibernation of the system 100, carrying out the saving of the software context data of the system 100 in the second volatile memory 114 or in the second non-volatile memory 116 depending on the electrical consumption involved in saving the data in each of them.

[0079] In this example, the method begins while the system 100 is in active mode and an exit from this active mode is initiated (step 200).

[0080] During a following step 202, an electrical charge value ConsoNon_Voia intended to be used, during a prolonged standby of the system 100, for a potential saving of the software context data in a non-volatile memory of the system 100 which corresponds, considering the example of the system 100 previously described in connection with [Fig.l], to the second non-volatile memory 116 of the system 100, is determined. completed. In a particular embodiment, this value of electric charge ConsoNonVoia, expressed in Coulomb, is determined by the equation:

[0081] [Math.5] ConSON,„— ( C HW Cllltpr<>ÿ_Nov_Vola X dProg_^pn_V <rla) ( ^^^'^^Eff_N<n_Vpla X f_Non_Vola) Vvia X dcapiaùpmVolà)

[0082] The parameter CourantProgNonVoia corresponds to the value of the current used for programming the non-volatile memory 116, in amperes.

[0083] The dProg_Non_Vola parameter corresponds to the duration of the programming of the non-volatile memory 116, in seconds.

[0084] The parameter CourantEff_Non Voia corresponds to the value of the current used to erase a part of the non-volatile memory 116, in amperes.

[0085] The parameter dEff_Non Voia corresponds to the duration of the erasure of a part of the non-volatile memory 116, in seconds.

[0086] The parameter CourantCoPie_Non_voia corresponds to the value of the current used for copying the software context data into the non-volatile memory 116, in amperes.

[0087] The parameter dCoPie_Non_voia corresponds to the duration of the copy of the software context data in the non-volatile memory 116, in seconds.

[0088] Thus, the electrical charge value ConsoNon_Voia corresponds to the sum of the electrical charges intended to be used by the non-volatile memory 116 during programming, erasing and writing operations. For example, this value of the electrical charge ConsoNonVoia can be between 630.8 pC (minimum value obtained by considering the minimum durations of programming, erasing and copying of the data in the non-volatile memory 116) and 1261.6 pC (maximum value obtained by considering the maximum durations of programming, erasing and copying of the data in the non-volatile memory 116), and it is possible to choose, for the value of the electrical charge ConsoNonVoia, an average value between these minimum and maximum values. This electrical charge value ConsoNon_Vola can be determined on the basis of measurements which are not repeated at each exit from the active mode of the embedded system 100.

[0089] After step 202 described above, a value of a current called CourantSauv_Vola and intended to be used, during a prolonged standby of the system 100, for a potential saving of software context data in a volatile memory of the system 100, is determined, for a first temperature (step 204). This volatile memory of the system 100 corresponds, considering the example of the system 100 previously described in connection with [Fig.l], to the second volatile memory 114 of the system 100. This current value CourantSauv_Voia can be determined using a curve or pre-established measurement points of this current for different temperature values, as shown in [Fig.4]. As an example, for a first temperature equal to 25 °C, the value of the current CourantSauv_Voia can be equal to 0.7 pA (this value including, in this example, the current consumed by the voltage regulator allowing the power supply of the volatile memory during the prolonged standby of the embedded system as well as the current leaks observed during this prolonged standby).

[0090] During a following step 206, from the previously determined values ​​of electrical load ConsoNonVoia and current CourantSauv_Vola, a threshold value SeuilConso defining a duration beyond which an electrical consumption intended to be generated by the potential saving of software context data in the non-volatile memory 116 of the system 100 is lower than that intended to be generated by the potential saving of software context data in the volatile memory 114 of the embedded system 100 is determined. According to a particular exemplary embodiment, the threshold value SeuilConso, expressed in seconds, is determined by the equation:

[0091] [Math.6] Sëiiil(jonsct Con.wN,.m_v^a Sauÿ Vok Current,

[0092] Since the value of the current CourantSauv_Voia is temperature dependent, the threshold value SeuilConso is also temperature dependent. [Fig.5] represents examples of threshold values ​​SeuilConso obtained by considering the minimum values ​​of the electrical load ConsoNon_Vola (corresponding to the points having, for a given temperature, the lowest values), the maximum values ​​of the electrical load ConsoNon_Vola (corresponding to the points having, for a given temperature, the highest values), and the average values ​​of the electrical load ConsoN(m_Vola (corresponding to the points having, for a given temperature, the values ​​located between the low and high values)

[0093] In a following step 208, it is determined whether a backup of the software context data is carried out in the non-volatile memory 116 when a planned duration of prolonged standby of the embedded system is greater than the threshold value Threshold conso, or in the volatile memory 114 when the planned duration of prolonged standby is less than or equal to the threshold value Threshold conso-

[0094] When it is determined that the backup of the software context data is performed in the volatile memory 114, the system 100 can go directly into hibernation (step 210). In this case, the backup of the software context data in the volatile memory 114 consists of keeping this memory weakly powered since the software context data is already in volatile memory 114.

[0095] When it is determined that saving the software context data is performed in the non-volatile memory 116, the following steps can be implemented:

[0096] - programming a flag (or "Flag" in English) DNon_Vola indicating that the saving the software context data is performed in the non-volatile memory (step 212);

[0097] - determination, or calculation, of a start address for writing in the non-memory volatile 116 (step 214);

[0098] - writing software context data into non-volatile memory 116, from from the previously determined write start address (step 216);

[0099] - subtraction, from the expected duration of prolonged standby of the system 100, of a duration of implementation of the previous step of writing the software context data into the non-volatile memory 116 (step 218);

[0100] - stopping the power supply to the volatile memory 114 (step 220).

[0101] After these steps, the system 100 can go into hibernation (step 210).

[0102] At the exit from this prolonged standby of the system 100 (step 222), the following steps can be implemented:

[0103] - resumption of the power supply to the volatile memory 114 (step 224);

[0104] - determining a cause of the system 100 exiting hibernation (step 226), then: - if the exit from standby is due to a reset of the system 100, an initial start-up of the system 100, a software update via FOTA (Firmware Over-The-Air), or a monitoring event (watchdog), the system 100 is put directly into the active state (step 228) without reading the value of the DNon_Vola flag, or - if the exit from standby is not due to a reset of the system 100, an initial start-up of the system 100, a software update via FOTA, or a monitoring event, a reading of the value of the DNon_Vola flag is implemented (step 230).

[0105] - if the value of the DNon_Vola flag indicates that saving the context data software has been performed in the volatile memory 114, the system 100 is put directly into the active state (step 228), or

[0106] - if the value of the DNon_Vola flag indicates that saving context data software context data has been performed in the non-volatile memory 116, the software context data is read from the non-volatile memory 116 from the write start address and written to the volatile memory 114 (step 232), then blocks of the non-volatile memory 116 in which the software context data has been saved are erased (step 234).

[0107] Alternatively, it is possible that step 224 of resuming the power supply of the volatile memory 114 is implemented after reading the value of the flag D Non_voia, this resumption of the electrical supply of the volatile memory 114 occurring when the saving of the software context data has been carried out in the non-volatile memory 116 and prior to writing the data in the volatile memory 114.

[0108] In the example above, the update of the embedded system 100 can be carried out remotely by FOTA technology. The part of the memory 116 reserved for these updates can be used for saving the software context data.

[0109] In the method described above, the choice of the memory in which the saving of the software context data is carried out is determined by comparing an expected duration of prolonged standby of the system 100 with a threshold value defining a duration beyond which an electrical consumption intended to be generated by the potential saving of software context data in the non-volatile memory 116 of the system 100 is lower than that intended to be generated by the potential saving of software context data in the volatile memory 114 of the system 100.

[0110] According to a first variant of the method described above, it is possible that the saving of the software context data in the non-volatile memory is conditioned, in addition to the criterion of the threshold value SeuilConSo previously explained, on the fact that the planned duration of prolonged standby is less than or equal to a minimum duration of prolonged standby dMin guaranteeing a desired lifetime of the non-volatile memory 116. This minimum duration dMin can be expressed by the equation: [YES] [Math.7] j _ dvj^65><24x360& <tailt^^^ min     n max^cyde.^ ai^emémoire_libre

[0112] with dVie: desired lifetime of the non-volatile memory 116, in years;

[0113] Context size: size of software context data;

[0114] NMax_cyeieS: theoretical maximum number of write / erase cycles of non-volatile memory 116 before its degradation;

[0115] Memory Size _Ltbre: free memory size in non-volatile memory 116.

[0116] For example, the value of the parameter NMax_cydeS is for example between 10000 and 100000.

[0117] According to a second variant, the saving of the software context data in the non-volatile memory 116 can be conditioned on the fact that the value of a parameter N cyeieS_vie defined by the equation:

[0118] [Math. 8] aj _ aj Size Cyclesvie Cycles counter Size Méwiin,

[0119] is less than the theoretical maximum number of write / erase cycles of the non-volatile memory 116 before its degradation,

[0120] with NCycies_compteUr ■ number of write / erase cycles already performed by the non-volatile memory 116;

[0121] Context size: size of software context data;

[0122] FreeMemorySize: Free memory size in non-volatile memory 116.

[0123] The first and second variants described above can be combined, the saving of the software context data in the non-volatile memory 116 being in this case conditioned on the satisfaction of the three criteria set out above.

[0124] The non-volatile memory 116 may correspond to a Flash memory internal to the system 100, or may correspond to a Flash memory external to the system 100 and coupled thereto.

[0125] In all the examples previously described, a backup of the software context data in the non-volatile memory 116 can be carried out by using a file system of the non-volatile memory 116, or by using a register of a size adapted to the size of the software context data present in the RTC block 113 for storing the value of the DNon_Vota flag as well as for storing the start address of writing the software context data in the non-volatile memory 116.

[0126] The implementation of this method makes it possible to reduce, compared to existing solutions, the current consumption when the system implementing it is put into prolonged standby.

[0127] The method described above can advantageously be implemented within an embedded system, for example of the system on a chip type, or SoC ("System on a Chip" in English), comprising a volatile memory such as a random access memory and a non-volatile memory such as a Flash memory. According to a particular example, the method can be implemented in an embedded system communicating according to an NB-IoT type protocol such as the LTE Cat NB1 protocol.

[0128] Various embodiments and variations have been described. Those skilled in the art will understand that certain features of these various embodiments and variations could be combined, and other variations will occur to those skilled in the art.

[0129] Finally, the practical implementation of the embodiments and variants described is within the reach of those skilled in the art from the functional indications given above.

Claims

Claims

1. Method for managing the prolonged standby of an embedded system (100), comprising at least the steps of: - determination (202) of an electrical load value Conso Non_voia intended to be used, during prolonged standby of the embedded system (100), for a potential saving of software context data in a non-volatile memory (116) of the embedded system (100); - determination (204) of a value of a current CourantSauv_Voia intended to be used, during a prolonged standby of the embedded system (100), for a potential saving of software context data in a volatile memory (114) of the embedded system (100), at a first temperature; - determination (206), from the previously determined values ​​of electrical load ConsoNcm_Voia and current CourantSauv_Vola, of a threshold value SeuilConso defining a duration beyond which an electrical consumption intended to be generated by the potential saving of software context data in the non-volatile memory (116) is lower than that intended to be generated by the potential saving of software context data in the volatile memory (114); - saving the software context data in the non-volatile memory (116) when an expected hibernation duration of the embedded system (100) is greater than the previously determined ThresholdConsumption threshold value, or in the volatile memory (114) when the expected hibernation duration is less than or equal to the previously determined ThresholdConsumption threshold value.

2. The method of claim 1, wherein the electrical charge value ConsoNon_voia intended to be used for the potential saving of software context data in the non-volatile memory (116) is expressed in Coulombs and determined by the equation: Vllfa — I C'OUl OfHpnigJtm Vglu dpmg_Nait_Vola )^( eoWOnl£ffX * ^Csyie_Sl <m_Vols with CourantProg_Non_voia - value of the current used for programming of the non-volatile memory (116), in amperes; dprog Non_voia: duration of programming of the non-volatile memory (116), in seconds; CourantE / / _Non_Voia- value of the current used for erasing a part of the non-volatile memory (116), in amperes; dEff_Non_voia ■ duration of erasing a part of the non-volatile memory (116), in seconds; CourantCopie_NOn_voia- value of the current used for copying software context data into the non-volatile memory (116), in amperes; dCopie_Non_voia ■ duration of copying software context data into the non-volatile memory (116), in seconds.

3. Method according to claim 2, in which the threshold value SeuilConso is determined by the equation: onsoNon_V«la ^euuConso - Courant SmrVolii

4. Method according to one of the preceding claims, in which the saving of the software context data in the non-volatile memory (116) is further conditioned on the fact that the expected hibernation duration is less than or equal to a minimum hibernation duration dMin guaranteeing a desired lifetime of the non-volatile memory (116) and expressed by the equation: _ dVlgx365x24x3600x7ailleCmlextc with dVie: desired lifetime of the non-volatile memory (116), in years; Context size: size of the software context data; NMax_Cycies: theoretical maximum number of write / erase cycles of the non-volatile memory (116) before its degradation; FreeMemorySize: size of free memory in the non-volatile memory (116).

5. Method according to one of the preceding claims, in which the saving of the software context data in the non-volatile memory (116) is further conditioned on the fact that the value of a parameter NCyCies_vie defined by the equation: vr _ n y. TailleCmtexts * Cycles Vie * CycktyCamplitude A is less than the theoretical maximum number of write / erase cycles of the non-volatile memory (116) before its degradation, with Ncyeiesjcounter ■ number of write / erase cycles already performed by non-volatile memory (116); Context Size: size of software context data; FreeMemorySize: size of free memory in non-volatile memory (116).

6. Method according to one of the preceding claims, in which the saving of the software context data in the non-volatile memory (116) comprises the implementation of the following steps: - programming (212) a DNon_Voia flag indicating that the saving of the software context data is carried out in the non-volatile memory (116); - determining (214) a start address for writing in the non-volatile memory (116); - writing (216) the software context data in the non-volatile memory (116), from the start address for writing previously determined; - subtracting (218), from the expected duration of prolonged standby of the embedded system (100), a duration of implementation of the previous step of writing the software context data in the non-volatile memory (116); - stopping (220) the power supply of the volatile memory (114).

7. The method of claim 6, further comprising a hibernation exit of the embedded system (100) including at least the implementation of the following steps: - reading (230) the value of the DNon_Voia flag; - if the value of the DNon_Voia flag indicates that the saving of the software context data has been carried out in the volatile memory (114), the embedded system (100) is put directly into the active state, or - if the value of the DNon_Voia flag indicates that the saving of the software context data has been carried out in the non-volatile memory (116), the software context data are read from the non-volatile memory (116) from the write start address and written to the volatile memory (114), then blocks of the non-volatile memory (116) in which the software context data have been saved are erased.

8. The method of claim 7, wherein the standby output extended operation of the embedded system (100) further comprises, before or after the step of reading the value of the flag, a step of resuming the power supply to the volatile memory (114).

9. The method of claim 7 or 8, wherein the exit from hibernation of the embedded system (100) further comprises, before the step of reading (230) the value of the DNon_Vola flag, a step (226) of determining a cause of the exit from hibernation of the embedded system (100), then wherein: - if the exit from hibernation is due to a reset of the embedded system (100), an initial start of the embedded system (100), a software update via FOTA, or a monitoring event, the embedded system (100) is put directly into the active state without reading the value of the flag, or - if the exit from hibernation is not due to a reset of the embedded system (100), an initial start of the embedded system (100), a software update via FOTA, or a monitoring event, the reading of the value of the flag is implemented.

10. Embedded system (100) comprising means for implementing the method according to one of the preceding claims.

11. The embedded system (100) of claim 10, wherein the non-volatile memory (116) is Flash memory, and wherein the volatile memory (114) is RAM.

12. Computer program product comprising instructions which, when the program is executed by an embedded system (100), cause the latter to implement the method according to one of claims 1 to 9.

13. A computer-readable medium comprising instructions which, when executed by an embedded system (100), cause the latter to implement the method according to one of claims 1 to 9.

Images