| RTOS Debug Support |
If kernel awareness for an RTOS (Real-time Operating System) is added to HiTOP, the following features are brought in
However, the additional functionality also depends on the RTOS in question and the functionality of the debug system.
Display ObjectsThis functionality gives you information about the objects of the RTOS and their attributes. Tasks are a good example for objects, because they are normally found in every RTOS. The attributes of task objects are normally at least priority and state (e.g. running, ready, suspended). However, the attributes of a task and the values of the attributes will differ from RTOS to RTOS. For example, one RTOS might have additional attributes like scheduling strategy while another might name the task states differently and still another might have no suspended state at all. This shows that the information given by a display object's functionality depends heavily on the RTOS in question. However, you can expect Hitex RTOS Debug Support to display all objects and all their attributes, even if this requires multiple windows. Additional RTOS Objects may be semaphores, memory regions, alarms, counters, queues, messages, etc.
Display object functionality requires only the most basic features of a debug system, i.e. to read from memory. Display object functionality is therefore present in all RTOS support from Hitex.
Event TraceThis functionality lets you record events occurring in the RTOS together with a time stamp. An example of such an event may be the activation of a task, the entry/exit of an interrupt routine or the call/return of an operating system service. This information is sufficient to answer questions like
Obviously, an Event Trace provides an insight into an RTOS application thatis very different to that provided by a regular high-level language debugger.
The Event Trace feature works in real-time without wasting resources of the target system. A huge memory area in the target system to record and save events is not necessary. Instead, the in-circuit emulator uses its trace buffer for that purpose. Also instrumentation of the RTOS application is normally not necessary. If instrumentation should become necessary, the overhead in time and memory is so small that the instrumentation can be kept in the production version, too. This avoids having to have different RTOS variants for test and production.
Events recorded in the Event Trace depends on the operating system in question. However, you can expect to get at least the order and duration of running tasks, if the Event Trace feature is available at all. The set up of the in-circuit emulator for the Event Trace is done automatically as soon as the Event Trace window is opened.
The Event Trace feature requires at least an in-circuit emulator that allows filtering of selected write cycles to the Trace buffer.
Task Specific BreakpointsTask Specific Breakpoints (and triggers) become useful if the RTOS application features shared code, i.e. a portion of code that is executed by different tasks. If a Task Specific Breakpoint is set in shared code, the breakpoint halts the emulation only if that code is executed on behalf of the specified task.
For Task Specific Breakpoints an in-circuit emulator featuring sequence levels or at least condition programs is a prerequisite.
This general explanation of Hitex RTOS Debug Support also applies to Hitex OSEK/VDX Debug Support.
List of currently supported RTOSHitex RTOS Debug Support for TriCore
Hitex RTOS Debug Support for MPC5xx
Hitex RTOS Debug Support for x86
Hitex RTOS Debug Support for 68HC12
Hitex RTOS Debug Support for C166/C167 and ST10
Hitex RTOS Debug Support for 68k
Hitex RTOS Debug Support for 68HC08