Overview
emApps is a revolutionary software package that brings the familiar flexibility of the smartphone to the world of embedded systems. As an alternative to fixed firmware, emApps introduces an application layer that allows new functionality to be added at any time without touching the validated core system.
To accomplish this, emApps can create apps, which are small programs that can be dynamically loaded and executed in a protected environment known as a sandbox. Each app operates in its own memory space, the sandbox, isolated from the firmware and other apps.
These apps enable the user to add new capabilities, features, or enhancements to embedded devices while keeping firmware small and maintaining system stability and security. They also make it possible for the manufacturer to run tests on such embedded systems using apps.
Since the apps can be dynamically loaded, they do not increase the size of the firmware. Thus, any number of tests can be written and performed, including functionality and performance tests on the embedded system.
App capabilities are defined by an API table in the firmware, giving a firmware developer full control over the exact functionalities available to them. It is even possible to grant different rights (API tables) to different apps running in a system.
Key features
Small app size
Apps created with emApps are very small and start less than 100 bytes. The number of runtime functions is minimized, and only required functions are added to the build, meaning app size is optimized for use on low-memory systems.
High performance
Apps are executed on a virtual CPU specifically designed by SEGGER for this purpose. They are executed by a call to the emApps executor, which implements the instruction set. High code density (often more compact than ARM Thumb-2 or RISC-V code) and efficient instruction scheduling deliver high performance.
Sandboxing
Apps operate in their own memory space, fully sandboxed and isolated from the host program and other apps. Any illegal operations (such as access outside of app memory space) are detected, returning control to the caller. The only connection to the host is via the host provided API.
Easy integration
Integrating emApps into existing firmware is simple and easy. The entire host code (which is integrated in the firmware), consisting of the executor, loader and API service functions, is written in C. The framework integrates smoothly into any existing firmware and supports any RTOS.
Use cases
Apps can be used to dynamically extend a host’s capabilities or to enable customization by manufacturers, OEMs, and end customers. Use cases include test apps, communication (web server, customization), automation, and many more.
Flasher and production systems
Apps can implement flash programming routines, custom test logic, or communication protocols without modifying the device firmware.
Third-party app development
A development kit can be provided to external partners. Apps can be created independently and deployed securely thanks to sandboxing.
Safety-critical environments
Non-essential features — such as GUI control or display logic — can be isolated as apps and excluded from certification scope.
Dynamic product customization
Apps allow feature expansions in the field, supporting new languages, new algorithms, or additional connectivity standards.
How to evaluate emApps
A PC trial version is available for download. It includes various pre-built apps along with their source code. All included apps can be run on a PC as well as on a Flasher, allowing testing in a real embedded system. To create apps for the trial version, an online version of the S32 compiler is available.
How emApps works
emApps consists of a PC development environment with a compiler for creating apps, as well as source code for host integration. Also included is a PC-based executor for running, testing, tracing, and even profiling apps on a desktop.
emApps adds a minimal runtime engine — the executor — into the firmware. This tiny component (~1 KB) acts as a virtual CPU that executes applications and manages their interaction with the embedded system. Apps are statically or dynamically linked and can be downloaded at any point in the device lifecycle.
Each application runs inside a dedicated memory space. The firmware assigns memory to the app only for the duration of execution. Any attempt to access memory outside this space is intercepted by the executor, which immediately returns control to the firmware. System stability and safety remain intact at all times.
The executor and its API together form a complete architecture for application management. Instead of assembling low-level components or configuring memory protection manually, the framework delivers a finished and scalable structure — a ready-to-use engine, instead of a box of parts. While similar goals can be attempted using standard RTOS mechanisms or an MPU, such solutions remain complex to configure and maintain. They provide isolation but not modularity, and they do not enable dynamic loading or field-based updates. emApps solves all of that in one integrated model.
Additional features
Execution model
Multiple apps can run under RTOS control, even in parallel. Apps can be statically or dynamically linked and downloaded at any time.
Target adaptation
With target adaptation, apps gain visibility if native functions are available in firmware or if they need to use S32-coded functions. With this feature, when running an app on different targets, the targets will use the best-performing functions, depending on the platform they are executed on.
API propagation
When an app is loaded with emApps, it receives a list of API functions, that are available on the executor the app is running with. If the app requires API functions, that are not available, it will not start.
The API table needs to be coded into the executor to define the handling of specific function calls.
Below is a code excerpt of an API table:
static const S32_SERVICE_BINDING _aServices[] = {
{ "printf", S32_API_C_printf },
{ "__S32_idiv", S32_API_S32_idiv },
{ "__S32_udiv", S32_API_S32_udiv },
{ "UTIL_MulDiv", S32_API_General_MulDiv },
{ "SYS_GetTime_ms", _SYS_GetTime_ms },
};Resource usage
Memory usage of emApps adds the emApps executor requirements and the size of the app itself including stack size. The stack usage is typically less than 256 bytes.
The apps, which are held and executed in RAM, are very small, starting at less than 100 bytes. There is no upper limit on the complexity these apps can have, hence the maximum program size.
emApps executor size
The emApps executor does not require static RAM.
- Static code (ROM) requirement: ~2.5k bytes;
does not include provided services (API calls) - Dynamic RAM requirement: 102 bytes per S32 context
The software also comes with an assembly optimized executor for Arm cores, which is even smaller.
App size examples
Some example app code sizes:
- Hello World: 44 bytes total runtime image size (including 8 bytes stack)
- Dhrystone: 12548 bytes total runtime image size (including 512 bytes stack)
This means emApps is suitable even for compact MCUs with just 64 KB of flash memory.
Performance and code density
The virtual instruction set is highly efficient. Fewer instructions are required, and execution remains close to native speed — even for compute-intensive tasks. Overall app performance depends on the speed of the CPU the executor is running on and on the instructions used.
The emApps executor’s performance translates into 18 host-system instructions (or clocks) per virtual S32 instruction (CPI). Depending on the instructions calling internal operations, firmware operations, or hardware (which is often the case for CPU or compute-intense code), the CPI ratio can further improve. Finally, the S32 instruction-code density is usually better than the host system's code density, which further improves performance.
Licensing
The software is available under various embedded software license models and can be delivered as source code. All commercial licenses are based on a one-time payment, are royalty-free, and include six months of updates and support from SEGGER’s Embedded Experts.
There are no subscription fees, ensuring predictable and fixed costs over the entire product lifetime.
For non-commercial use, evaluation, and educational purposes, the software is provided under SEGGER’s Friendly License.
FAQ
What is the main benefit of emApps?
emApps transforms static firmware into a dynamic, extensible application platform.
Does it require specific hardware?
No. emApps runs on small and resource-limited microcontrollers — starting at 64 KB of flash memory.
How are apps added?
Apps can be downloaded and executed without modifying the existing firmware.
Can multiple apps run simultaneously?
Yes. Multiple apps can be executed simultaneously in a system that has multiple CPU cores or is RTOS based, and they can have multiple entry points and serve as libraries, similar to DLLs. Multiple apps operate in parallel and remain isolated.
How is the emApps architecture fundamentally different from a container, and what makes it viable on a microcontroller where a technology like Docker could never run?
It’s fundamentally about efficiency. A container like Docker requires a full operating system and massive resources. emApps is built for resource-constrained microcontrollers. Our executor engine is incredibly small—around 1 KB. It provides the modularity and virtualization of a container, but in a footprint that can actually run on the smallest of devices.
For a hard real-time system controlling a motor, how can you guarantee deterministic performance?
We would recommend keeping your hard real-time loops, like a motor controller, in your core, native firmware. emApps is ideal for separating your non-critical tasks or an analytics app — from that core logic.
Does emApps have a proven track record?
Absolutely! SEGGER has been using them in our J-Link and Flasher product lines for years.
Can emApps be used for applications other than embedded systems?
Sure. Host systems can range from small, microcontroller-based embedded systems to full desktop applications.
Can my customers write their own apps for my product?
Yes, if you want to open up the system for your customers.
Can I make sure only authentic apps can execute in my product?
Yes, if that is what you want, you can do it. All it takes is a signature check.
Get in touch with us
Have questions or need assistance? Our Embedded Experts are here to help!
Reach out to us for:
- Licensing quotes
- Technical inquiries
- Project support