The CMXTracker Manual. The CMXTracker Manual

Similar documents
The CMXBug Manual. The CMXBug Manual

Micriµm, Inc. µc/os-view

REAL TIME OPERATING SYSTEMS: A COMPLETE OVERVIEW

SIO-DLL. Serial I/O DLL. User Manual

Command Manual Network Protocol. Table of Contents

SpiNNaker Application Programming Interface (API)

real-time kernel documentation

embos Real-Time Operating System CPU & Compiler specifics for embos Visual Studio Simulation

Typical modules include interfaces to ARINC-429, ARINC-561, ARINC-629 and RS-422. Each module supports up to 8 Rx or 8Tx channels.

6 System Processes Keyboard Command Decoder CRT Display... 26

Faculty of Electrical Engineering, Mathematics, and Computer Science Delft University of Technology

8086 Interrupts and Interrupt Responses:

AN HONORS UNIVERSITY IN MARYLAND UMBC. AvrX. Yousef Ebrahimi Professor Ryan Robucci

INEL4206: Microprocessors 1 Problem Set #5 Interrupt-Driven Memory-Mapped I/O in SPIM/XSPIM

Hardware OS & OS- Application interface

PS Telematik-Projekt: Wireless Embedded Systems

Section 31. DMA Controller

BASICS OF THE RENESAS SYNERGY TM

Release Bugs solved

Multiprogramming. Evolution of OS. Today. Comp 104: Operating Systems Concepts 28/01/2013. Processes Management Scheduling & Resource Allocation

Templates what and why? Beware copying classes! Templates. A simple example:

Task Based Programming Revisited Real Time Operating Systems

BASICS OF THE RENESAS SYNERGY PLATFORM

Input/Output Programming

C:\Users\Jacob Christ\Documents\MtSAC\ELEC74 Mt SAC - chipkit\homework Sheets.docx

Process Concepts. CSC400 - Operating Systems. 3. Process Concepts. J. Sumey

In examining performance Interested in several things Exact times if computable Bounded times if exact not computable Can be measured

ssj1708 User s Manual Version 1.3 Revised February 2nd, 2009 Created by the J1708 Experts

Exam TI2720-C/TI2725-C Embedded Software

,$5$SSOLFDWLRQ1RWH$95 (IILFLHQWSURJUDPPLQJRI$WPHO V $95 PLFURFRQWUROOHUV

What s An OS? Cyclic Executive. Interrupts. Advantages Simple implementation Low overhead Very predictable


Operating Systems 2014 Assignment 2: Process Scheduling

ECAN TM (Polling) Module

Computer Labs: I/O and Interrupts

Hello, and welcome to this presentation of the STM32 Low Power Universal Asynchronous Receiver/Transmitter interface. It covers the main features of

C:\Users\jacob\Documents\MtSAC\ELEC74 Mt SAC - chipkit\homework Sheets.docx

Xinu on the Transputer

Chaper 1: E10+ PLCs Host-Link Command Format

Visual Profiler. User Guide

Quadros. RTXC Kernel Services Reference, Volume 1. Levels, Threads, Exceptions, Pipes, Event Sources, Counters, and Alarms. Systems Inc.

Console Framework Module Guide

Lecture 3: Concurrency & Tasking

Simulator. Chapter 4 Tutorial: The SDL

REAL-TIME MULTITASKING KERNEL FOR IBM-BASED MICROCOMPUTERS

Introduction to Operating Systems Prof. Chester Rebeiro Department of Computer Science and Engineering Indian Institute of Technology, Madras

LORD MANUAL. Wireless Sensor Networks LXRS Data Communications Protocol

Lab 3a: Scheduling Tasks with uvision and RTX

Device-Functionality Progression

Chapter 12: I/O Systems. I/O Hardware

EE 390 Lab Manual, EE Department, KFUPM. Experiment #7. Introduction to Flight86 Microprocessor Trainer and Application Board

Lesson 5: Software for embedding in System- Part 2

Embedded Software TI2726 B. 7. Embedded software design. Koen Langendoen. Embedded Software Group

embos Real Time Operating System CPU & Compiler specifics for ARM core with ARM RealView Developer Suite 3.0 Document Rev. 1

Design and Implementation Interrupt Mechanism

Architectural Pattern for a Very Small Microcontroller

Module 1. Introduction:

PROCESS STATES AND TRANSITIONS:

Architectural Support for Operating Systems

Using kgdb and the kgdb Internals

SECTION 5 HSLRT6 WINDOWS BASED SETUP PROGRAM REFERENCE

Remote Control & PVR User Guide Version 12

IPTV Middleware Remote Control & DVR User Guide

CS 134. Operating Systems. April 8, 2013 Lecture 20. Input/Output. Instructor: Neil Rhodes. Monday, April 7, 14

Lab 13 Real Time Debugging

Using the KD30 Debugger

Embedded Systems Programming - PA8001

FERGUSON BEAUREGARD. RTU-5000 Configurator User Manual

CSE 120. Overview. July 27, Day 8 Input/Output. Instructor: Neil Rhodes. Hardware. Hardware. Hardware

Contents. Remote Control Playback Controls What s on TV? Using the OK Button Using the Info Button... 6

University of Massachusetts Amherst Computer Systems Lab 1 (ECE 354) LAB 1 Reference Manual

By the end of Class. Outline. Homework 5. C8051F020 Block Diagram (pg 18) Pseudo-code for Lab 1-2 due as part of prelab

Concurrency: Deadlock and Starvation. Chapter 6

Real Time Operating System: Inter-Process Communication (IPC)

Xbee module configuration from a µcontroller

Cooperative Multitasking

Embedded Resource Manager (ERM)

Real-Time Programming

DNP3 V3.00 DEVICE PROFILE DOCUMENT

SST DeviceNet Interface Cards

NetBurner s uc/os RTOS Library

NOTE The documentation and/or manuals provided by the IEDs vendors must be read and understood thoroughly prior to configuration.

Appendix A Pseudocode of the wlan_mac Process Model in OPNET

CSE 351. GDB Introduction

Multi-channel TNC FIRMWARE (Version 1.0) Copyright 1985, Ronald E. Raikes (WA8DED)

Introduction to the ThreadX Debugger Plugin for the IAR Embedded Workbench C-SPYDebugger

Micrium µc/os II RTOS Introduction EE J. E. Lumpp

Operating Systems Design Fall 2010 Exam 1 Review. Paul Krzyzanowski

Digital TV. Quick Reference Guide

User s Guide. HP B3081B Real-Time OS Measurement Tool for VRTX32 and VRTXsa

ArdOS The Arduino Operating System Reference Guide Contents

Using TOPPERS/ASP (RTOS) on GR-PEACH (Cortex-A9) With Atollic TrueSTUDIO

Chapter 1 Getting Started

DNP Points List and Implementation

Developing Reusable Device Drivers for MCU's

Design UART Loopback with Interrupts

Source EE 4770 Lecture Transparency. Formatted 16:43, 30 April 1998 from lsli

Input/Output Systems

Computer-System Architecture (cont.) Symmetrically Constructed Clusters (cont.) Advantages: 1. Greater computational power by running applications

Programming Model 2 A. Introduction

Transcription:

The CMXTracker Manual The CMX CMXTracker TM Code Analyzer provides the ability to log chronologically in real-time, the tasks' execution flow, capturing when a task is executing, the CMX functions called and their parameters, interrupts using CMX functions, and the CMX system TICK, within the CMX-RTX TM real-time multitasking operating system environment, while application code is running. Displaying the log is performed by CMXTracker, which runs as a task, usually the highest priority task. In most cases, one of the target processor UART channel(s) is used as the input/output device. A simple terminal or CPU with a keyboard is all that is required to use CMXTracker. When the CMXTracker task is enabled, it will send a menu to the screen. One of several prompts may be selected, allowing the user to view the chronologically ordered log, reset the log, resume running the application or "autowake" CMXTracker after a certain number of log entries or system TICKS. When the CMXTracker task is running, it prohibits other tasks from running, stops the task timers and cyclic timers, and disables interrupts from calling CMX functions, so the application is "frozen" within the CMX RTOS environment. CMXTracker allows viewing the log at the beginning or end and paging up or down. The exact execution of the tasks, the CMX functions called with their parameters and results returned (such as the message sent or received, event bits set, timed out, etc.), and interrupts are displayed with the CMX system TICK being a "timeline" stamp. CMXTracker has the capability to "single step" one system TICK allowing normal activity to occur for one system TICK, with CMXTracker resuming after this "single step". Also the number of system TICKS that CMXTracker will wait, allowing normal activity before it resumes, can be selected. This is a very powerful and helpful feature. A terminal that will send and receive characters using its serial port, or any PC that has a serial port and a communication package such as Procomm, Mirror, etc., should be connected to the target processor s serial port. For a communications package you may also use the CMX CMXBugio.exe program described below. The communication package selected should be fast enough to receive and display characters (without losing them) at a BAUD rate of 9600. CMX has a PC based program, CMXBugio.exe, which allows a PC to send and receive characters from either communication serial port 1 or 2. This is an interrupt driven program which allows characters to be received and transmitted without losing received characters. This will happen, in a normal polled environment, at a high BAUD rate. To use CMXBugio.exe the target processor UART must be configured for 9600 Baud, 8 data bits, one stop bit and No parity (9600 N81). Please notify us if you did not receive CMXBugio.exe and you would like one. 1

SETTING UP CMXTRACKER This manual will NOT go into great details about the CMX RTOS and its function calls. It is assumed that the user has read the CMX manual, is familiar with the CMX function calls and their parameters, and has a basic insight on how the CMX RTOS works. WARNING: Please read the section at the end of this manual, the "CMXTracker Processor Specific Section". This will provide any additional processor and "C" vendor specifics, with regards to using CMXTracker. SETTING UP CMXTRACKER WARNING: CMXTracker will NOT work in conjunction with the CMXBug. CMXBug and CMXTracker cannot be used at the same time in the same application. CMX provides the ability to have CMXTracker code included or not included within the CMX functions. If the CMXTracker code is included the code size of most CMX functions will be increased and execution times will be slightly longer for each function that has the ability to be recorded into the CMXTracker log. To have the CMXTracker code included within the CMX functions, the "C" vendor's compiler switch that is equivalent to a #DEFINE CMXTRACKER MUST be used. In most cases the switch is a -D so the command line for the compiler would look something like the following: Compiler_EXE_Name -DCMXTRACKER file.c. Because CMX supplies a make file for the CMX libraries, all that is necessary to recreate the library file(s) is to edit the make files (*.mak) adding the proper compiler switch to include this global define. CMX recommends that two sets of libraries be made, one set with the CMXTracker code included, and one set without CMXTracker code. Even though CMXTracker code is present, the CMXTracker code does NOT get executed unless CMXTracker has been enabled to run. Below is a simple function that may clarify this: cmx_function() {... /* function's normal code */ #ifdef CMXTRACKER/* If CMXTracker code should be present */ #endif if (CMXTRACKER_ON) /* Has the user enabled CMXTracker to record entries of CMX functions? If so, then record it */ { cmxtracker_in(this_function);/* record this entry. */ } 2

SETTING UP CMXTRACKER }... /* back to function's normal code */ Within the CMX header file "cxconfig.h" there are some defines that deal with CMXTracker, CMXTRACKER_ENABLE and CMXTRACKER_SIZE. CMXTRACKER_ENABLE is for enabling or disabling CMXTracker in the CMX module CMX_INIT.C. The CMX_INIT.C module is used by CMX to allocate the required memory and variables according to the configuration file. This define should be set to ONE (1) to enable CMXTracker, or set to ZERO (0) to disable CMXTracker. The #define CMXTRACKER_SIZE specifies the amount of RAM that will be allocated to the CMXTracker log. This size should be large enough to record a decent amount of entries. CMX compresses the entries in the log as much as possible. In most cases, entries into the log take 3 to 8 bytes. CMX recommends CMXTRACKER_SIZE be set to at least 1K (1024 bytes). If possible, CMX recommends 4K or more for a log size. CMXTracker may need to be modified to meet your specific needs. The "CMX_INIT.C" file contains 3 functions that may need to be modified and one global variable that might need to be changed. CMXTracker uses a POLLED method of testing the selected serial port of the processor to see if a character is present. The CMXTracker task defaults to waiting 10 SYSTEM TICKS, before waking up to see if the + (plus) key has been pressed. If not pressed, the CMXTracker task goes to sleep for another 10 SYSTEM TICKS. This is repeated until the + (plus) key is detected. The "wait" time may be increased or decreased if desired. This is a variable within the K_OS_Init function called BUG_WAIT_TICKS. BUG_WAIT_TICKS = 10; The setup_bug function may have to be modified to select the desired serial port. This function sets up the serial port by configuring the BAUD rate, data bits, parity, etc. It also enables any register flags that must be cleared and/or set to get the serial port alive. If using CMXBugio.exe the target processor UART must be configured for 9600 Baud, 8 data bits, one stop bit and No parity (9600 N81). This serial port MUST be configured for a POLLING type of operation and NOT interrupt driven. The K_Bug_Getchr function uses the serial port configured by the setup_bug function to receive characters for the CMXTracker task. It may or may not clear/set any necessary receiver flags, depending upon the processor. You are free to change the desired serial port, but you must ensure that the processor has this serial port and that any receiver flags that must be cleared or set, are done, according to the processor you are using. The K_Bug_Putchr function uses the serial port configured by the setup_bug function to transmit characters for the CMXTracker task. It may or may not clear/set any necessary transmitter flags, depending upon the processor. You are free to change the 3

SETTING UP CMXTRACKER desired serial port, but you must ensure that the processor has this serial port and that any transmitter flags that must be cleared or set, are done, according to the processor you are using. Try not to use the SAME serial port that is used by a MONITOR program, YOUR program, etc. If so, you will most likely run into a conflict problem. The CMX assembly file(s) also have a switch that determines whether or not to include the CMXTracker code. The switch is called CMXTRACKER_ENABLE and should be set to 1 (one) if the CMX assembly module is to be assembled with the ability to interface with the CMXTracker code. If CMXTRACKER_ENABLE is set to 0 (zero), then the assembly module will be assembled without the CMXTracker code. If this switch is off and other CMXTracker modules are linked in, then the logging of a task switch will NOT be performed. CMX could have coded the assembly modules to detect whether the CMXTracker code was enabled, but this would have required additional code and increased context switch times. Because of this, we have implemented a switch, which must be enabled/disabled by the user. The default setting is disabled. CMX provides the capability of a "user entry" into the cmxtracker log. This allows the user to place a character wide number (0-255) into the log. The CMX function is called cmxtracker_user. The prototype of this function is as follows. void cmxtracker_user(unsigned char user_num); If this function is used, CMX recommends that each time this function is called to increase the user_num variable by 1. This allows up to 256 consecutive numbers for each task. Because CMX automatically identifies which task called this function, each task is capable of calling 256 cmxtracker_user functions with a different user number. CMX provides a function to declare how many entries or SYSTEM ticks must occur, before "freezing" the CMXTracker log, allowing no more entries. The ability to have CMXTracker task automatically wake up ("autowake") after the desired number of entries or SYSTEM TICKS occur is also provided. The CMX function used is as follows: void cmxtracker_mode(unsigned char MODE, unsigned short COUNT); The COUNT parameter is the number of entries specified by the MODE parameter which must occur before the tracking log stops recording the flow of task execution, CMX functions called, etc. The MODE parameter specifies how CMXtracker should perform. The bits of this byte are explained below. Bit 0 = not used Bit 1 = not used Bit 2 = The COUNT is decremented on the SYSTEM TICK. 4

Bit 3 = The COUNT is decremented each time a entry is recorded. Bit 4 = not used Bit 5 = not used Bit 6 = not used Bit 7 = Autowake the CMXTracker task, when count gets to zero. If the declared size of RAM for logging is smaller than the size needed to record based on the COUNT parameter, then the COUNT parameter is disregarded. There are two ways to start LOGGING. The first way is by setting the CMXTRACKER_ON variable to 1 (one). The second way is to have the CMXTracker task woken up (by pressing the plus '+' key) and then having the CMXTracker task do a QUICK GO and RESUME, GO and RESUME or EXIT CMXTracker function. You can disable the recording of entries by setting the CMXTRACKER_ON variable to a zero (0). How ever if you do this and then use the '+' key to wake up the CMXTracker task and do one of the following: QUICK GO and RESUME, GO and RESUME or EXIT CMXTracker functions, the CMXTRACKER_ON variable will forcibly be set to a 1 (one), thus enabling recording of entries. The CMXTracker is a task that must be included into the application code. This code is found in file "cmxtrack.c". The CMX libraries (CMX functions) must be built with the #define CMXTRACKER, so the CMXTracker code resides within the CMX functions. Also the CMX RTOS must be used in the application, with the switches described above correctly set, to allow CMXTracker to work properly. To enter the CMXTracker task press the + (plus) key from the console input device. If the "autowake" feature of the CMXTracker is used, the + (plus) key does not have to be pressed, for the CMXTracker task will automatically be triggered. Once this is done the CMXTracker task will take control of the CMX RTOS system. CMXTracker then presents a menu that looks as follows. Select the desired function: Enter 1 to DISPLAY LOG Enter 2 RESET LOG Enter 3 GO and RESUME CMXTracker Enter 4 QUICK GO and RESUME CMXTracker Enter 99 EXIT CMXTracker Enter P/p to toggle ECHO mode Your choice? The following pages will describe each of the above choices in detail. First we will explain some of the data entry prompts you will see. 5

Because CMXTracker will usually talk (UART I/O) to a terminal or CPU, normal data entry is somewhat limited. Also to keep the code size of the CMXTracker task down to a minimum, the data entered is not parsed until the <Return/Enter> key has been pressed. The following "keys" are used quite frequently. <Pg Dn> is used to go one page down in the log, with each "page" set to 18 entries. Note that it may not be possible to show a complete page if at or near the end of the log. <Pg Up> is used to go one page up in the log, with each "page" set to 18 entries. <Home> is used to go to the top of the log, displaying the FIRST page. <End> is used to go to the bottom of the log, displaying the LAST page. Note the LAST page may not be a complete page. The "<return> to exit" is used to go back to the previous menu. The <return> key must be pressed as the first key to exit the current function. At ANY TIME, the + (plus) key may be pressed to return to the main menu. The following will show you the different CMX functions and the associated "picture" that is seen when the selected function is displayed. Please make a note that there may be slight differences, depending upon minor enhancements to the CMXTracker code. First to be displayed is what CMX function was called by user code, a task or by an interrupt. We will then show you at least one of the following: INFORMATIONAL results, SUCCESSFUL results, or UNSUCCESSFUL results. Some functions have a "time parameter" that is displayed, or "Timed Out" if the time period expired before the possible other entity occured. It is possible that more than one error code can result from a CMX function. We will list all INFORMATIONAL, SUCCESSFUL and UNSUCCESSFUL displays for each function. We do not always break the function down into the smallest unsuccessful result codes, for this would require much more code space and increase the time to get through the function. Note that INFORMATIONAL is displayed as INFO, SUCCESSFUL is displayed as GOOD and UNSUCCESSFUL is displayed as ERROR. If the task was named using the CMX K_Task_Name function, up to 12 characters of the name will be displayed. If the task was not named, then Slot #?? will be displayed. We have listed "TASK NAME" as indicating the task's name or slot number. Also question marks (?) indicate values that will be filled in by CMXTracker. CMX recommends that while working with CMXTracker, that the tasks be named with the K_Task_Name function. Note that when you are calling functions prior to entering the CMX RTOS with the K_OS_Start function, NO task will be shown, for there is no current running task. 6

Below are 3 examples, the first was for a function called prior to the K_OS_Start function, the second if a task did NOT have a name attached to it and the third if a task DID have a name attached to it. USER CODE... Slot #??... TASK NAME... WARNING: If the CMXTracker task does NOT understand a particular entry in the CMXTracker log, then the following message will appear. If this message appears, then ALL subsequent entries should be considered INVALID. The user is encouraged to call CMX because this message should NEVER appear. ERROR: "Not valid command" The following "keywords" will be displayed in capital letters when a task uses them. >>> CMX Tick <<<: This indicates that the CMX "system tick" has occurred. This is used as a time line for the occurrence of system calls by tasks and interrupts. EXECUTING: This denotes that the shown task is now the executing task. When the scheduler is entered, you will not get another EXECUTING when leaving the scheduler, unless another task becomes the "new" running task. INFO: "TASK NAME EXECUTING" --CYCLIC?? K_Event_Signal: This signifies that the cyclic timer setup and started, was automatically executed, when its programmed time expired. The "??" will be filled in with the actual cyclic timer number.also identified is whether it was successful in calling the K_Event_Signal function. If it was successful, then it will list the "mode" value that was executed. Note that "mode" is set when a cyclic timer is created. The task name/slot number or priority will be shown according to the selected mode value. INFO: "--CYCLIC?? K_Event_Signal,..." ++INTERRUPT : This means that an interrupt called this function, not a task. It does NOT identify which interrupt called it, only that the function was executed out of the interrupt pipe function queue. INFO: "++INTERRUPT..." The following are assumed to follow the user code, task or interrupt that called them. K_Task_Create: Indicates that the CMX K_Task_Create function was called. GOOD: "K_Task_Create, Successful" ERROR: "K_Task_Create, ERROR" K_Task_Start: Indicates that the CMX K_Task_Start function was called. 7

GOOD: "K_Task_Start, Successful, TASK NAME" ERROR: "K_Task_Start, ERROR-> TASK NAME" K_Task_Priority: Indicates that the CMX K_Task_Priority function was called. GOOD: "K_Task_Priority, Successful, TASK NAME, NEW PRI. is??" ERROR: "K_Task_Priority, ERROR-> TASK NAME" K_Task_Remove: Indicates that the CMX K_Task_Remove function was called. GOOD: "K_Task_Remove, Successful, TASK NAME" ERROR: "K_Task_Remove, ERROR-> TASK NAME" ERROR: "K_Task_Remove, ERROR-> BUSY, TASK NAME" K_Task_Wake: Indicates that the either the CMX K_Task_Wake or K_Task_Wakef function was called. GOOD: "K_Task_Wake, Successful, TASK NAME" ERROR: "K_Task_Wake, ERROR-> TASK NAME" ERROR: "K_Task_Wake, ERROR-> not waiting, TASK NAME" K_Task_Wait: Indicates that the CMX K_Task_Wait function was called. ALWAYS displayed when called: "K_Task_Wait TIME PERIOD =?????" One of the other two messages are displayed, if either the time period expired or the K_Task_Wake/K_Task_Wake_force function was used. INFO: "K_Task_Wait TIME PERIOD =?????" INFO: "K_Task_Wait, Timed Out" INFO: "K_Task_Wait, woken by K_Task_Wake" K_Task_End: Indicates that the CMX K_Task_End function was called. INFO: "K_Task_End" K_Mesg_Get: Indicates that the CMX K_Mesg_Get function was called. If successful, then the text "MBOX #??" and mailbox number will be shown. Also the first 12 characters of the message that has been RECEIVED will be shown, followed by 3 dots if the message length exceeds 12 characters (e.g. Mesg. recv = message Stri... ). GOOD: K_Mesg_Get, Successful, MBOX #??, Mesg. recv = MESSAGE" ERROR: "K_Mesg_Get, ERROR-> range, MBOX #??" ERROR: "K_Mesg_Get, ERROR-> MBOX owned, MBOX #??" ERROR: "K_Mesg_Get, ERROR-> no messages, MBOX #??" K_Mesg_Wait: Indicates that the CMX K_Mesg_Wait function was called. If successful, then the text "MBOX #??" and mailbox number will be shown. Also the first 12 characters of the message that has been RECEIVED will be shown, followed by 3 dots if the message length exceeds 12 characters (e.g. Mesg. recv = message Stri... ). INFO: "K_Mesg_Wait, MBOX #??" GOOD: "K_Mesg_Wait, Successful, MBOX #?? Mesg. recv = MESSAGE" ERROR: "K_Mesg_Wait, ERROR-> range, MBOX #??" ERROR: "K_Mesg_Wait, ERROR-> MBOX owned, MBOX #??" 8

ERROR: "K_Mesg_Wait, ERROR-> Timed Out, no messages, MBOX #?? " K_Mesg_Send: Indicates that the CMX K_Mesg_Send function was called. If successful, then the text "MBOX #??" and mailbox number will be shown. Also the first 12 characters of the message being SENT will be shown, followed by 3 dots if the message length exceeds 12 characters (e.g. Mesg. sent = message Stri...). GOOD: "K_Mesg_Send, Successful, MBOX #?? Mesg. sent = MESSAGE" ERROR: "K_Mesg_Send, ERROR-> Range/NO MSG slots, MBOX #??" K_Mesg_Send_Wait: Indicates that the CMX K_Mesg_Send_Wait function was called. If successful, then the text "MBOX #??" and mailbox number will be shown. Also the first 12 characters of the message being SENT will be shown, followed by 3 dots if the message length exceeds 12 characters (e.g. Mesg. sent = message Stri...). INFO: "K_Mesg_Send_Wait, MBOX #??" GOOD: "K_Mesg_Send_Wait, Successful, MBOX #?? Mesg. sent = MESSAGE" GOOD: "K_Mesg_Send_Wait, Successful, ACKED by receiving task, MBOX #??" ERROR: "K_Mesg_Send_Wait, ERROR-> Range/NO MSG slots, MBOX #??" ERROR: "K_Mesg_Send_Wait, ERROR-> Timed Out WAITING for ACK, MBOX #??" K_Mesg_Ack_Sender: Indicates that the CMX K_Mesg_Ack_Sender function was called. If successful, then the task name/slot number will be shown. GOOD: "K_Mesg_Ack_Sender, Successful, TASK NAME" K_Mbox_Event_Set: Indicates that the CMX K_Mbox_Event_Set function was called. If successful, then the text "MBOX #??" and mailbox number will be shown. ERROR: "K_Mbox_Event_Set, ERROR-> range, MBOX #??" GOOD: "K_Mbox_Event_Set, Successful, MBOX #?? " K_Event_Signal: Indicates that the CMX K_Event_Signal function was called. If it was successful, then it will list the "mode" value that was executed. The task name/slot number or priority will be shown according to the selected mode value. Also the event bit(s) to be set are displayed in HEX: 0x????. Note that there are 16 event bits and any combination of these 16 bits, may be enabled (set to a one). The mode value displayed ranges from 0 to 6. Below is the output for the different modes. GOOD: "K_Event_Signal, Successful, Mode 0, TASK NAME" GOOD: "K_Event_Signal, Successful, Mode 1, TASK NAME" GOOD: "K_Event_Signal, Successful, Mode 2, TASK NAME" GOOD: "K_Event_Signal, Successful, Mode 3, ALL Tasks" GOOD: "K_Event_Signal, Successful, Mode 4, ALL Tasks Waiting" GOOD: "K_Event_Signal, Successful, Mode 5, ALL Tasks same PRI." GOOD: "K_Event_Signal, Successful, Mode 6, ALL Tasks same PRI. Waiting" ERROR: "K_Event_Signal, ERROR-> mode #??" ERROR: "K_Event_Signal, ERROR-> TASK NAME" 9

K_Event_Wait: Indicates that the CMX K_Event_Wait function was called. When a task calls this function the time period that it is willing to wait for at least one of the event bits to be set will be displayed. If the time specified expires "Timed out" will be shown. On a match of event bit(s) the text "Event bits match = 0x????" will be displayed, with the? mark filled in by the hex value of the bit(s) which were set that this task was waiting on. INFO: "K_Event_Wait puttime(); INFO: "K_Event_Wait, Timed Out" GOOD: "K_Event_Wait, Successful, Event bits match = 0x????" K_Event_Reset: Indicates that the CMX K_Event_Reset function was called. If successful, the task name/slot number will be shown and the event bit(s) that were reset will be displayed in hex format: 0x????. Note that there are 16 event bits and any combination of these 16 bits may be enabled (set to a one), signifying that these are the bits to reset. GOOD: "K_Event_Reset, Successful, TASK NAME Event bits reset = 0x????" ERROR: "K_Event_Reset, ERROR-> TASK NAME" K_Mem_FB_Create: Indicates that the CMX K_Mem_FB_Create function was called. If successful, the address of the memory block BASE will be displayed in hex format: 0x????. GOOD: "K_Mem_FB_Create, Successful, Memory Block BASE address 0x????" K_Mem_FB_Get: Indicates that the CMX K_Mem_FB_Get function was called. If successful, the address of the memory block will be displayed in hex format: 0x????. GOOD: "K_Mem_FB_Get, Successful, Memory address is 0x????" ERROR: "K_Mem_FB_Get, ERROR-> none free, Memory Block base address 0x????" K_Mem_FB_Release: Indicates that the CMX K_Mem_FB_Release function was called. If successful, the address of the released memory block will be displayed in hex format: 0x????. GOOD: "K_Mem_FB_Release, Successful, Memory address returned 0x????" K_Timer_Create: Indicates that the CMX K_Timer_Create function was called. If successful, the cyclic timer number will be displayed. ERROR: "K_Timer_Create, ERROR-> Range: cyclic timer #??" GOOD: "K_Timer_Create, Successful, cyclic timer #??" K_Timer_Start: Indicates that the CMX K_Timer_Start function was called. If successful, the cyclic timer number will be displayed. GOOD: "K_Timer_Start, Successful, cyclic timer #??" ERROR: "K_I_Cyclic_Common, ERROR-> Range: cyclic timer #??" K_Timer_Restart: Indicates that the CMX K_Timer_Restart function was called. If successful, the cyclic timer number will be displayed. GOOD: "K_Timer_Restart, Successful, cyclic timer #??" 10

ERROR: "K_I_Cyclic_Common, ERROR-> Range: cyclic timer #??" K_Timer_Cyclic: Indicates that the CMX K_Timer_Cyclic function was called. If successful, the cyclic timer number will be displayed. GOOD: "K_Timer_Cyclic, Successful, cyclic timer #??" ERROR: "K_I_Cyclic_Common, ERROR-> Range: cyclic timer #??" K_Timer_Initial: Indicates that the CMX K_Timer_Initial function was called. If successful, the cyclic timer number will be displayed. GOOD: "K_Timer_Initial, Successful, cyclic timer #??" ERROR: "K_I_Cyclic_Common, ERROR-> Range: cyclic timer #??" K_Timer_Stop: Indicates that the CMX K_Timer_Stop function was called. If successful, the cyclic timer number will be displayed. GOOD: "K_Timer_Stop, Successful, cyclic timer #??" ERROR: "K_Timer_Stop, ERROR-> Range: cyclic timer #??" K_Que_Create: Indicates that the CMX K_Que_Create function was called. If successful, the queue number will be displayed. ERROR: "K_Que_Create, ERROR-> queue #??" GOOD: "K_Que_Create, Successful, queue #??" K_Que_Add_Top: Indicates that the CMX K_Que_Add_Top function was called. If successful, the queue number will be displayed. GOOD: "K_I_Que_Add_Common, Successful, queue #??" ERROR: "K_I_Que_Add_Common, ERROR-> Range: queue #??" ERROR: "K_I_Que_Add_Common, ERROR-> Full: queue #??" K_Que_Add_Bottom: Indicates that the CMX K_Que_Add_Bottom function was called. If successful, the queue number will be displayed. GOOD: "K_I_Que_Add_Common, Successful, queue #??" ERROR: "K_I_Que_Add_Common, ERROR-> Range: queue #??" ERROR: "K_I_Que_Add_Common, ERROR-> Full: queue #??" K_Que_Get_Top: Indicates that the CMX K_Que_Get_Top function was called. If successful, the queue number will be displayed. GOOD: "K_I_Que_Get_Common, Successful, queue #??" ERROR: "K_I_Que_Get_Common, ERROR-> Range: queue #??" ERROR: "K_I_Que_Get_Common, ERROR-> Empty: queue #??" K_Que_Get_Bottom: Indicates that the CMX K_Que_Get_Bottom function was called. If successful, the queue number will be displayed. GOOD: "K_I_Que_Get_Common, Successful, queue #??" ERROR: "K_I_Que_Get_Common, ERROR-> Range: queue #??" ERROR: "K_I_Que_Get_Common, ERROR-> Empty: queue #??" 11

K_Que_Reset: Indicates that the CMX K_Que_Reset function was called. If successful, the queue number will be displayed. GOOD: "K_Que_Reset, Successful, queue #??" ERROR: "K_Que_Reset, ERROR-> queue #??" K_Resource_Get: Indicates that the CMX K_Resource_Get function was called. If successful, the resource number will be displayed. GOOD: "K_Resource_Get, Successful, resource # " ERROR: "K_Resource_Get, ERROR-> resource #??" ERROR: "K_Resource_Get, ERROR-> already owned, resource #??" K_Resource_Wait: Indicates that the CMX K_Resource_Wait function was called. If the time period specified by this function to wait for a resource expires, "Timed out" will be shown. If time has not expired, the resource number and the time period requested by the task will be displayed. INFO: "K_Resource_Wait, resource #?? TIME PERIOD =??; INFO: "K_Resource_Wait, Timed Out" GOOD: "K_Resource_Wait, Successful, resource #??" ERROR: "K_Resource_Wait, ERROR-> resource #??" K_Resource_Release: Indicates that the CMX K_Resource_Release function was called. The resource number will be displayed. GOOD: "K_Resource_Release, Successful, resource #??" ERROR: "K_Resource_Release, ERROR-> resource #??" ERROR: "K_Resource_Release, ERROR-> not owned, resource #??" K_OS_Slice_On: Indicates that the CMX K_OS_Slice_On function was called. INFO: "K_OS_Slice_On " K_OS_Slice_Off: Indicates that the CMX K_OS_Slice_Off function was called. INFO: "K_OS_Slice_Off " K_Task_Lock: Indicates that the CMX K_Task_Lock function was called. INFO: "K_Task_Lock, Successful" K_Task_Unlock: Indicates that the CMX K_Task_Unlock function was called. INFO: "K_Task_Unlock, Successful" K_Task_Coop_Sched: Indicates that the CMX K_Task_Coop_Sched function was called. INFO: "K_Task_Coop_Sched" USER ENTRY: Indicates that the CMXTracker cmxtracker_user function was called. INFO: "USER ENTRY, entry #??" GO and RESUME CMXTracker function Enter the number of ticks to wait or <return> to leave 12

This function allows CMXTracker to release control of the CMX RTOS for the number of SYSTEM TICKS selected. When the number of SYSTEM TICKS specified has expired, CMXTracker will automatically resume control of the CMX RTOS and freeze all other tasks. This is a very powerful feature, for it allows the user to "multiple step" the desired number of SYSTEM TICKS and see the CMX RTOS environment change, aiding in debugging and verifying the application. Note when this is performed CMXTracker cannot be "woken" sooner by entering a key stroke. QUICK GO and RESUME CMXTracker function This function allows CMXTracker to release control of the CMX RTOS for one SYSTEM TICK. When the NEXT SYSTEM TICK has expired, CMXTracker will resume control of the CMX RTOS and freeze all other tasks. This is a very powerful feature, for it allows the user to "single step" one SYSTEM TICK at a time and see the CMX RTOS environment change, aiding in debugging and verifying the application. This function is the same as the GO and RESUME function above with a selected value of 1. EXIT CMXTracker function This function will allow the CMXTracker task to PERMANENTLY release control of the CPU back to the CMX RTOS and the running application. The only way to reenter the CMXTracker task is by pressing the "+" (plus) key. Enter P/p to toggle ECHO mode This function allows CMXTracker task to enable or disable the ECHO mode. The default is to ECHO (send back) all valid characters received to the terminal or PC. If disabled, no received characters will ECHO back. If a valid key is pressed and two characters are displayed, then the CMXTracker ECHO mode can be disabled or the terminal or PC prevented from echoing characters. 13