Methods for selectively using a bootloader and methods for selectively traversing a code sequence of a bootloader

Abstract

Method for selectively using a bootloader to modify code in at least one application of a software-controlled device, wherein a plurality of the software-controlled devices are operated via a common data bus, the method comprising: a) Addressing the devices via a data bus, wherein the addressing is done by assigning a bus address to each device on the data bus; b) Specifying at least one encoding for each bus address, wherein the encoding includes a first code section representing the bus address; c) Specifying a common memory area by means of a second code section of the encoding, wherein the memory area is accessible to the bootloader and the application; d) Generating, in response to a triggering event, by the application, at least one first indication, wherein the first indication is assigned to the device whose application contains code that is to be changed; e) Storing, through the application, the encoding and the first indication in the common memory area; f) Retrieval, through the bootloader, the encoding and the first indication; and g) Modifying, by application, the application code of the device indicated by the coding in response to the retrieval of the first indication by the bootloader.

Description

Field of invention

[0001] The invention relates to a method for selectively using a bootloader to modify code in at least one application of a software-controlled device, in particular an actuator in a vehicle.

[0002] Furthermore, the invention relates to a method for selectively traversing a code sequence of a bootloader as a result of an interruption event, in particular a reset of an application of a software-controlled device in a vehicle. background

[0003] In vehicles, various devices are often operated via a shared bus (data bus), particularly a LIN bus. These devices might be actuators for different applications and may have different software applications and hardware. Typically, however, the devices share the same bootloader, even if the application software differs. Occasionally, though, it becomes necessary to update the software applications of individual devices. One option is to update the devices, or individual devices, via the LIN bus using the LIN protocol. In practice, however, this is disadvantageous because the LIN protocol consumes a significant amount of storage space within the devices. Another option is to transfer software application updates to the devices using the bootloader.However, this has the disadvantage that all devices can only be updated simultaneously.

[0004] Document WO 2012 / 028 541 A1 describes a method for programming or updating software versions, in particular firmware, of lighting technology bus participants using update software. The publication Rogers, G.: LIN Trends in Automotive Electronics. In: Elektronik Industrie, 2006, No. 1 / 2, pp. 72-74, ISSN: 0174-5522 describes applications of the Local Interconnect Network (LIN) standard. DE 10 2016 212 204 A1 describes a method for updating a bootloader and includes a higher-level control system that contains a central processing unit in conjunction with non-volatile memory with a shared memory architecture.

[0005] The invention aims to provide a method which allows the selective updating of individual devices by means of a bootloader.

[0006] This problem is solved by the invention specified in the independent claims. Advantageous embodiments are described in the dependent claims. Brief description of the invention

[0007] According to a first aspect of the invention, a method of the type mentioned at the outset is provided, wherein a plurality of the software-controlled devices are operated via a common data bus, in particular a LIN bus, the method comprising: a) Addressing devices via a data bus, wherein addressing is done by assigning a bus address to each device on the data bus; b) Specifying at least one encoding for each bus address, wherein the encoding includes a first code section representing the bus address; c) Specifying, by means of coding, in particular by means of a second code section, a common memory area, wherein the memory area is accessible to the bootloader and the application; d) Generating, in response to a triggering event, by the application, at least one first indication, in particular a bootloader flag, wherein the first indication is assigned to the device whose application contains code that is to be modified; e) Storing, through the application, the encoding and the first indication in the common memory area; f) Retrieval, through the bootloader, the encoding and the first indication; and g) Modifying, by application, the application code of the device indicated by the coding in response to the retrieval of the first indication by the bootloader.

[0008] The method has the advantage that all devices on a bus (data bus), preferably a LIN bus, can be individually addressed. By assigning an indication, preferably a bootloader flag, to the individual addresses, it is possible to serially overwrite (flash) the device or the application code of the devices using one and the same bootloader. For the purposes of the application, flashing / overwriting is understood to mean overwriting stored software, i.e., modifying the software code. In other words, all devices, including different devices with different applications, can be selectively updated (i.e., brought up to date by updating the code, i.e., overwriting) using the same bootloader.The invention is based on the understanding that a) a unique assignment of the physical addresses of the devices on the LIN bus is required, but b) these addresses must be assigned a further indicator, the indication, to enable the bootloader to recognize individual devices. For this purpose, a common memory area is defined in which this indication can be stored and retrieved by the bootloader. The memory area can be defined by "recoding" the individual LIN address, i.e., by assigning an additional code to the bus address (for example, a LIN address), which comprises two code sections. These code sections serve to encode the address and to encode the common memory area. In this way, when the bootloader retrieves the bus address, it can also retrieve an address range of a common memory area. The indication, e.g.,a flag must be stored, which the bootloader can use to recognize that a particular device needs to undergo an update routine.

[0009] In one embodiment of the invention, the modification further includes causing the application to execute an update routine via the bootloader. The bootloader, or its code, is itself immutable. The bootloader's function is to trigger the application to execute the update routine. This allows any application, including applications from different devices, to be prompted to execute the update routine by the same bootloader. The actual code modification, i.e., the overwriting for the purpose of updating, is then performed by the application itself.

[0010] In one embodiment of the invention, the method comprises the application writing a second indication to the common memory area, wherein the second indication represents a reason for changing the application code, particularly wherein the writing occurs after the application has executed the update routine. Advantageously, the application / bootloader can determine the reason for the last reset by reading the second indication from the common memory area. Subsequently, the execution of a bootloader sequence can be adjusted. In other words, bootloader sequences can be modified, and in particular omitted, depending on the reset reason. This allows, for example, a faster restart of the application.

[0011] In one embodiment of the invention, the common memory area is a memory area in a non-volatile storage device. This ensures that data stored in the memory area remains available after a restart.

[0012] In one embodiment of the invention, defining the at least one encoding for each LIN address includes converting an ASCII encoding of the LIN address into a hexadecimal format; in particular, the encoding is specified in hexadecimal format. The ASCII format of the LIN address This can cause misunderstandings. Therefore, it can also be specified in hexadecimal format. The hexadecimal format has the advantage of being less error-prone, while still supporting all regular bootloader functionalities.

[0013] In one embodiment of the invention, the shared memory area can be defined on an EEPROM, a microcontroller register, or even within the application itself. This allows for the flexible use of various available memory resources. In particular, no additional memory is required. The shared memory area can be defined on any available memory device.

[0014] In particular, the shared memory area comprises a first and a second area, with the encoding and the first indication being written to the first area and the second indication to the second area.

[0015] The division into two storage areas allows for the unambiguous assignment of the first indication and coding to the second indication.

[0016] In one embodiment of the invention, the first indication is selected from a limited number of indicators. The presence of an indication that is not selected from this limited number can thus be interpreted as an indication that the indication may be faulty. If an indication value lies outside a specific range, either a standard procedure can be initiated by reverting to a default value of the indication, or the interaction between the bootloader and the application can be terminated. This ensures the integrity of the interaction between the bootloader and the application.

[0017] In one embodiment of the invention, the encoding comprises a first and a second code section, wherein the first code section encodes the bus address, a bootloader ID, and an application version number; and wherein the second code section encodes the common memory area. This subdivision allows the creation of a protected memory area, e.g., an EEPROM, which both the bootloader and the application can access and in which immutable operating data can be stored. This operating data is then not lost during flashing / updating. This area is variable due to the encoding. Preferably, the first and / or the second code section has a size of one byte. The bus address can, in particular, be the LIN address of a LIN bus.

[0018] In one embodiment of the invention, the common memory area is a protected memory area, indexed by the second byte of the encoding, wherein the second byte defines an end area of ​​the non-volatile memory whose code is not to be changed. Factory settings, operating data, etc., can then also be stored in the protected memory area. Flash cycles can also be stored here. The minimum size of the protected memory area is 12 bytes, and the maximum size is 192 bytes.

[0019] Preferably, the software-controlled device comprises an electric motor. The method can therefore be used, in particular, for updating the firmware of an electric motor and / or for mediating data between the bootloader and the firmware of an electric motor's control software. The electric motor can thus be selectively addressed for a software update via a data bus, among a plurality of bus participants. The data bus can, in particular, be a LIN bus. Additionally or alternatively, a method can be provided by which data from the bootloader is supplied to the firmware, so that the firmware can be regulated or controlled depending on the supplied data. In particular, the firmware can execute different program sequences after a restart, depending on the reason for the restart.

[0020] According to a second aspect of the invention, a method is provided for selectively executing a bootloader code sequence as a result of an interruption event, in particular a reset of an application of a software-controlled device in a vehicle. The method comprises: determining, by the bootloader, a reset reason representing the interruption event, wherein the determination includes retrieving initial information representing the reset reason from a common memory area; and, in response to the determination: at least partially executing the bootloader code sequence to start the application. Advantageously, the application / bootloader can determine the reason for the last reset by reading the initial information from the common memory area. Subsequently, the execution of a bootloader sequence can be adjusted.In other words, depending on the reason for the reset, bootloader sequences can be modified, and in particular, omitted. This can, for example, speed up the application restart.

[0021] In one embodiment of the second aspect of the invention, the interruption event is a power-on reset (POR), a watchdog reset, a wake-up event, or a delay event. Different interruption events can have different characteristics, which allows the bootloader sequence to be adapted according to the interruption event.

[0022] In one embodiment of the second aspect of the invention, the common memory area is a region of a register of a microcontroller of the software-controlled device, in particular wherein the common memory area is a protected region. The first piece of information can be stored in a protected region that is not overwritten, for example, during an update. This ensures that the information about the interruption event is permanently stored and can be retrieved at any time.

[0023] In an embodiment of the second aspect of the invention, the at least partial execution of the code sequence further comprises: if a POR event has been determined: complete execution of the bootloader sequence, wherein the complete execution includes waiting for a defined first time interval, in particular approximately 50 ms; if a watchdog reset, delay event, or wake-up event has been determined: partial execution of the bootloader sequence, wherein the partial execution includes waiting for a second time interval, in particular approximately 15 ms. The second time interval may, in particular, be shorter than the first time interval. In the case of a POR event, the complete bootloader sequence may be executed.This includes a 50 ms waiting period before the application starts, where 50 ms represents the maximum waiting time if the application uses LIN bus communication (the maximum permissible time until communication between the application and the LIN bus is fully established is 100 ms). If the interruption event is a watchdog reset, a delay event, or a wake-up event, the bootloader may only allow a short waiting time or none at all. The application can be started directly by the bootloader or after a short delay, e.g., 15 ms. This can result in a short waiting time until the application starts and thus until the system is fully operational, depending on the reason for the restart.

[0024] In particular, determining also includes calling the microcontroller's register and retrieving the register entry by the bootloader sequence.

[0025] In particular, determining also includes ascertaining whether an update request exists for the application; and / or ascertaining whether the update has already been performed.

[0026] In a further embodiment of the second aspect of the invention, the method also includes storing, by application, the first information in the common memory area in response to the interruption event. Brief description of the drawings

[0027] Exemplary embodiments of the invention are described in more detail below with reference to the accompanying drawings. They show: the Fig. Figures 1a to 1f show a schematic representation of an exemplary method according to the invention in an exemplary software-controlled device; the Fig. 2 a first embodiment of an exemplary method according to one aspect of the invention; the Fig. 3 a second embodiment of the exemplary method according to the aspect of the invention from Fig. 2; the Fig. 4 an exemplary division of a memory area of ​​a memory of a software-controlled device. Character description

[0028] The Fig. Figures 1a to 1f show an exemplary method according to the invention. In block 1, an initialization process is performed first. In block 2, an initial registration 1 of an application in the bus system is carried out. For example, the data bus is configured as a LIN bus. In step 2A, the device waits for the receipt of an initial message from the data bus. In the next step 2B, the expiration of a waiting period (timeout) is checked. The waiting period can, for example, be predetermined.

[0029] If no message is received within the waiting period, the operating voltage is checked in step 2C. For example, it is checked whether the operating voltage is greater than a minimum operating voltage. In this example, the minimum operating voltage is 7V. If the minimum operating voltage is not reached (false), the program jumps back to step 2A, waiting to receive an initial message. If the minimum operating voltage is reached (true), step 2D checks whether there is a request to update the bootloader. If not, the application is started in step 2E. If such a request is present, the program jumps to routine 7 for updating the bootloader.

[0030] If the waiting time is not exceeded in step 2B (false), then in step 2F, the receipt of a defined message is checked. In this example, the receipt of a command "ProgX" is checked, where "Prog" denotes a command to execute an action, and "X" denotes a variable for encoding the command. For example, "X" could represent a value that triggers an update, or another value that triggers reading the firmware version number or the bootloader version number. If a defined message is not received (false), the process returns to step 2A. The defined message could, in particular, be a query for the version number of the bootloader or the application software, or a command to update the application software (flashing). Furthermore, the message could include addressing a bus participant, such as an actuator.If a defined message is received (true), an acknowledgment is sent in step 2G. A routine for updating is then called.

[0031] In Block 3 (see especially the Fig. 1b and Fig. Figure 1c) shows an exemplary procedure for an overwrite operation. In step 3A, a command to execute the overwrite operation is received. Receiving this command includes checking whether it corresponds to the broadcast command "Prog!" for performing an update. If the command "Prog!" was received in step 2F, a firmware update is performed. A firmware update is also performed if the message is addressed to the receiving bus participant and lies within a predefined range of values. In this example, the range of values ​​is the address space 0xC0 to 0XDF, and the received message must correspond to the address stored in the memory of the bus participant.If either a broadcast message for an update or a command to update the firmware directed to the bus participant is received (true), the write protection of the flash memory is disabled in a further step 3B. In a further step 3C, the flash memory is erased. Specifically, the erasure can encompass the entire flash memory, except for the area designated for or allocated by the bootloader. In a further step 3D, it can then be verified whether the erasure operation was successful. If so (true), an acknowledgment of the erasure operation is sent in a step 3E. Finally, in a step 3F, the clock frequency of the control circuits of the bus participants to be updated is synchronized. Specifically, the synchronization can be to the clock frequency of a bus master, particularly a LIN master.For this purpose, the bus master can send a corresponding message to the bus participants via the bus. For example, the clock frequency is changed from 9600 Hz to up to 512 kHz, preferably to up to 48 kHz. Then, in step 3G, it is checked whether the complete data set for the overwrite operation has been received. If all data has been received (true), the bootloader is reset in step 3H. If not all data has been received (false), in step 3I it is checked whether a checksum of the transmitted data deviates from an expected checksum value by more than a predefined error value CHK_ERR_Max. If this is the case, an error state is entered in step 3J. If this is not the case (false), in step 3K it is checked whether a specified prefix has been received, and in step 3L it is checked whether the data following the prefix has been received.Once the prefix and data have been received, the checksum is recalculated in step 3M and compared to the received checksum. If the two values ​​do not match, the process returns to step 3G; otherwise, step 3M checks whether a normal data record has been transmitted. If so, the received data is processed in step 3Q. If not (false), step 3R checks whether a final data entry exists. If no final data entry exists, step 3S returns to an error state; otherwise (true), step 3T checks whether the remaining data was written successfully. If the data was written successfully (true), a confirmation message is sent in step 3U, and a FlashCount counter is incremented in step 3V, after which, in this example, the process returns to step 3G.If step 3T indicates that the additional data was not successfully written (false), an error message is displayed in step 3W.

[0032] In the Fig. Block 4 to 6, shown in Figure 1d, demonstrates further bootloader functionalities. If, in step 3A, no bootloader update command is present (false), the process jumps to step 4A of block 4 and checks whether a query for the application's version number (command "Prog?") is present. This command can be a broadcast "Prog?" or a message addressed to the bus participant within a predefined address space (here in the range 0x80 to 0x9F). If a command is received in this range, the process further checks whether the received value corresponds to a value stored by the bus participant (received value - 0x20 = stored value) and whether the command is therefore addressed to that bus participant.If either of the two conditions is met (true), steps 4B to 4D are executed, whereby in step 4B the version number of the application is sent, in step 4C a corresponding checksum is sent, and in step 4C a restart (reset) of the bootloader is performed.

[0033] In the other case, if no query for the application version number is present in step 4A (false), the process jumps to step 5A of block 5, which checks whether a "Prog%" command for querying the bootloader version number is present. Here, too, the command can be a broadcast "Prog%" or a message addressed to the bus participant within a predefined address space (here in the range 0xA0 to 0xBF). If a command is received in this range, it is further checked whether the received value corresponds to a value stored by the bus participant and whether the command is therefore addressed to that bus participant. In the example, this check is performed to see if the received value, minus the value 0x40, matches the stored value.If either of the two cases is true, steps 5B to 5D are executed, whereby in step 5B the version number of the bootloader is sent, in step 5C a corresponding checksum is sent, and in step 5C a restart (reset) of the bootloader is performed.

[0034] However, if no request regarding the bootloader version number is received in step 5A (false), the process jumps to step 6A of block 6, which checks whether a "Prog#" command to erase the memory is present. If such a command is present (true), the EEPROM is erased in step 6B and the flash memory is erased in step 6C. Subsequently, an acknowledgment of the erasure process is sent in step 6D, and an acknowledgment is sent from the bus participant to the bus master in step 6E. Finally, the bootloader is restarted (reset) in step 6F. If no command to erase the memory is received in step 6A, the bootloader is restarted in a further process step.

[0035] In Block 7 (see Fig. 1e and Fig. Figure 1f) shows an example procedure for updating the bootloader itself. If step 2D detects a request to update the bootloader, an update routine is executed according to block 7. In step 7A, initialization is performed first, followed by step 7B, which checks whether the maximum initialization time has elapsed. If the initialization time has expired, step 7C checks whether a further time limit has expired. If this has also expired (true), step 7D restarts the bootloader. If, however, the maximum initialization time has not been reached in step 7B (false), step 7E checks whether a "BootX" command to start the bootloader has been received. If not, the process returns to step 7A.If the "BootX" command is received, an acknowledgment is sent in step 7F, and in step 7G, it is checked whether a bootloader update has occurred. If not, a bootloader restart is initiated in step 7H. Otherwise, a bootloader update is started by the application software (firmware) in step 7I. During this process, the clock frequency can be resynchronized with the clock frequency of the bus master. In particular, the clock frequency of the bus participant(s) can be increased, thus accelerating the update process.

[0036] In a further step, 7J, it is then checked whether all data has been received. For example, it can be checked whether all data frames required to perform the bootloader update have been received. If all data has been received (true), a bootloader restart can be initiated in step 7K. If, however, not all data has been received (false), a checksum of the data is calculated in step 7L, and it is checked whether the calculated checksum matches a received checksum. In particular, it can be checked whether the error value resulting from the comparison of the two checksum values ​​exceeds a maximum error value. If this is not the case, an error state is assumed in step 7M. Otherwise, in step 7N, it is checked whether a data prefix has been received. If so, in step 7O, it is checked whether the remaining data has been received.If the remaining data has also been received, step 7P verifies whether the checksum is correct. If the checksum value is incorrect, an error message is sent in step 7T, and a checksum error counter is incremented in step 7R. The process then returns to step 7J. If step 7P determines that the checksum value is correct, step 7S checks whether a normal data entry is present. If not, step 7T writes the bootloader to the designated memory area. The process then returns to step 7J. If step 7S determines that the data entry is not normal, step 7O checks whether a final data entry is present. If this is also not the case, step 7V enters an error state.If, however, a final data entry exists, step 7W checks whether the data was successfully written to the data storage, specifically to the flash memory. If step 7W determines that the remaining data was successfully written to memory (true), a final acknowledgment is sent in step 7X, and the process then returns to step 7J. If, however, step 7W does not determine that the data was successfully written to memory (false), an error acknowledgment is sent in step 7Y.

[0037] Fig. Figure 2 shows an exemplary procedure for selectively traversing a boot sequence depending on a reset reason. The procedure begins with a Power On Reset (POR) in step 22A, i.e., the activation of a power source. The next step determines the type of interruption event, i.e., the reason for the power interruption. For this purpose, step 22B checks whether the reset was triggered by a watchdog timer, and if so, a corresponding indication is written to a memory area (step 22C). If not, another step 22C checks whether the interruption event was caused by waking from a sleep state, and if so, a corresponding indication is written to a memory area (step 22E). If this is also not the case, a further step 22F checks whether the interruption event was triggered by a wake-up signal received via the LIN bus.If necessary, a corresponding indicator is written to memory (step 22G). Then, in step 22H, it is determined whether a "flash process"—that is, an update—should be performed. If so, this is done, and in step 22J, the completion of the update process is verified. In step 22K, another indicator is written to memory to confirm this. After the update has been executed, or if step 22H determines that no update should be performed, the application is booted in step 22I. The boot process can always be carried out taking into account the indicators stored in memory.

[0038] Fig. Figure 3 shows an exemplary procedure for selectively executing a boot sequence depending on a reset reason, taking a waiting period into account. After power-on in step 33A, steps 33B, 33E, and 33F check what type of interrupt event is present. If only a "normal" POR event is present (i.e., no watchdog reset (see step 33B), no retention mode (see step 33E), and no LIN wake-up (see step 33F)), a waiting period of 50 ms is applied (step 33G) before the application is booted in step 33D. If another reset reason is present, a shorter waiting period of 15 ms is applied (step 33C) before the application is booted in step 33D.

[0039] Fig.Figure 4 shows a diagram of an NVRAM address range in hexadecimal representation. This address range is protected. The minimum size of the protected address range is 15 bytes (from 0x500001B4 to 0x500001BF). The maximum size of the protected address range is 192 bytes (from 0x500000FF to 0x500001BF). The size of the protected address range depends on the byte with address 0x1B6. The protected address range also includes a byte for a flash count (0x1B8) and a byte for the address of a device to which the memory area is assigned (0x1BA). Each of these bytes is secured with a checksum. Furthermore, the address range 0x500001BC to 0x500001BF is reserved for internal specifications, such as unchanging operating parameters, version number, etc.

Claims

[1] Method for selectively using a bootloader to modify code in at least one application of a software-controlled device, wherein a plurality of the software-controlled devices are operated via a common data bus, the method comprising: a) Addressing the devices via a data bus, wherein the addressing is done by assigning a bus address to each device on the data bus; b) Specifying at least one encoding for each bus address, wherein the encoding includes a first code section representing the bus address; c) Specifying a common memory area by means of a second code section of the encoding, wherein the memory area is accessible to the bootloader and the application; d) Generating, in response to a triggering event, by the application, at least one first indication, wherein the first indication is assigned to the device whose application contains code that is to be changed; e) Storing, through the application, the encoding and the first indication in the common memory area; f) Retrieval, through the bootloader, the encoding and the first indication; and g) Modifying, by application, the application code of the device indicated by the coding in response to the retrieval of the first indication by the bootloader. [2] Method according to claim 1, wherein the modification further comprises: causing the application to undergo an update routine (7) via the bootloader. [3] Method according to claim 1 or 2, comprising writing, by the application, a second indication to the common memory area, wherein the second indication represents a reason for changing the application code. [4] Method according to claim 3, wherein the writing takes place after the application has run through the update routine. [5] Method according to any of the preceding claims, wherein the common storage area is a storage area in a non-volatile storage device. [6] Method according to any of the preceding claims, wherein the data bus is a LIN bus. [7] Method according to claim 6, wherein specifying at least one encoding for each LIN address comprises converting the ASCII encoding of the LIN address into a hexadecimal format, in particular wherein the encoding is specified in hexadecimal format. [8] Method according to any of the preceding claims, wherein the common memory area is specified on an EEPROM, a microcontroller register or in the application. [9] Method according to any of the preceding claims, wherein the common storage area comprises a first and a second area, wherein the encoding and the first indication are written to the first area and the second indication to the second area. [10] Method according to any of the preceding claims, wherein the first indication is selected from a limited number of indicators. [11] Method according to any of the preceding claims, wherein the encoding comprises a first and a second code section, wherein the first code section contains the encoded: the bus address, a bootloader ID, an application version number; and wherein the second code section contains the encoded: the common memory area. [12] Method according to any of the preceding claims, wherein the common memory area is a protected memory area which is indexed by the second code section of the encoding, wherein the index defines an end area of ​​the non-volatile memory whose code is not to be changed. [13] Method according to any of the preceding claims, wherein the software-controlled device comprises an electric motor. [14] Method for selectively traversing a code sequence of a bootloader as a result of an interruption event of an application of a software-controlled electric motor, the method comprising: Determine (22B, 22D, 22F) by the bootloader a reset reason representing the interrupt event, wherein determining includes retrieving initial information representing the reset reason from a common memory area; and in response to the determination: At least partial execution of the bootloader code sequence to start the application (22I). [15] Method according to claim 14, wherein the interruption event is a power-on reset (POR), a watchdog reset, a wake-up event, or a delay event. [16] Method according to claim 14 or 15, wherein the common memory area is an area of ​​a register of a microcontroller of the software-controlled device. [17] Method according to any one of claims 14 to 16, wherein the at least partial traversal of the code sequence further comprises: If a POR event has been determined: complete execution of the bootloader sequence, whereby the complete execution includes waiting for a specified initial time period; If a watchdog reset, delay event, or wake-up event has been determined: partial execution of the bootloader sequence, where the partial execution includes waiting for a second period of time. [18] Method according to claim 17, wherein the second time interval is shorter than the first time interval. [19] Method according to any one of claims 14 to 18, wherein the determining further comprises: Calling the microcontroller's register and retrieving the register entry by the bootloader sequence. [20] Method according to any one of claims 14 to 19, wherein the determining further comprises: Determine if there is an update request for the application; and / or determine if the update has already been performed. [21] Method according to any one of claims 14 to 20, wherein the method further comprises: The application stores the first piece of information in the shared memory area in response to the interruption event.

Images