Products / Development Software / winIDEA /Enhanced Functionality / On-Chip Debugging
winIDEA
|
|
|---|---|
|
|
|
|
On-chip trace was introduced to address issues that came up with the ongoing miniaturization and integration of microcontrollers running at an increasing clock rate. Reducing pin count and costs at the same time as well as raising the maximum operation frequency, a traditional (in-circuit emulator like) trace was no longer possible. Chip manufacturers implement different levels of on-chip trace. This differs from a simple and small (couple of bytes) on-chip trace buffer to record some instructions (via a standard interface like JTAG) and goes up to complex on-chip debug cells such as NEXUS (see picture below) and ETM (from 2 to 12 additional pins are needed). Having no more access to the buses the only information a tool vendor can record are messages (highly cormpressed bus information). Additionally, every microcontroller vendor has a different way to implement on-chip trace. In the following, we describe the more complex implementations such as NEXUS and ETM more or less implemented on microcontrollers such as ARM, MPC, CRX, … Using On-Chip Trace as implemented by a microcontroller manufacturer
NEXUS – similar to ETM – is a message based protocol that transmits compressed bus information (so called NEXUS stream) over a few dedicated NEXUS pins. Each message is a variable length sequence of bits. In general, a CPU has a minimum of 2 NEXUS data pins. This can be extended to 4, 8 or 12 data pins if the developer uses more multiplexed ports for the NEXUS data pins. Due to inherent correlations in program flow the program trace is highly compressible, since it is very likely that most of the time the flow is sequential and most branches are short direct branches. However, data access activity is not sequential, so virtually no compression is possible here. Depending on the CPU some modest on-line filtering can be implemented in the Nexus module. Furthermore, the fairly simple trigger and filter logic of the CPU-internal trace interface is surely restricted. The data is captured in a trace buffer of the on-chip debugger. Once the buffer is filled, the data is transferred to the host where the program flow is reconstructed off-line using the source code.
 Limitations compared to an In-Circuit Emulator based trace:
Using On-Chip Trace with additional hardware from iSYSTEM
To get rid of these restrictions, iSYSTEM implemented a hardware based trace port analysis mechanism. The additional “blue box” needed is called iTRACEGT. It is able to reconstruct a full bus from the information produced by on-chip trace ports in real-time, on the fly. This means that the stream of Nexus/ETM data is immediately analyzed and the CPU activity reconstructed by hardware in an FPGA, thus providing full real-time program flow information. This technology provides all the trace possibilities which are normally provided by true in-circuit emulators. A full trigger machine is available that enables you to set up your trigger conditions easily. This advanced triggering also allows you to better utilize your trace buffer for only the data you need. Finally, waiting for long post-trigger software analysis is no longer required as all the data is reconstructed in real-time. Since the full execution bus is reconstructed, endless execution coverage and long lasting profiling are available too. Currently this feature is available on iTRACEGT for all ARM based controllers with ETM port, MPC5554 and CRX with Nexus port.
What else does iSYSTEM offer to make on-chip trace more comfortable and easy?
Trace Data Compression (for iTRACEGT based systems only) Optimized packing of on-chip trace messages using an iTRACEGT unit (for ARM, MPC):
• More trace history with the same physical trace buffer
• Existing trace depth can be extended considerably without fundamental losses
• Longer profiler session with the same physical trace buffer
• Existing profiler session can be extended considerably without fundamental losses
Trace Wizard (for all on-chip trace solutions from iSYSTEM)
Microcontrollers like ARM and MPC implement a more or less complex trigger dialog. In most of the cases they differ from each other. Thus, a user has to know all the details (register types and settings etc.) of a trigger machine to use it efficiantly. This is very time consuming! iSYSTEM implented a wizard, that assists a developer in stetting up simple and complex triggers. Every dialog that is supported by the wizard has a wizard button. This also includes hardware breakpoint configurations. Screenshot Standard Trigger Dialog of a MPC5554 NEXUS implementation Backtrace (for ARM microcontroller based systems) |