winIDEA
|
|
|---|---|
|
Please note, these guides were put together for a dedicated microcontroller architecture and may differ from one to another. Please contact info@isystem.com for microcontroller specific information and functionality. |
Datasheet
|
All operating modes listed above are based on a physical analyzer module. An analyzer module can record CPU buses, and message based trace information (such as NEXUS, ETM for 32 bit microcontroller), external AUX lines and time stamps synchronous to the CPU's execution. As such, it is a powerful add-on to an in-circuit emulator or on-chip debugger to analyze and test program execution and correctness as well as performance of an embedded application. The following short descriptions give you an overview of what is possible using iSYSTEM’s Trace, Coverage and Profling enhanced functionality. For more information, please read the appropriate user’s guides or contact info@isystem.com. Trace is one of the most efficient mechanisms to get a deep and non-intrusive (real-time) overview of what’s going on in a microcontroller during program execution. Today, microcontrollers offer various implementations of this functionality, some of them don’t. Using a 32 bit microcontroller with an on-chip debug interface only, things get even more complicated. However, iSYSTEM on-chip tool solutions for ARM, Cortex, Freescale MPC, Coldfire, Texas Instruments TMS470 implement trace, coverage and profiling as good as a microcontroller allows to. Some implementations (based on NEXUS level 3 and ETM) are very close to the feature set of an in-circuit emulator.
More information about Trace using an In-Circuit Emulator More information about Trace using an On-Chip Debugger Execution Coverage (Statement and Decision) is a method to analyse the quality of test cases. Using the analyzer module in execution coverage mode it records all addresses being executed. Thus, the user can inspect code or memory areas not executed to define or improve test cases. Execution Coverage can also be used to detect so called “dead code” - code that has never been executed during testing. Such code represents undesired overhead when assigning code memory resources and represents a risk. Access Coverage is used for detecting non-initialized variables or to verify how many bytes of stack were consumed by the user's program. It is a data access analysis method. When the analyzer module is used in the access coverage mode, it records all CPU's addresses being accessed. All accesses can be detected down to one-byte resolution, depending on the type of analyzer module used. If a microcontroller doesn’t implement data trace support, it is not possible to run this analysis method. More information about Coverage Function profiler helps identifying performance bottlenecks. The user can find which functions are most time consuming or time critical and need to be optimized. Its functionality is based on the trace, recording entries and exits from profiled functions. A profiler area can be any section of code with a single entry point and one or more exit points. Existing functions profiler concept does not support exiting two or more functions through the same exit point. Exit point can belong to one function only. In such cases, the application needs to be modified to comply with this rule or alternatively data profiler with code arming can be used in order to obtain functions profiler results. The nature of the functions profiler requires quality high-level debug information containing addresses of function entry and exit points, or such areas must be setup manually. Trace recordings are then statistically processed and for each function the following information is calculated:
Function profiler relies on a fact that recorded instructions are executed. This can be a problem on CPUs with the internal CPU pipeline, where fetched cycles are dropped from the CPU pipeline before they come to the execute stage due to the change in the program. For instance few instructions following executed branch or return from subroutine instruction are fetched but not executed. Hence, functions profiler is supported on development systems with full CPU bus trace being capable to distinguishing between fetched and executed cycles, and on development systems with message based trace, which provide information on executed program by default. More information about Profiler
|