Profiler Configuration
In this topic:
•Code
•Data
Introduction
By default the Profiler is configured to analyze:
•Program execution
•OS events (if OS awareness is configured in winIDEA)
•Network messages (if network analyzer is connected)
You can, however, choose exactly what you wish to analyze by selecting the event types:
•Code,
•Data,
•OS,
•FNet,
on the Profiler list and listing the specific events you wish to analyze.
|
Time correlation is only possible when timestamps for recorded messages are provided by the BlueBox. Practically this means that if you are using e.g. a trace port, you will be able to correlate the program flow with other trace sources (e.g. network messages), while if you're using an On-Chip Trace Buffer (OCTB), the timestamps for CPU trace data are provided by the On-Chip trace module, and therefore can not be correlated to the rest of the trace traffic. |
|
On the Recorder page, you can also limit the session duration for Profiler. |
Entry/Exit
In such case BlueBox comparators are set to record only function entries and exits, which limits the amount of information that needs to be recorded. However, the functionality relies on correct function entries and exits being reported in the debug information. If debug information is not reliable, the analysis might be aborted due to reconstruction failure.
Profiling in Entry/Exit mode also recognizes function nesting.
If a preemptive Operating System (OS) is used, it is required to also signal and profile the context switches of the OS. The Profiler basically maintains a function call stack for each recognized OS context.
Entry/Exit mode profiling does not cater for function exit optimizations, i.e. function exit optimizations may yield this profiling mode unusable.
Range
More reliable method of program execution reconstruction is the Range mode, where function entries and exits are detected based on the function range (we fall in range as soon as the first instruction in the function range is executed, and out of range as soon as the first instruction out of range is executed). This method is more reliable, as the function start and size are more accurately reported in debug information. Range mode requires full program trace recording.
Profiling in Range mode also recognizes function nesting.
If a preemptive Operating System (OS) is used, it is required to also signal and profile the context switches of the OS.
The Profiler basically maintains a function call stack for each recognized OS context.
Range mode profiling performs an in-depth analysis of the code trying to recognize and compensate compiler optimizations, such a function tail optimizations.
Flat
Program execution reconstruction may not always be possible (e.g. RTOS is used, but task switches are not recorded). For example function 1 is entered in context of task A and then function 2 is exited in context of task B. If task switches are not recorded, the program reconstruction will fail (function 1 entered, then function 2 exited, which indicates an error in the reconstruction process). Flat mode limits the analysis to the currently active function (function can either be active or inactive, ignoring the suspended mode). Flat mode analysis will provide limited function statistics, but is able to handle incomplete program reconstruction
Profiling in Flat mode does not recognize function nesting. It assume a valid entry/exit sequence for each function.
In Flat mode it is not necessary to also profile the context switches of an OS.
This mode is not affects by compiler optimizations.
Call Site
Method used for profiling configured functions. Determines the function activity by observing its call / exit site and not its entry / exit point as other available operation modes in winIDEA.
If the function doesn't have call sites specified in the symbol information (Symbol Browser window), it will be ignored in the analysis. If one function calls another, caller function will be shown as suspended in Profiler Timeline ONLY if the called function is configured for profiling.
Trigger at
By default the trigger logic is not configured. This option enables the user to generate a trigger on instruction execution. The trigger can be used informatively or as a start of profiler analysis (if option Analyze only events after trigger point is enabled). If the option Hardware Trigger is checked, please verify your Recorder Configuration to make sure both are configured properly.
Analyze events after trigger
When checked Profiler will ignore all events before the trigger marker (red line in the Profiler Timeline).
Advanced
Refer to Advanced Profiler Configuration for more information.
Refer to Code Profiling for more information.
During code profiling, BlueBox tools analyze the trace recording and try to reconstruct the program execution and the RTOS context to which it belongs.
Refer to Data Profiling for more information.
Refer to OS Profiling for more information.
Displays called functions in the Profiler Timeline and Profiler Statistics windows in a form of a three structure. If this option is selected, analysis will be performed on the selected Operation mode, except Flat. When exporting only call stack areas that are children of normal function area are exported.
More information in the Call Stack Profiling chapter.
More resources
•Timing Analysis – Function Profiling Operating modes - Tech Video
