embOS-MPU offers memory protection on top of the well-proven real-time operating system embOS. It significantly enhances both stability and safety of your embedded applications and thereby also simplifies any certification process. Due to a fully compatible API, existing embOS applications may be adapted to embOS-MPU with minimal effort.

embOS-MPU can be used in any application from battery-powered, single chip products to systems demanding ultra-fast response, flexibility and multiple tasks. Typical fields include, but are not limited to medical equipment, automation, avionics, and further safety-critical applications.


  • Comprehensive memory protection
  • Suitable for any safety-critical application
  • Available for any microcontroller containing a hardware memory protection unit or memory management unit
  • Simple and straightforward runtime configuration
  • Easy to integrate in both new and existing products
  • Supports device drivers for full control of peripheral accesses
  • MISRA-C:2012 compliant

pdf Documentation download

Subscribe to embOS software notification


HTML Release Notes

Basic concepts of embOS-MPU

What is memory protection?

Memory protection is a prevalent mechanism to control memory access rights and is part of most modern processor architectures and operating systems. The main purpose of memory protection is to avert specific tasks from accessing memory that has not been allocated to them, thus preventing possible bugs or even malware contained in one task from affecting the entire system.

In order to achieve this, application tasks that could possibly affect other tasks or the OS itself must be restricted from accessing the whole memory, special function registers and the OS’s control structures. For example, tasks that execute third-party code may be considered unsafe and should be restricted accordingly. Such application tasks must not run on the same privilege state as the OS, which runs in fully privileged mode and has access to all memory, peripheral and CPU features. Instead, these tasks must run in unprivileged state and have restricted access to specific memory locations only.

What is embOS-MPU?

embOS-MPU uses the hardware’s memory protection unit as well as additional software mechanisms implemented with embOS-MPU to prevent one task from affecting the entirety of the system. This guarantees that even in case a bug occurs in one task, all other tasks and the operating system itself continue execution.

With embOS-MPU, all privileged tasks have full access to the whole memory. An unprivileged task, however, has specific access permissions to each distinct memory region. In order to access peripherals, additional memory locations and OS control structures, device drivers as well as specific embOS API may be called from within an unpriviliged task.

An application based on embOS-MPU therefore consists of two distinct parts:

  • The first part runs in privileged state: it initializes the MPU settings and includes the device drivers.
    This part contains critical code and must be verified for full reliability.
  • The second part is the application itself, which does not need to or in some cases even cannot be verified for full reliability.
    As it runs in unprivileged state, this part cannot affect the complete system.

Working with unprivileged tasks

By default, a newly created unprivileged task has read access to RAM and ROM, but may execute code in ROM only, while write access is restricted to its own task stack. In order to access peripherals, additional memory locations and OS control structures, device drivers as well as specific embOS API may be called from within an unpriviliged task.
Access to peripherals

In a default configuration, an unprivileged task has no access to any peripheral. A specific device driver is necessary to access peripherals from within such task, e.g. for using a UART, SPI, or port pins. Device drivers can be provided by SEGGER, but in most cases will be implemented by the user.

With embOS-MPU, a device driver consists of two parts: one part runs in privileged state and the other part runs in unprivileged state. The actual peripheral access is performed in the privileged part only, and embOS-MPU ensures that there is only one explicit and safe way to switch from the unprivileged part to the privileged one.

Access to further memory regions

An unprivileged task may be granted access to additional memory regions, e.g. when a task needs to write LCD data to a framebuffer in RAM and a device driver is deemed inefficient for this purpose. Access permissions are fully configurable in regards to read access, write access and code execution.

Access to OS objects

An unprivileged task has no direct or indirect write access to embOS objects. However, indirect write access to these objects via embOS-MPU API may be granted for each individual object. This requires all objects to be created in privileged state.

MPU violation management

In case an unprivileged task violates its access restrictions or otherwise triggers a fault exception, it is automatically suspended and an optional user callback function is executed to inform the application about this. This callback may also perform further actions in regards to that task, e.g. restarting it or even terminating it completely.


Supported cores and compiler

The following list gives an overview on cores and compilers which are currently supported by embOS-MPU. We are continously adding new targets. However, if your device is not in the list, we are able to port the system to your target, ensuring high quality and extensive testing. Please feel free to contact us at info@segger.com.

Core Compiler / IDE embOS
 Cortex-M Segger Embedded Studio embOS-MPU Cortex-M ES

Trial version

Download an embOS-MPU trial version and get your first application running within a few minutes!.

embOS-MPU API functions

The table below lists the available embOS-MPU API functions.

 Function Description
OS_MPU_Enable() Enables embOS-MPU.
OS_MPU_EnableEx() Enables embOS-MPU and sets the MPU API list.
OS_MPU_ConfigMem() Configures RAM/ROM and OS regions.
OS_MPU_SetAllowedObjects() Sets a list of allowed OS objects.
OS_MPU_AddRegion() Adds an additonal memory region.
OS_MPU_SetErrorCallback() Sets the error callback function.
OS_MPU_SwitchToUnprivState() Switches a task to unprivileged state.
OS_MPU_SetDeviceDriverList() Sets the device driver list.
OS_MPU_CallDeviceDriver() Calls a device driver.
OS_MPU_GetThreadState() Returns the privilege state.
OS_MPU_ExtendTaskContext() Extends the task context for MPU registers.

emlib-crc.html Detailed descriptions of all functions can be found in the embOS-MPU documentation.

Example application

The following example shows the ease of use of embOS-MPU. Furhermore, it provides a good starting point for your application.

#include "RTOS.h"
#include "BSP.h"
#include <stdio.h>

*       Static data

// Task-control-blocks.
// Task stacks. With Cortex-M MPU, stack for unprivileged tasks
// requires alignment.
static OS_STACKPTR int StackHP[128];
static OS_STACKPTR int StackLP[128] __attribute__ ((aligned (512)));
// Linker symbols to get section addresses. embOS-MPU needs to know
// where RAM, ROM and the OS section are located.
extern unsigned int __FLASH_segment_start__;
extern unsigned int __FLASH_segment_size__;
extern unsigned int __RAM_segment_start__;
extern unsigned int __RAM_segment_size__;
extern unsigned int __os_start__;
extern unsigned int __os_size__;
// User callback function which is called when an unprivileged
// task violates its access permissions.
static void _ErrorCallback(OS_TASK* pTask, OS_MPU_ERRORCODE ErrorCode) {
  printf("%s has been stopped due to error %d\n", pTask->Name, ErrorCode);
  OS_TerminateTask(pTask);  // Terminate the violating task

*       Local functions

static void _HPTask(void) {
  while (1) {

static void _LPTask(void) {
  OS_MPU_SwitchToUnprivState();  // Switch task to unprivileged state
  while (1) {

*       Global functions

int main(void) {
  OS_IncDI();                      /* Initially disable interrupts  */
  OS_InitKern();                   /* Initialize OS                 */
  OS_InitHW();                     /* Initialize Hardware for OS    */
  BSP_Init();                      /* Initialize LED ports          */
  // Setup embOS-MPU:
  // 1. Configure memory information, must be done before first task is created.
  // 2. Set optional error callback function.
  // 3. Enable embOS MPU support.
  OS_MPU_ConfigMem((OS_U32)&__FLASH_segment_start__, (OS_U32)&__FLASH_segment_size__,
                   (OS_U32)&__RAM_segment_start__,   (OS_U32)&__RAM_segment_size__,
                   (OS_U32)&__os_start__,            (OS_U32)&__os_size__);
  /* You need to create at least one task before calling OS_Start() */
  OS_CREATETASK(&TCBHP, "HP Task", _HPTask, 100, StackHP);
  OS_CREATETASK(&TCBLP, "LP Task", _LPTask,  50, StackLP);
  OS_Start();                      /* Start multitasking            */
  return 0;

SEGGER SystemView

Real-time analysis and visualization

SEGGER SystemView is a real-time recording and visualization tool that exposes the true runtime behavior of an application, going far deeper than the insight provided by debuggers. This is particularly effective when developing and working with complex systems comprising multiple threads and interrupts: SystemView can ensure a system performs as designed, can track down inefficiencies, and show unintended interactions and resource conflicts.


  • Minimal intrusive.
  • Free tool. No license costs, no hidden fees.
  • RTOS task, resource, and API tracing.
  • Interrupt tracing for bare metal systems without an RTOS.
  • Continuous real-time recording and live analysis with J-Link and SEGGER RTT technology.
  • Live analysis of captured data — view responses to stimuli in real time without stopping the target!
  • embOS, embOS/IP, and FreeRTOS API call tracing as standard.
  • Can be adapted to other RTOS using a fully documented API.
  • Works on any CPU.
Download SEGGER SystemView package for Windows, Mac OS X and Linux
SEGGER SystemView documentation
Subscribe to SystemView software notification


Analysing a system with SystemView

SystemView can record data from the target system while it is running. The recorded data is analyzed and the system behavior is visualized in different views.

All system information is sent by the application and is part of the recording. The information is shown in the window on the top right and includes the application name, the underlying OS, the target device and the timing information. Additional information about task switches and interrupt frequency provide a quick overview of the system.

With the Timeline and the Events window the whole system execution can be visually analyzed.

The Events window lists all SystemView events which were recorded from the system and displays information about the exact timestamp when the event was generated, in which task or interrupt context it happened, which event it is, and the details of the event. The type of events to be displayed can be filtered to show only events of interest.

The Timeline displays the interrupt and task activity, as well as scheduler activity and idle over the system time. Scrolling through the events and zooming in on the timeline provide an exact view on how the contexts are connected:

  • How often do interrupts occur.
  • Which interrupt starts which task.
  • When are tasks or interrupts interrupted.
  • When does the scheduler trigger a task switch.
  • How long does it take for a task to run when it becomes ready.
  • How long does an interrupt run.

The Contexts window provides run-time information about tasks and interrupts. For each item the frequency, run time information and CPU load is shown. This information can be used for profiling, to see whether the system runs evenly or not, and to get an overview where the CPU time is spent.

The CPU Load window displays the used CPU time by context over a time period. This enables analysis of how much CPU time is used when the system is active or idle and can provide an indicator for where the system might be inefficient, i.e. when interrupts happen too often or simple computations take too long.


What is SEGGER SystemView?

SystemView consists of two parts: The visualization application SystemViewer, which is available for Windows, Mac OS X and Linux, and some target-side code, collecting information on the target system.

Actually, there is a third part: J-Link and the RTT technology that enables this wonderful system with all of its capabilities. Although J-Link can be eliminated, it’s best experienced with a J-Link.

The SystemViewer host application enables analysis and profiling of the behavior of an embedded system. It records the monitor data which is generated in the embedded system and visualizes the information in different windows. The recording can be saved to a file for analysis at a later time or for documentation of the system.

The monitor data is recorded via the debug interface, meaning that no additional hardware (especially no extra pins) is required to use SystemView. It can be used on any system that offers debug access.

With a SEGGER J-Link and its Real Time Transfer (RTT) technology SystemViewer can continuously record data, and analyze and visualize it in real time.

SystemView makes it possible to analyze which interrupts, tasks and software timers have executed, how often, when exactly and how much time they have used. It sheds light on what exactly happened in which order, which interrupt has triggered which task switch, which interrupt and task has called which API function of the underlying RTOS.

Cycle-accurate profiling can be performed and even user functionality can be timed.

SystemView should be used to verify that the embedded system behaves as expected and can be used to find problems and inefficiencies, such as superfluous and spurious interrupts, and unexpected task changes. It can be used with any (RT)OS which is instrumented to call SystemView event functions, but also in systems without an instrumented RTOS or without any RTOS at all, to analyze interrupt execution and to time user functionality like time-critical subroutines.

How does it work?

On the target side a small software module, containing SystemView and RTT, needs to be included.

The SystemView module collects and formats the monitor data and passes it to RTT. The RTT module stores the data in the target buffer, which enables continuous recording with a J-Link on supported systems, as well as single-shot recording on any system.

The target system calls SystemView functions in certain situations, such as interrupt start and interrupt end, to monitor events. SystemView stores these events together with a configurable, high-accuracy timestamp, in the RTT target buffer. Timestamps can be as accurate as 1 CPU cycle, which equates to 5 ns on a 200 MHz CPU.

What resources are required on the target side?

The combined ROM size of RTT and the SYSVIEW modules is less than 2 KByte. For typical systems, about 600 bytes of RAM are sufficient for continuous recording with J-Link. For system-triggered recording the buffer size is determined by the time to be recorded and the amount of events. No other hardware is required. The CPU needs less than 1 us for typical events (based on a 200 MHz Cortex-M4 CPU), which results in less than 1% overhead in a system with 10,000 events per second. Since the debug interface (JTAG, SWD, FINE, …) is used to transfer the data, no additional pins are required.

On which CPUs can SystemView be used?

SystemView can be used on any CPU. Continuous real-time recording can be done on any system supported by J-Link RTT technology. RTT requires the ability to reading memory via the debug interface during program execution. This especially includes ARM Cortex-M0, M0+, M1, M3, M4 and M7 processors as well as all Renesas RX devices. On systems which are not supported by the RTT technology the buffer content can be read manually when the system is halted, which enables single-shot recording until the buffer is filled and post-mortem analysis to capture the latest recorded data. Single-shot and post-mortem recording can be triggered by the system to be able to control when a recording starts and stops.

How much work is it to add it to a target system?

Not very much. A small number of files need to be added to the make file or project. If the operating system supports SystemSiew, then only one function needs to be called. In a system without RTOS or non-instrumented RTOS, 2 lines of code need to be added to every interrupt function which should be monitored.
That’s all and should not take more than a few minutes.


Modes of operation

Continuous recording

With a J-Link debug probe and the SEGGER Real Time Transfer technology (RTT), SystemViewer can continuously record target execution in real time, while the target is running. This enables analysis of the system behaviour over a longer period of time without requiring a large target memory buffer.

Read more…

Single-Shot recording

When the target device does not support RTT or when no J-Link is used, SystemView can still record data into its buffer until it is filled. Single-shot recording offers insight to the startup sequence or event-triggered activity in any system for a decent amount of time.

Read more…

Post-Mortem Mode

Post-mortem analysis is similar to single-shot recording, with one difference: SystemView events are continuously recorded. When the target buffer is filled older events are overwritten and reading the buffer provides the latest recorded events. Post-mortem analysis can provide information of long-time system tests and helps analysing system crashes.

Read more…


Supported (RT)OSes

To use SystemView the SystemView target module has to be included in the target application and the OS needs to be instrumented. Currently embOS and FreeRTOS can be used with SystemView out-of-the-box. SystemView can also be used with a non-instrumented OS or without any OS at all.

For a detailed description of the target implementation, please refer to the SystemView User Manual UM08027.

Configuring embOS for SystemView

SEGGER embOS (V4.12a and later) can generate trace events for SystemView and other recording implementations when profiling is enabled. Profiling is enabled in the OS_LIBMODE_SP, OS_LIBMODE_DP and OS_LIBMODE_DT embOS library configurations (For detailed information refer to the embOS User Manual UM01001).

In addition to the SystemView and RTT core module, SEGGER_SYSVIEW_Config_embOS.c needs to be included in the application. This file allows configuration to fit the target system, like defines for the application name, the target device and the target core frequency. It initializes the SystemView module and configures embOS to send trace events to SystemView.

At the start of the application, at main, after the target is initialized, SEGGER_SYSVIEW_Conf() has to be called to enable SystemView.

Now, when the application is running, SystemViewer can connect to the target and start recording events. All task, interrupt, and OS Scheduler activity, as well as embOS API calls are recorded when SystemViewer is connected or SEGGER_SYSVIEW_Start() has been called.

For a detailed description on how to configure embOS for SystemView, please refer to the SystemView User Manual.

Configuring FreeRTOS for SystemView

FreeRTOS can also generate trace events for SystemView and offers basic but useful analysis without modification.

For more detailed analysis, like Scheduler activity and interrupts, the FreeRTOS source and the used port have to be slightly modified.

For a detailed description on how to configure FreeRTOS for SystemView, please refer to the SystemView User Manual.

Using SystemView without an OS

SystemView can be used without any instrumented OS at all, to record interrupt activity and user events.

Integrating SystemView in such an application is as simple as adding three lines of code.

For a detailed description on how to configure the application and how to record interrupts, please refer to the SystemView User Manual.


FAQs & Troubleshooting

Q: Can I use SystemViewer while I am debugging my application?
A: Yes. SystemViewer can run in parallel to a debugger and do continuous recording. To make sure data can be read fast enough, configure the debugger connection to a high interface speed (>= 4 MHz).
Can I do continuous recording without a J-Link?
A: No. Continuous recording requires the J-Link Real Time Transfer (RTT) technology to automatically read the data from the target. One-time recording can be done with any debug probe.
Can I use SystemViewer with my J-Link LITE or J-Link OB?
A: Yes. SystemViewer can in general be used with any J-Link.
J-Link LITE and J-Link OB are limited in the debug interface speed, which can lead to overflow events when the RTT buffer cannot be read fast enough and the system creates too many events.
To get a full-featured J-Link, have a look at the purchase options.
Can I use SystemViewer with my old J-Link?
A: Yes. SystemViewer can in general be used with any J-Link if the J-Link supports the target core.
Older J-Links (V8 and older) might have limited RTT capability, which can lead to overflow events when the RTT buffer cannot be read fast enough and the system creates too many events.
To trade-in or upgrade your J-Link, have a look at our purchase options.
Can I do continuous recording on Cortex-A, Cortex-R or ARM7, ARM9?
A: No. RTT requires memory access on the target while the target is running. If you have one of these devices, only one-time recording can be done.
I don’t use embOS or FreeRTOS, can I still use SystemView for my application?
A: Yes. SystemView can be used with any (RT)OS.
For Task and OS execution recording your OS might have options to hook up trace/profiling instrumentation modules where you can add SystemView, otherwise the OS has to be instrumented to be able to do so. In case of doubt get in contact with your OS vendor.
If instrumenting the OS is not possible you can still use SystemView to record interrupt activity and user events.
I don’t use any OS at all. Should I still use SystemView?
A: Yes. Even without any OS SystemView can be used to record interrupt activity to verify interrupts occur as expected and to record user events which can be used to measure module execution times.
I get overflow events when continuously recording. How can I prevent this?
A: Overflow events occur when the SystemVIew RTT buffer is full.
This can happen for following reasons:

  • J-Link is kept busy by a debugger and cannot read the data fast enough.
  • The target interface speed is too low to read the data fast enough.
  • The application generates too many events to fit into the buffer.

To prevent this:

  • Minimize the interactions of the debugger with J-Link while the target is running. (i.e. disable live watches)
  • Select a higher interface speed in all instances connected to J-Link. (i.e. The debugger and SystemViewer)
  • Choose a larger buffer for SystemView. (1 – 4 kByte)
  • Run SystemViewer stand-alone without a debugger.
Q: My application crashes when I connect SystemViewer. What might be wrong?
A: Make sure ~200 Bytes of stack are available for SystemView in every context (Task, Interrupt, Scheduler) which can create SystemView events.
I cannot start recording in SystemViewer. What might be wrong?
A: Possible reasons are:

  • J-Link or target is not connected: Make sure all connections are okay.
  • The target is not running: Make sure the target is running, otherwise connection might fail or the RTT Control Block can not be found.
  • The SystemView module is not configured: Make sure the SystemView module is included in your application and SEGGER_SYSVIEW_Conf() is called at the start of the application.
  • The J-Link Software is out-of-date: Make sure you have the latest J-Link Software and Documentation Package installed.
SystemViewer cannot find the RTT Control Block, how can I configure it?
A: Auto-detection of the RTT Control Block can only be done in a known RAM address range after it is initialized. Make sure the application startup has ran when starting to record. If the RTT Control Block is outside the known range for the selected device, either select ‘Address’ and enter the exact address of the RTT Control Block or select ‘Address Range’ and enter an address range in which the RTT Control Block will be.
Do I have to select a Target Device to start recording?
A: Yes. J-Link needs to now which target device is connected. The drop-down lists the most recently used devices. To select another device simply enter its name. A list of supported devices can be found here.
My question is not listed above. Where can I get more information?
A: For more information and help please ask your question in the SEGGER Forum.

SEGGER J-Links are the most widely used line of debug probes available today. They’ve proven their worth for more than 10 years with over 400,000 units sold, including OEM versions and on-board solutions. This popularity stems from the unparalleled performance, extensive feature set, large number of supported CPUs, and compatibility with all popular development environments.

Following strict, yet efficient coding and documentation standards, we created and developed a feature-rich, high-performance family of middleware with a very small footprint and outstanding documentation.

Firmware for ST-LINK on-board

SEGGER offers a firmware upgrading the ST-LINK on-board on the Nucleo and Discovery Boards. This firmware makes the ST-LINK on-board compatible to J-Link OB, allowing users to take advantage of most J-Link features like the ultra fast flash download and debugging speed or the free-to-use GDBServer.


  • Fully compatible to and same features as J-Link OB
  • Wide range of IDEs are supported
  • Virtual COM port (VCOM) support


SEGGER created a firmware which runs on the ST-LINK on-board, making it J-Link compatible. In order to make use of this firmware, the following Terms Of Use must be accepted:

  • The firmware is only to be used with ST target devices. Using it with other devices is prohibited and illegal.
  • The firmware is for use with evaluation boards only. It is not for use with custom hardware.
  • The firmware may only be used for development and/or evaluation purposes. It may not be used for production purposes.
  • The firmware is made available without any warranty and without support.

If there is any doubt if a certain use may be considered within the foregoing scope it is strongly recommended to consult SEGGER prior to use.
When starting a debug session, the following license dialog shows up which must be accepted in order to be able to work with ST-LINK on-board:


The firmware making the ST-LINK on-board J-Link compatible has some limitations in contrast to an original, industry leading SEGGER J-Link:

  • May be used with ARM based ST devices only
  • Only debugging on evaluation boards is allowed. Debugging on custom hardware is not supported and not allowed
  • No production flash programming support
  • Unlimited breakpoints in flash available for evaluation only
  • No support is given

By using an original SEGGER J-Link PROJ-Link ULTRA+ or J-Link PLUS, all these limitations will be gone. Learn more about J-Link.

Compatible Evaluation Boards

The following eval boards have been tested with the J-Link OB firmware and are known to be working. Other eval board may work as well but are not guaranteed to do so. In case of doubt, please consult SEGGER.

  • NUCLEO-F030R8
  • NUCLEO-F031K6
  • NUCLEO-F042K6
  • NUCLEO-F302R8
  • NUCLEO-F303K8
  • NUCLEO-F334R8
  • NUCLEO-L031K6
  • NUCLEO-L053R8
  • STM32F0308-DISCO
  • STM32F3348-DISCO (32F3348DISCOVERY)
  • STM32F411E-DISCO
  • STM32F429I-DISCO
  • STM32F469I-DISCO
  • STM32F746G-DISCO
  • STM32L0538-DISCO (32L0538DISCOVERY)
  • STM32L100C-DISCO
  • STM32L476-DISCO

Getting started with ST-LINK on-board

In order to get started with ST-LINK on-board and upgrade it to a J-Link OB, just a few steps are necessary:

  • Make sure that the ST-LINK USB drivers are installed: Download
  • Make sure that the J-Link software package V5.12b or later is installed: Download
  • Download the SEGGER STLinkReflash utility: Download
  • Start the STLinkReflash utility
  • Agree to the license terms

  • Connect ST-LINK on-board to PC
  • Select “Upgrade to J-Link”
  • Wait for operation to complete

  • Quit the STLinkReflash utility


Restore ST-LINK on-board firmware

If, for whatever reason, the original ST-LINK firmware shall be restored and the ST-LINK on-board is already running the J-Link firmware, this can be achieved via the STLinkReflash utility:

  • Start the STLinkReflash utility
  • Agree to the license terms

  • Connect ST-LINK on-board to PC
  • Select “Restore ST-Link”
  • Wait for operation to complete

  • Quit the STLinkReflash utility

Our auxiliary converters can be configured and observed through a flexible webserver application running on keil rtx. The user interfaces are created dynamically from the target. All firmwares can be updated via the browser and no further or special software is neccessary for maintenance and diagnosis.

The controller hardware consists of multiple embedded systems that are connected by a proprietary CAN protocol. The STM32 controllers may also have additional external FPGAs for high performance control alogrithms and data analysis. The ARM arhitecture is a reliable and proven hardware basis and allows fast and reliable software solutions for complex and flexible tasks.

Elite Developers – Show us your Cool Apps!

Join our club of elite developers by showcasing your app and enter to win $2,000 in Embarcadero Credits!


How does it work?Cool_App_Contest_Logo_and_Graphic

1) Submit a title for your cool app

2) Provide a description for your submission

3) Share your short video URL or request a recording (Date & Time)

4) MVPs & Embarcadero Evangelists vote

5) Winner each month – $2,000 toward any of our products

This contest awards prizes and showcases cool applications built using Embarcadero’s RAD Studio, Delphi and C++Builder. We are looking for cool applications across all industries including personal use, using any type of application you can build with our products. Your cool app can use VCL, FireMonkey, DataSnap, EMS, FireDAC, InterBase and any other components, libraries, services, sites, infrastructures, APIs, devices and other capabilities.

As part of your contest entry, we want you to create a 5 minute video (or please request a date/time with David I and/or Jim McKeeth for a recording session and we’ll help you) that shows your cool code, UI, technology, component use, architecture, algorithms, data structures, unique solution to a problem, business solution, game, world changing idea and any other app that you want to show off.

The contest will be an ongoing monthly contest so there is no specific deadline for submission. We will be giving each monthly winner a $2000 coupon that can be used towards the purchase of Embarcadero products from our shop site  (starting May 1, 2016), while the contest is running.  In addition, we will highlight the winning submission on our YouTube channel along with other submissions so that your fellow Embarcadero community members will be able to admire your work.

You only need to submit your cool app once. Embarcadero developer relations team, Embarcadero software consultants and Embarcadero MVPs will vote each month to determine the monthly winner. Embarcadero employees are not eligible to enter the contest. Embarcadero MVPs are allowed to enter the contest but will not be allowed to vote for their own entry.

For examples of short application videos, check out the Digifort IP Surveillance System video by Eric Bonihla (Digifort) and the Visualizing Mathematical Functions video by Anders Ohlsson (Embarcadero MVP).

You can use any screen recording software to create your 5 minute Cool App Contest video. At Embarcadero we use Camtasia for Windows and Camtasia for Mac by TechSmith (they have trial versions available if you are interested). TechSmith has tutorials available for Camtasia for Windows and Camtasia for Mac. Your video should be recorded and rendered at or near 1920×1080 resolution. Please make sure that your IDE editor’s text font size is set to 12 point or larger (David I likes to use Lucida Console 14 point).

If you intend to enter, please use the submission form (short survey) to tell us about your Embarcadero Cool App. Bookmark this survey page URL and start your cool app entry (or entries) today and then update your submission(s) when you have completed your video or want to request a date/time with us for a recording session.

The submission (Survey Monkey) form can be found at https://www.surveymonkey.com/r/V99D7YR

We like all types of applications – desktop, mobile, server, cloud, personal, professional, industrial, etc.  There is no limit to the type of application, except that it must be a cool app. The app does not have to be a for sale app. The app does not have to be open source based.  The app can be used inside a company or delivered to specific users.  The app just has to be wonderful. There are no other rules except what is in the email, what is in the submission/survey form header and the final question that has you put your name, email and company to give us permission to publicly showcase your app (whether it wins a monthly prize or not) and to use some or all of the textual information and other information you provide as part of us showing your cool app video to the world.

We look forward to seeing all of the cool apps our Embarcadero community members have built!

If you have any questions or need additional information, please contact me.

David Intersimone “David I”


Frequently Asked Questions about the Cool Apps Contest

Q: Does the video have to be five minutes in length?
A: We hope your submitted video will be approximately 5 minutes in length. But, the video can be a little shorter or a little longer if you need to show the coolness of the app. Is there a video submission that might be too short, say 2 minutes in length? The video can be shorter, as long as you can show the coolness of the app in action, the UI, some source code or architecture and anything else that will help the “judges” evaluate the cool app submission.

Q: Do I maintain ownership of the 5 minute video? I would have no issue granting permission for the video to be used as that becomes the positive marketing from your side.
A: You own the video and the app. The last item on the submission form asks you to give your name, email address and company (or self) as confirmation that you want your cool app entered into the Embarcadero Cool Apps Contest and that we can use the information and video you provide as part of the marketing of our Cool Apps Contest. We will put the video and information on our site and also our YouTube channel.

Q: If I submit am app once and then later make significant update to it with which I extend my apps features can I update my submission to reflect the latest changes?
A: You can always update your submission whether it has won a monthly award entry or not. We will create a landing page and YouTube playlist for the videos and can update videos as you do, or change the link. Just let us know.

Q: In your article you state that it is necessary to submit the cool app only once and the judges will vote for best app every month. Can one app can be nominated as best several times?
A: We will pick a cool app each month from the complete set of submissions. You do not have to re-submit the same cool app. One specific Cool App can only win once. A Cool App submitted can win once and only once.

Q: Is this strictly for mobile apps, or are groundbreaking desktop apps also eligible?
A: We like all types of applications – desktop, mobile, server, cloud, personal, professional, industrial, etc. There is no limit to the type of application, except that it must be a cool app. The app does not have to be a for sale app. The app does not have to be open source based. The app can be used inside a company or delivered to specific users. The app just has to be cool.

Q: Since this appears to be a monthly contest, when is the cutoff date for the first month? End of April?
A: We will take submissions over time. The “judges” will take a look at all submissions (except for past winners) at the beginning of each month (for April, this means early May). We will choose one winner each month from the complete list of submissions. Once a cool app video has won a monthly prize, it will not be considered for any additional month’s awards.