Trace for the MPLAB® REAL ICE™ In-Circuit Emulator (Instrumented Trace) is a solution for providing basic trace information. Through the use of TRACE() and LOG() macros, you can report program locations or variable values to MPLAB X IDE while the application is running and examine them via the Trace window once the application halts. You may type these macro names in manually or right-click in the editor and select the macro to be inserted from the context menu. To log a variable value, the variable should be highlighted before selecting it from the context menu.
There are three trace methods available at this time (See "Types of Instrumented Trace"). The methods are located on the Project Properties dialog, REAL ICE for Category, and Trace and Profiling for Options Categories. The choices found under Communications Medium, include Native Trace (utilizes PGC/PGD communication lines), Serial Peripheral Interface (SPI) Trace, and I/O Port Trace. Not every method is available on every part; i.e., the options are device-specific. The Instrumented Trace library supports C and assembly projects on PIC18F MCU devices; but, only C projects on 16-bit devices.
The trace and log information transmitted is identical regardless of the trace method used. For TRACE(), a single value in the range of 64-127 is sent. A label generated using this number is automatically inserted into the code, so MPLAB X IDE can identify in the trace buffer the location that sent the value. For LOG(), a two-byte header is sent, followed by the value of the variable being logged. The first byte indicates the variable type and is a value between zero and 63. The second byte indicates the location that sent the variable. Here, the location is represented by a value between zero and 127. (See "More on Trace/Log ID Numbers".)
Interrupts are disabled during every TRACE() and LOG() call. This is to ensure that trace or log statements at an interrupt level do not interfere with a trace or log statement that may already be in progress at the application level. A similar argument holds for protecting statements within a low priority interrupt from being corrupted by those from a high priority interrupt.