How Instrumented Trace Works

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.

TraceLogNew.gif
Figure 1: Example of Inserted Log Macro

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.

X_PP_8and16BitTrace.gif
Figure 2: Project Properties – Native Trace Selection

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.

© 2024 Microchip Technology, Inc.
Notice: ARM and Cortex are the registered trademarks of ARM Limited in the EU and other countries.
Information contained on this site regarding device applications and the like is provided only for your convenience and may be superseded by updates. It is your responsibility to ensure that your application meets with your specifications. MICROCHIP MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WHETHER EXPRESS OR IMPLIED, WRITTEN OR ORAL, STATUTORY OR OTHERWISE, RELATED TO THE INFORMATION, INCLUDING BUT NOT LIMITED TO ITS CONDITION, QUALITY, PERFORMANCE, MERCHANTABILITY OR FITNESS FOR PURPOSE. Microchip disclaims all liability arising from this information and its use. Use of Microchip devices in life support and/or safety applications is entirely at the buyer's risk, and the buyer agrees to defend, indemnify and hold harmless Microchip from any and all damages, claims, suits, or expenses resulting from such use. No licenses are conveyed, implicitly or otherwise, under any Microchip intellectual property rights.