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.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

OCEOS Real-time operating system

OCEOS is a real-time pre-emptive fixed priority operating system that can be used in applications that require European Cooperation for Space Standardization Category B or ISO 26262 standards. It has a small memory footprint (<10 kBytes), requires only one system stack rather than a stack for each task, and provides support for precisely timed data outputs independent of task scheduling. 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
• High precision timed actions (data output and task start)
• Supports SPARC V8 LEON2/3/4 single core targets initially
• Ideal 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, but being early can also be a problem. OCEOS provides a timed output service that 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 254 tasks with up to 15 current execution instances of each task, allowing one task service multiple units of the same type. Each task has a fixed priority and more than one task may have the same priority. Tasks of the same priority are FIFO scheduled, there is no time slicing between tasks in OCEOS. In OCEOS a pre-emption threshold higher than the task’s priority can be set for a task so that once it starts execution it can only be pre-empted by a task with higher priority than this threshold.

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 allows relatively simple determination of worst case behaviour. Problems such as unbounded priority inversion, chained blocking, and deadlocks cannot occur in OCEOS.

OCEOS provides mutexes to protect critical shared code or data, and inter-task communication using semaphores and 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. If the system state is not normal actions such as disabling a task or resetting the system may be taken.

OCEOS does not allow dynamic creation of tasks at run time. 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.1.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