Main Page

This OCE wiki provides information on how to use debug software DMON and real-time operating system OCEOS

DMON software debug tool

DMON monitors what is happening inside a System on Chip (SoC) and helps debug software more efficiently.

SoCs can have multiple CPUs and twenty or more other functional units. DMON's GUI interface allows developers monitor these as a program is running and focus in on one or more of them as desired. DMON provides the usual software debug capabilities such as breakpoints, watchpoints, disassembly, memory and register read/write, and can be used with source level debuggers such as GDB. It accepts commands in its own command language, in TCL, or in Python, and scripts for test or other purposes can be written in any of these. Other features include remote working, data monitoring and display, and user extensions.

At present DMON supports two main CPU families, SPARC and Arm, and more than one hundred different types of functional units, a list that continues to expand.

DMON runs on Windows and Linux systems (including Cygwin). It can connect to the target SoC using a number of different debug links, including Serial (RS232), Ethernet, USB, JTAG and RMAP.

DMON has been developed with help from the Irish Government and the European Space Agency (ESA).

For more information on purchasing DMON, click OCE Sales.

SOC Visualisation

DMON's GUI provides a schematic display of the functional units on the SOC. One or more of these can be selected for detailed examination with register values updated in real-time.

Drill down to register bit level

Register contents may be displayed along with the interpretation of the different bits. These may be updated in real-time depending on the register.

Remote Access

DMON can act as a server with a remote DMON client connected over the Internet. The server is connected directly to the target. The client-server link is secured with SSL.

The user on the client can request that a session be kept alive, then close the client and reconnect to the session later from any computer using the session-id.

The client can load files onto the target directly, or transfer them to the server and load them from there.

Proprietary hardware support

The target system to which DMON is connected may include special purpose devices developed by the user. An example is an SOC implemented on an FPGA, which is likely to contain user defined devices. Using standard DMON commands the user can interact with these devices, and can provide support for them by creating batch files of DMON commands or scripts in TCL or Python. Alternatively a user can add support for a user defined device to DMON itself, extending DMON’s built-in commands and other features.

Target data graphing and storage

DMON allows the user to monitor addresses on the board by periodically sampling them. The user can configure a start condition, a stop condition and a number of addresses to poll, and choose one of several possible display formats. The data can also be stored in a file.

TCL and Python scripting

DMON can process scripts involving its own commands, TCL or Python.

Scripts can be triggered by a change in a target memory location. When the change occurs, the actions in the script are carried out, and typically the trigger is reset.

Software debug support

DMON currently at version 2.1.0.2

 If you have an older version, please contact us at support@ocetechnology.com and we will provide you with the information on how to get the latest version

OCEOS Real-time operating system

OCEOS is a fixed priority pre-emptive real-time operating system for safety critical and other high reliability applications. It complies with European Cooperation for Space Standardization Category B and ISO 26262 standards. Its memory requirement is small with only one system stack and less than 10 kBytes for executable code. It allows data outputs and task starts be set for precise times. It is available initially for applications running on SPARC based hardware. The support of the European Space Agency in developing OCEOS is acknowledged.

OCEOS provides the following facilities:

• Fixed priority pre-emptive scheduling
• Based on Stack Resource Policy - unbounded priority inversion, chained blocking, and deadlocks cannot occur.
• Single stack rather than separate stack for each task
• Small code footprint ( <10 kBytes for scheduling and mutex)
• Mutex, Counting Semaphore, and Data Queue support
• Data output and task start can be set to occur at precise times
• Supports ARM and SPARC V8 LEON2/3/4 single core targets
• Additional support for Cobham-Gaisler GR716 applications
• DMON monitor/debug tool support
• Support & ISVV services available from OCE
• Gold standard customer support package
• Developed to ECSS Category B and ISO 26262 standards
• Developed in cooperation with European Space Agency (ESA)

OCEOS was developed for high reliability aerospace applications. Its small size and efficiency make it ideal for use in embedded systems requiring compactness and high reliability.

Real time software is often written as a set of trap/interrupt handlers and tasks managed by a RTOS. The trap/interrupt handlers start due to anomalous conditions or external happenings. They carry out the immediately necessary processing and may ask the RTOS to start a task to complete the processing. The RTOS then schedules the task for execution based on its priority.

In hard real time systems scheduling must ensure that each task completes no later than its deadline. Being early can also be a problem and OCEOS allows a data output be set for a precise time independently of scheduling. A task also can be scheduled to start at a precise time, but the actual start time may be later depending on task priority.

OCEOS supports up to 255 tasks each with up to 15 start requests pending execution. Each start request can refer to a different object, allowing one task be used to service different objects. Each task has a fixed priority and an equal or higher priority pre-emption threshold. There is no time slicing between tasks of the same priority, such tasks are FIFO scheduled. Once a task starts execution it can only be pre-empted by a task with higher priority than its pre-emption threshold.

OCEOS provides mutexes to protect critical shared code or data, and inter-task communication using counting semaphores and data queues. A system state variable provides a summary of the current state of the system. Error conditions such as missed deadlines are logged and the system state variable updated. When the system state deviates from normal a user defined function is called which can carry out actions such as disabling a task or restarting the system.

Pre-emptions and any traps/interrupts that occur will delay a task’s completion and potentially cause it to miss its deadline. Careful analysis is needed to ensure that task deadlines are always met. OCEOS supports this analysis and records maximum time to completion, minimum inter-start times and other information for each task, allowing relatively simple determination of worst case behavour. Problems such as unbounded priority inversion, chained blocking, and deadlocks cannot occur in OCEOS. The DMON debug monitor tool has been extended to support performance analysis in systems that use OCEOS.

OCEOS does not allow creation of new tasks after scheduling has begun. Virtual memory is not supported. Task priorities are fixed. OCEOS is based on the Stack Resource Policy extension of the Priority Ceiling Protocol [Baker 1991]. OCEOS is provided as a library and is statically linked with an application. Services not needed by an application are omitted by the linker.

For more information on purchasing OCEOS, click OCE Sales.

OCEOS is currently at version 0.3.0.0

If you have an older version, please contact us at support@ocetechnology.com and we will provide you with the information on how to get the latest version