Core and Application Binary Separation in ARM-Based Embedded Systems
In ARM-based embedded systems, particularly those utilizing Real-Time Operating Systems (RTOS), there is often a need to separate the core functionality from application-specific code. This separation allows for modular development, easier updates, and independent execution of multiple applications. The core functionality typically includes essential services such as process management, timer handling, UART communication, and API definitions. On the other hand, application-specific code leverages these core services to perform specific tasks. The challenge lies in ensuring that both the core and application binaries can coexist in flash memory, execute independently, and not interfere with each other’s operation.
Core and Application Binary Separation Requirements
The primary requirement is to divide the embedded image into two distinct parts: the core image and the application image. The core image contains all the fundamental functionalities required for the system to operate, such as process management, timer handling, UART communication, and API definitions. The application image, on the other hand, is developed using the APIs defined in the core image and should be capable of being compiled and executed independently. The application image should be downloadable to flash memory and should work alongside the core image without causing any interruptions or conflicts.
For example, consider a scenario where test1.c is already running on the device, and test2.c needs to be downloaded to flash memory. Both test1.c and test2.c should be able to run concurrently without affecting each other. This requires careful management of memory addresses, linking processes, and execution contexts.
Scatter Loading and Symbol Definition Challenges
One of the main challenges in achieving core and application binary separation is managing the memory layout and ensuring that both binaries can coexist without overlapping or interfering with each other. This is typically achieved using scatter loading, which allows for precise control over where different parts of the code and data are placed in memory. However, scatter loading alone is not sufficient. The application binary needs to be aware of the locations of the core functionalities, such as API definitions, to correctly link and execute.
To address this, a symbol definition file (symdef) can be generated during the linking of the core files. This symdef file contains the locations of all the core functionalities and can be used during the linking of the application files. This ensures that the application binary knows where to find the core functionalities it depends on. However, this approach introduces additional complexity, particularly in managing the execution context of multiple applications.
RTOS Task Management and Execution Context
When using an RTOS, the management of multiple applications becomes more complex due to the need to manage tasks and execution contexts. The RTOS typically handles task scheduling, context switching, and resource management. However, when multiple applications are running concurrently, the RTOS must ensure that each application has its own execution context and that there is no interference between them.
The exact details of how tasks are managed vary between different RTOS implementations. Some RTOS implementations may allow for dynamic loading and execution of tasks, while others may require all tasks to be linked together into a single binary. In the latter case, the core and application binaries would need to be linked together, which complicates the separation process.
Scatter Loading and Symbol Definition for Binary Separation
Scatter Loading for Memory Layout Management
Scatter loading is a technique used in ARM-based embedded systems to control the placement of code and data in memory. It allows developers to specify exactly where different parts of the code and data should be located in memory, which is crucial for separating the core and application binaries.
To achieve binary separation, a scatter loading file with two LOAD regions can be created: one for the core binary and one for the application binary. The core binary would contain all the essential functionalities, such as process management, timer handling, UART communication, and API definitions. The application binary would contain the application-specific code that uses these core functionalities.
The scatter loading file would specify the memory addresses for each LOAD region, ensuring that the core and application binaries do not overlap. For example, the core binary could be placed in the lower memory addresses, while the application binary could be placed in the higher memory addresses. This ensures that both binaries can coexist in flash memory without interfering with each other.
Symbol Definition for Core Functionality Access
In addition to scatter loading, a symbol definition file (symdef) is required to ensure that the application binary can access the core functionalities it depends on. The symdef file is generated during the linking of the core files and contains the locations of all the core functionalities, such as API definitions.
When linking the application files, the symdef file is used to ensure that the application binary knows where to find the core functionalities it depends on. This allows the application binary to be compiled and linked independently of the core binary, while still being able to access the core functionalities it needs.
For example, if the core binary defines an API for UART communication, the symdef file would contain the memory address of this API. When linking the application binary, the linker would use the symdef file to resolve the reference to the UART API, ensuring that the application binary can correctly call the API.
Challenges in Symbol Definition and Linking
While scatter loading and symbol definition provide a way to separate the core and application binaries, there are several challenges that need to be addressed. One of the main challenges is ensuring that the symdef file is correctly generated and used during the linking process. If the symdef file is not correctly generated, the application binary may not be able to access the core functionalities it depends on, leading to runtime errors.
Another challenge is managing the memory layout to ensure that the core and application binaries do not overlap. This requires careful planning and testing to ensure that the memory addresses specified in the scatter loading file are correct and that there is no overlap between the core and application binaries.
RTOS Task Management and Execution Context for Multiple Applications
RTOS Task Management for Concurrent Execution
When using an RTOS, the management of multiple applications becomes more complex due to the need to manage tasks and execution contexts. The RTOS typically handles task scheduling, context switching, and resource management. However, when multiple applications are running concurrently, the RTOS must ensure that each application has its own execution context and that there is no interference between them.
In the context of core and application binary separation, the RTOS must ensure that each application binary has its own task and execution context. This allows the applications to run concurrently without interfering with each other. For example, if test1.c and test2.c are both running on the device, the RTOS must ensure that each application has its own task and execution context, allowing them to run independently.
Dynamic Loading and Execution of Tasks
Some RTOS implementations support dynamic loading and execution of tasks, which can simplify the process of separating the core and application binaries. With dynamic loading, the application binary can be loaded into memory and executed independently of the core binary. This allows for greater flexibility in managing multiple applications, as new applications can be loaded and executed without needing to modify the core binary.
However, dynamic loading introduces additional complexity, particularly in managing memory and ensuring that the application binary can access the core functionalities it depends on. The RTOS must ensure that the application binary is correctly loaded into memory and that it can access the core functionalities it needs.
Linking Core and Application Binaries Together
In some cases, the RTOS may require all tasks to be linked together into a single binary. This complicates the process of separating the core and application binaries, as both binaries would need to be linked together. In this case, the core and application binaries would be combined into a single executable image, which would then be loaded into memory and executed by the RTOS.
While this approach simplifies the management of tasks and execution contexts, it reduces the flexibility of being able to update or replace the application binary independently of the core binary. This approach may be suitable for systems where the core and application binaries are tightly coupled and do not need to be updated independently.
RTOS-Specific Considerations
The exact details of how tasks are managed vary between different RTOS implementations. Some RTOS implementations may provide built-in support for separating core and application binaries, while others may require custom solutions. It is important to consult the documentation for the specific RTOS being used to understand how tasks are managed and how core and application binaries can be separated.
In some cases, it may be necessary to open an official support case with the RTOS vendor to discuss the specific requirements and challenges of separating core and application binaries. The RTOS vendor may be able to provide guidance on how to achieve binary separation and ensure that the applications can run concurrently without interfering with each other.
Conclusion
Separating core and application binaries in ARM-based embedded systems is a complex but achievable task. It requires careful management of memory layout, symbol definition, and task execution contexts. Scatter loading and symbol definition files provide a way to control the placement of code and data in memory and ensure that the application binary can access the core functionalities it depends on. However, this approach introduces additional complexity, particularly in managing the execution context of multiple applications.
When using an RTOS, the management of multiple applications becomes even more complex due to the need to manage tasks and execution contexts. Some RTOS implementations support dynamic loading and execution of tasks, which can simplify the process of separating core and application binaries. However, this approach introduces additional complexity in managing memory and ensuring that the application binary can access the core functionalities it needs.
In some cases, the RTOS may require all tasks to be linked together into a single binary, which complicates the process of separating core and application binaries. It is important to consult the documentation for the specific RTOS being used and, if necessary, open an official support case with the RTOS vendor to discuss the specific requirements and challenges of separating core and application binaries.
By carefully managing memory layout, symbol definition, and task execution contexts, it is possible to achieve core and application binary separation in ARM-based embedded systems. This allows for modular development, easier updates, and independent execution of multiple applications, ultimately leading to more flexible and maintainable embedded systems.
