Please enable JavaScript to view this site.

winIDEA Help

Version: 9.21.253

Multi-Memory Space Session Overview

Technologies are constantly evolving, and so is winIDEA to match the needs of embedded software engineers. That’s why we’ve developed the Multi-Memory Space concept or MMS for short, which is a new way of configuring the Debug Session.


The introduction of complex SoCs with many cores enabling powerful processing expanded the possibilities of embedded design. Embedded software is not limited to a single application running on a core. It can also include a hypervisor that creates and runs multiple virtual machines with operating systems which in turn each run multiple embedded applications.


To begin on-chip debugging, we need to transfer our developed application to the target system-on-chip, or SoC, by downloading Program Files to the internal flash of the SoC. Depending on the complexity of the embedded software and the target SoC, the debugging use cases can span from a single application running on a single-core to one or more applications running on multiple cores. If you have multiple applications running on the SoC, they all have separate elf files.


In the winIDEA, you can configure each Application separately, and then switch Process debugging contexts on-the-fly.

Each software component is an Application running in its own Memory Space. We call this a Process, which gets assigned its distinctive ID.



Introduction to winIDEA 9.21






Memory Space





Application is compiled and linked with a Compiler from source files. The result is one or more executables, which is a binary representation of your program in terms of code and data (ELF file). To run the Application it has to be downloaded via debugger BlueBox into a designated Memory Space where it executes. Multiple instances of an Application can be active in a separate Memory Spaces.

On a simple system only a single instance of one Application will execute. In a rich OS environment, many applications can run simultaneously, even multiple instances of the same Application.

Application configuration contains Symbol File(s), Operating System (optional) and other miscellaneous settings (e.g. Stack Usage). Each Application has its Symbol file that enables debugging activities, such as setting a breakpoint or stepping through the code.



Memory Space

Memory Space is assigned to a core or an SMP group. Within it, virtual (core) memory accesses are separated from other Memory Spaces by hardware logic. In each one Application is executing.

If a core supports multiple protection levels, a Memory Space has to be specified for every protection level in which an Application will be executing.




Process is when an Application is loaded to a designated Memory Space and is prepared to be executed. Process gets its own ID which has two parts; one is the Application name and second one is the Memory Space name.

Example: Application HelloWorld running inside MCU Memory Space creates a Process with an ID HelloWorld/MCU/. Application instances of HelloWorld running on any *Memory Space creates a Process with an ID HelloWorld/*.



Program Files

Files (e.g. Motorola S, Binary, ELF files) whose content will be stored into the target system at a session start. Content of the program files is transferred to target RAM or memory mapped Flash.



Symbol Files

Files whose symbolic debug information is used by winIDEA to provide high level debug functionality. Usually this is a single ELF file.


Copyright © 2024 TASKING