Method for dynamic loading on a microcontroller unit

By generating two images of the firmware in the microcontroller unit and identifying the relocation entry point, the compatibility problem between the microcontroller unit and the application is solved, enabling the firmware to run independently under different integrated development environments and compilers, and improving the configurability and flexibility of the microcontroller.

CN122219986APending Publication Date: 2026-06-16NXP BV

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
NXP BV
Filing Date
2024-12-16
Publication Date
2026-06-16

Smart Images

  • Figure CN122219986A_ABST
    Figure CN122219986A_ABST
Patent Text Reader

Abstract

A method is provided herein that enables dynamic loading on MCUs.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to a method and system. Specifically (but not exclusively), this invention relates to a method for dynamic loading on a microcontroller unit (MCU). Background Technology

[0002] Integrated development environments (IDEs) are typically used to enable programmers to develop software code that will be used on devices such as microcontroller units. They provide many useful tools, such as source code editors, automation tools, and debuggers.

[0003] One of the problems with using a specific integrated development environment is compatibility between compilers, especially between applications and device firmware.

[0004] The foregoing content is taken into account in conceiving the various aspects and implementation methods. Summary of the Invention

[0005] Various aspects may involve the configuration of the firmware used in the microcontroller unit.

[0006] From a first aspect, a computer-implemented method is provided that enables the configuration of firmware used in a microcontroller unit. The method can be implemented using one or more computing devices. The microcontroller can, for example, be used to train and implement one or more neural networks. The one or more computing devices may include one or more microcontroller units. The method may include identifying firmware associated with a microcontroller unit. The method may include identifying an address of the identified firmware. The method may include linking the identified firmware to at least one different address from the identified address. The method may include determining a first image of the identified firmware based on the identified address, and generating a second image of the identified firmware based on the at least one different address. The method may include comparing the first image of the identified firmware with the second image of the identified firmware to identify a relocation entry point for the firmware. The method may further include using the image of the firmware during the execution of an application.

[0007] A method according to the first aspect enables firmware associated with a microcontroller unit to be independent of the development environment and compiler. This expands firmware availability and increases the configurability of the microcontroller.

[0008] Optionally, the method further includes identifying the address of the identified firmware based on a call from the application to initialize the microcontroller unit.

[0009] Optionally, the call from the application responds to a power-on reset operation on the microcontroller unit.

[0010] Optionally, linking the identified firmware to at least one different address from the identified address includes modifying the firmware's linking script to link to said different address.

[0011] Optionally, comparing the first and second images of the identified firmware includes identifying differences in the binary components associated with the first and second images.

[0012] Optionally, identifying differences in the binary components associated with the first and second images includes performing a binary comparison.

[0013] Optionally, the firmware relocation entry point is stored in association with the microcontroller component.

[0014] Optionally, the relocation entry point is used at runtime to execute the firmware.

[0015] Optionally, the stack pointer associated with the firmware is reset after the firmware is executed.

[0016] Optionally, the reset of the stack pointer is associated with a preset stack pointer value.

[0017] Optionally, the firmware is assigned to the different addresses based on user input.

[0018] Optionally, the firmware is assigned to the different address based on the use of a compiler that is different from the compiler originally intended for use by the application.

[0019] Alternatively, a non-transitory computer-readable storage medium may be provided, on which executable instructions are stored, which, when executed by a processor of a computer system, cause the computer system to perform at least the first aspect.

[0020] A system configured to implement the first aspect can also be provided.

[0021] Alternatively, a processing resource may be provided, comprising a processor and a memory, the memory including executable instructions that, upon execution by the processor, cause a reader to perform the method of the first aspect.

[0022] A microcontroller unit configured according to the method of the first aspect can also be provided. Attached Figure Description

[0023] The embodiments will now be described by way of example only and with reference to the following figures, in which:

[0024] Figure 1 This illustrates the process of configuring firmware for use by the microcontroller unit; and

[0025] Figure 2A schematic diagram of the microcontroller unit is shown, along with user interaction and the initialization of the microcontroller unit's firmware. Detailed Implementation

[0026] We now refer to Figure 1 This paper illustrates a method for configuring firmware for use by a microcontroller unit or other embedded computing device.

[0027] In step S100, the user initializes component 202 of the microcontroller unit 200 via a power-on reset (POR) operation using a computing device 204 communicating with the microcontroller unit 200. This generates a call to the reset handler of the computing device 204 and initializes its firmware, i.e., the firmware of the computing device 204. This can be part of a project development operation in an IDE. The binary component of the project may include code for marking the stack pointer or the top of the stack pointer, or it may include code identifying the address of the firmware image that the user may wish to reallocate.

[0028] If the binary component has already been compiled, it can be used in any IDE, as long as the target platform is the same, i.e., the processor and instruction set are the same. To use the binary component, it only needs to be placed in memory.

[0029] When a project is created, the function API is exported to the virtual method table.

[0030] In step S102, the user initializes the application code they wish to run on the microcontroller unit 200. This initialization of the microcontroller unit occurs in step S104.

[0031] The microcontroller initialization causes the stack pointer to be initialized, and the stack pointer is pushed to the top of the stack in the allocated memory. The microcontroller initialization also stores the return address of the microcontroller 200's initialization function. Users developing applications can include the "incbin" command in their project during project build, which includes a binary file.

[0032] In step S106, the top of the stack is marked with an address specified by component 202, such as "0x524c50530x434e5546".

[0033] In step S108, the firmware of component 202 is invoked by calling the component's reset handler. This allows the firmware of component 202 to be identified as a reset handler, which is part of the firmware.

[0034] In step S110, we identify the firmware address.

[0035] In step S112, on a separate computing device (as opposed to component 202), the firmware is linked to different addresses by applying different link addresses. This creates two images of the firmware, namely a first image and a second image, each with a different link address. Each image corresponds to a binary file of the firmware. The separate computing device may be computing device 204. Steps S100 to S110 are implemented on component 202 or implemented using component 202.

[0036] In step S114, on the independent computing device, for example, binary comparison is used to compare the binary components corresponding to each of the first and second images of the firmware to identify where they differ.

[0037] The difference between the two images corresponds to the code relocation entry point, and the code identifier corresponds to step S116. This identifies the relocation entry point. This is also implemented on the independent computing device. This information allows the images to retain information about the firmware's program image. That is, if it can be determined, any assigned address can be used to deploy the firmware, i.e., the firmware becomes independent of a specific integrated development environment (IDE) and the compiler corresponding to that specific IDE.

[0038] By making the firmware independent of a specific IDE, the binary file corresponding to the image of the firmware can be debugged. By identifying the relocation entry point of the firmware, the corresponding component 202 can be relocated on the microcontroller unit at runtime.

[0039] The application can then be executed using a standalone version of the firmware's IDE, meaning execution is not limited to a specific IDE.

[0040] In other words, after steps S112 to S118, a binary component is obtained. This binary component is IDE-independent and not limited to a specific IDE.

[0041] After the identified relocation entry data is retrieved, the firmware stack pointer is restored on the microcontroller unit 200. This is step S120.

[0042] To complete this process, the component initialization code can then be modified in the IDE. The firmware address can be reset to its original address, or a relocation entry can be stored to identify the relocatable location of the firmware in the image, allowing the firmware to reside on the microcontroller unit 200 at runtime. This is step S122.

[0043] Steps S120 to S122 are implemented on the microcontroller unit 200.

[0044] If a user is performing a reallocation to perform dynamic memory allocation within an application, the user may want to relocate the firmware. This would allow the code to be reallocated.

[0045] Since the firmware can be relocated using relocation entry data, we can make the firmware independent of the IDE, and thus enable dynamic loading, as it is independent of the compiler and the IDE.

[0046] In summary, the described embodiments offer the following advantages:

[0047] ● (Firmware) Debuggable binary files enable the integration of the corresponding components;

[0048] ● The component obtains relocation entry data, which means that the firmware is relocatable at runtime;

[0049] ● No need to know the executable and linker format (ELF) information;

[0050] ● Provide global variables inside the component so that their initialization can be supported;

[0051] ● The firmware is IDE-free, which means that applications can be made by any IDE and used by any IDE.

[0052] It should be noted that the aspects and embodiments mentioned above illustrate this disclosure but do not limit it, and those skilled in the art will be able to devise many alternative embodiments without departing from the scope of this disclosure as defined by the appended claims. Any reference numerals placed in parentheses in the claims should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps other than those listed in any claim or throughout the specification. In this specification, "comprising" means "comprising... or consisting of...". A singular reference to an element does not exclude a plural reference to such an element, and vice versa. This disclosure can be implemented by means of hardware comprising several disparate elements and by means of a suitably programmed computer. In an apparatus claim listing several components, several of these components may be embodied by the same piece of hardware. The only fact is that reciting certain measures in mutually different dependent claims does not imply that combinations of these measures cannot be advantageously utilized.

Claims

1. A computer-implemented method for configuring firmware used in a microcontroller unit, characterized in that, The method includes: Identifies the firmware associated with the microcontroller unit; The address of the firmware being identified; Link the identified firmware to at least one different address from the identified address; A first image of the identified firmware is determined based on the identified address, and a second image of the identified firmware is generated based on the at least one different address; The first image of the identified firmware is compared with the second image of the identified firmware to identify the relocation entry point of the firmware; The image of the firmware is used during the execution of the application.

2. The method according to claim 1, characterized in that, The method further includes identifying the address of the identified firmware based on a call from the application used to initialize the microcontroller unit.

3. The method according to claim 1, characterized in that, The call from the application is in response to a power-on reset operation on the microcontroller unit.

4. The method according to claim 1, characterized in that, Linking the identified firmware to at least one different address from the identified address includes modifying the linker script of the firmware to link to the different address.

5. The method according to claim 1, characterized in that, Comparing the first and second images of the identified firmware includes identifying differences in the binary components associated with the first and second images.

6. The method according to claim 1, characterized in that, The firmware is assigned to the different address based on the use of a different compiler than the one originally intended for use by the application.

7. A non-transitory computer-readable storage medium having executable instructions stored thereon, characterized in that, The executable instructions, due to execution by the processor of the computer system, cause the computer system to perform at least the method according to any one of claims 1 to 6.

8. A system, characterized in that, Configured to implement the method according to any one of claims 1 to 6.

9. A method for processing resources, characterized in that, It includes a processor and a memory, the memory including executable instructions that, when executed by the processor, cause a reader to perform the method according to any one of claims 1 to 6.

10. A microcontroller unit, characterized in that, The microcontroller unit is configured according to the method of any one of claims 1 to 6.