ARM-ETM RTS User s Guide

Transcription

1 ARM-ETM RTS User s Guide TRACE32 Online Help TRACE32 Directory TRACE32 Index TRACE32 Documents... ICD In-Circuit Debugger... Processor Architecture Manuals... ARM/CORTEX/XSCALE... ARM-ETM RTS User's Guide... 1 Introduction... 3 Contacting Support 3 Debug System Requirements... 4 Target System Requirements... 4 Differences between Real-time Profiling and Classical Trace... 5 System Setup for Real-time Profiling... 6 Verification of the setup via classical trace 6 Minimal test of RTS 7 Use Case RTS.ON... 9 Use Case RTS.LOAD Avoiding and Fixing Processing Errors Background on Decoding of Trace Protocols and Error Types 15 Resolving Physical Transmission Errors ( Flow errors ) 16 Locating and Resolving Errors No access to code errors 16 Profiling a Target Application Processing Performance Considerations Requirements for Processing Resources 18 Assessing the usage of the host s processing resources 19 Current Limitations Troubleshooting Empty result windows or invalid results 21 Empty windows RTS.LIST or RTS.ListNested 21 Flow Errors 21 Error: No access to code 22 Warning: RTS.ON: There is no program code in the debugger s VM ARM-ETM RTS User s Guide 1

2 Error: Streaming not possible in this configuration 22 Locked commands and disabled dialog controls 24 Glossary ARM-ETM RTS User s Guide 2

3 ARM-ETM RTS User s Guide Version 29-Mar-2017 Introduction The term real-time profiling means the recording, processing, and optional storage of trace data, while the target system is running and emitting new trace data. The term real-time suggests that the analysis on the host is (often) fast enough to process the trace data as quickly as it is created. By no means there is any real-time magic to detect overwritten vectors etc. in the target. Real-time profiling has to be distinguished from the trace mode STREAM which means only recording trace data for extended amounts of time and storing it to disk. The difference between both features regarding the file is that the trace mode STREAM writes unprocessed raw trace data (e.g. raw PTM or ETMV3 protocol data) to the file which serves as huge trace buffer (limited by the size of the disk), while realtime profiling saves pre-decoded trace data and the results of the analysis. This document is about real-time profiling. The document: lists the system requirements, highlights the difference between classical trace and real-time processing shows how to set up a system for RTS, presents exemplary use cases for RTS.ON, RTS.LOAD and for profiling the target application, each illustrating various features, and gives some guidelines to assess the required processing resources on the host. A detailed description of the commands is not given in this document. This can be found in the command reference documentation on RTS. NOTE: For historical reasons the command for invoking real-time profiling feature is named RTS which is the abbreviation of an older name of the feature. Contacting Support For RTS specific support, contact rts-support@lauterbach.com. ARM-ETM RTS User s Guide 3 Introduction

4 Debug System Requirements For using RTS there are the following requirements: A PowerTrace-II with AutoFocus-II preprocessor: only this hardware provides the required data rates and allows to transfer data to the host PC while new data is recorded. A Gbit Ethernet interface; despite theoretically sufficient bandwidth, a debugger with USB interface does not reach the same transfer rates. A fast host PC, especially for the cycle accurate analysis and for nested analysis. A 64bit executable and OS are required for handling traces > 2G Frames. Target System Requirements Currently real-time profiling only support targets with ETMv3 and Coresight or PTM. Some feature are still under development for PTM. ARM-ETM RTS User s Guide 4 Debug System Requirements

5 Differences between Real-time Profiling and Classical Trace The main technical difference between real-time profiling and classical trace is that with classical trace the analysis of the collected trace data is performed after the target stopped while real-time profiling analyses the incoming trace continuously at run-time once the target was started (e.g. via the Go command). The consequence is that classical trace is limited by the available trace buffer (which may be the whole hard-disk when using the trace mode STREAM) while real-time profiling can handle very long-running tasks if the host can keep up with processing the incoming trace data. A technical difference is that for classical trace the debugger reads the program code required for the analysis from the target s program memory (which possible as the analysis is performed with a stopped target). This is not possible for real-time profiling as the analysis takes place at run-time and the debugger cannot read the program image from the target (at least not at the required speed and not without influencing its real-time behavior). Therefore real-time profiling requires a copy of all program code in the debugger s virtual memory (VM:) before starting the RTS analysis. This requirement includes but is not limited to regular program code interrupt handlers reset and exception handlers As a rule of thumb a copy of all code should be present in the VM: before starting the target program. Pay special attention to cases where program code is relocated or loaded at run-time. ARM-ETM RTS User s Guide 5 Differences between Real-time Profiling and

6 System Setup for Real-time Profiling If the requirements listed in section System Requirements are met and classical flow trace functionality works with your target, the setup for RTS is straight-forward. For RTS it is important that there are no flow errors, because these can seriously disturb the more complicated types of trace analysis (e.g. the nested analysis). The only additional requirement over classical tracing is that a copy of all program code has to be loaded into the debugger s virtual memory (VM:) before starting the RTS analysis. This is necessary because the trace decoder cannot read the required program image from the running target. Verification of the setup via classical trace Before testing a simple RTS use case, we want to verify that the trace recording is free from flow errors and that all program code is present in VM: to prevent any no access to code errors. Both can be verified using classical flow trace. To assure there are no flow errors, perform a classical trace analysis with real-time profiling disabled (RTS.OFF) and execute the command Analzyer.FindAll, flowerror In case there are flow errors try to use the calibration features of the trace hardware (e.g. the Autofocus II preprocessor) to get rid of them. To write or copy program code into the VM: the following commands can be helpful: Data.Load.... /VM Data.LOAD.... /PlusVM ; loads the code only into VM ; used when the target boots it s program ; loads the code into both into the VM ; and the target Data.COPY 0x0++0x100 vm:0x0 ; Copy 256. bytes from the target to VM: NOTE: If the target executes interrupt handlers or exception vectors, these need to be present also in the VM. To achieve this, the Data.COPY command can be useful. ARM-ETM RTS User s Guide 6 System Setup for Real-time Profiling

7 To verify that all executed program code was copied to the VM: perform the following steps (still with RTS.OFF) 1. Check the contents of program memory using the commands below. Both windows must show the same contents and the virtual memory must be initialized (otherwise it shows as???????? ). Data.List ; display target memory Data.List VM: ; check the debugger s virtual memory 2. Configure the trace decoder to read program code from the VM: (For RTS this step is redundant because it is implicitly done by RTS.ON) using the command Analyzer.ACCESS VM: 3. Start the target and verify that Analyzer.List works correctly while the target is running by: GO <execute the target code and trace it via classical trace > Analyzer.List ; open the list window Analyzer.OFF ; switch analyzer off but keep target running Now the Analyzer.List window should show valid trace data. 4. Check if no access to code errors occurred using the following command Trace.FindAll cycle unknown In case of errors copy the relevant areas to debugger VM: and repeat the procedure until no errors are left. Minimal test of RTS After verifying that classical trace works correctly while the target is running, we test RTS. 1. Enable RTS and set the required options. Start with simple settings: RTS.Init RTS.TImeMode.OFF RTS.NestingMode.FLAT RTS.TASKMode.OFF RTS.FileMode.OFF RTS.ON ; reset all RTS options to default values ; no real-time information ; no function nesting analysis ; no task support, and ; no writing to file ; enable RTS ARM-ETM RTS User s Guide 7 System Setup for Real-time Profiling

8 2. Start the target and open an ISTAT window: GO RTS.ISTAT.ListModule After starting the target again, the window will be constantly be updated. By default all errors will turn off the trace - which leaves the trace cycles that caused the problem in the regular analyzer. The RTS.List window (if available) will show the trace just up to the problem. ARM-ETM RTS User s Guide 8 System Setup for Real-time Profiling

9 Use Case RTS.ON This section presents a sample use case with RTS.ON. Before following the steps below verify that RTS works as described in the Quick Start Guide. NOTE: Contrary to usual procedure, in this tutorial we will encounter some problems giving us the chance to identify them and learn how to solve them on our own when using RTS in the real world. The first step is to configure RTS for our use case. In this case we do a cycle accurate analysis of the programs call tree. RTS.RESet RTS.NestingMode.TREE RTS.TImMode.CycleAccurate RTS.FILE t32.rts RTS.ON Go ; reset options to defaults ; analysis of the program s call graph ; name of the RTS file ; enable RTS after configuration ; run to breakpoint JPEG_DecompressAllocate After executing Go, the trace data is recorded and analyzed. We open some windows with analysis results. First we are interested in the code coverage analysis: Data.List /COV ARM-ETM RTS User s Guide 9 Use Case RTS.ON

10 Strangely the window is all yellow, as if not code had been executed at all: The reason is that we forgot to open an RTS.COVerage.<*> window. This is required because views depending on the COVerage data base are only updated while such a window is open. The same holds true for the ISTAT information. We open the following windows: RTS.COVerage.ListModule RTS.ISTATistic.ListModule ; keep coverage windows updated ; keep ISTAT windows updated The ISTAT window now correctly shows the coverage information in white and yellow (executed / not executed): the while loop was not entered because the core stopped in JPEG_DecompressAllocate(). However, the columns cycles and cpi at the left side are all zero. This is because we used cycle accurate mode but forgot to set the CPU clock frequency via Trace.CLOCK. ARM-ETM RTS User s Guide 10 Use Case RTS.ON

11 After setting the CPU clock and restarting the trace session (recording the data again), we finally get sensible values for the cycle information: The RTS.ISTATistic window shows similar information Finally we execute RTS.OFF. This ends the RTS sessions. This is not strictly necessary in the current context but when using an RTS file (see RTS.FileMode) it is required to save pending data. So it is a good habit to end the session with RTS.OFF. ARM-ETM RTS User s Guide 11 Use Case RTS.ON

12 Use Case RTS.LOAD This section presents a sample use case using RTS.LOAD. In this mode RTS operates on data loaded from the so-called RTS file. This is useful for analyzing the data later. We start off by creating an RTS file by performing a debug session with RTS.ON with the option RTS.FileMode.FULL. This causes all data recorded during the session to be saved to the file. Obviously this requires some processing resources and may slow down the analysis of the trace data (For more information see Processing Performance Considerations). At the end of the session, it is necessary to use RTS.OFF to save the final results (coverage and instruction statistics) and the virtual memory to the RTS file. SYStem.RESet RTS.RESet Data.LOAD.ELF tribalista.elf /PLUSVM RTS.FILE jaseinamorar.rts ; select file name RTS.FileMode.FULL ; save trace data + final analysis results RTS.NestingMode.TREE ; set analysis options RTS.TImeMode.CycelAccurate ; RTS.TASKMode.OFF ; RTS.ON Go ; start debugging session < target running for some seconds while saving trace data > BREAK RTS.OFF ; stop the target ; close file and save pending data copy jaseinamorar.rts KEEPTHIS.RTS ; make safety copy RTS.ON automatically renames the previous file to *.bak. Despite this we make a safety copy because the mechanism only preserves a single file. Now let s have a look at the setup for RTS.LOAD. Its setup is simpler because the options like RTS.NestingMode, RTS.TImeMode etc. are restored from the file. So we just reset the system and load the RTS file: SYStem.RESet RTS.LOAD jaseinamorar.rts ; enable RTS.LOAD mode loading file This loads the contents of the virtual memory contents (VM:) and the final processing results e.g. the final COVerage information from the file. Then we open the RTS.STATistic.TREE window to inspect the call tree (The minimum detail level required for this is RTS.FileMode.Summary). RTS.STATistic.TREE ARM-ETM RTS User s Guide 12 Use Case RTS.LOAD

13 Unfortunately the result is not what we expected. The call tree is shown but there are no symbolic names listed: The problem is that we did not load the program symbols. This can be done by Data.LOAD.Elf tribalista.elf /NoCODE ; only load symbols Note that loading the program to the VM: is not necessary (but does not harm either) because it is loaded from the RTS file. After closing and reopening the RTS.STATistic.TREE window we get the correct output with symbols. Note the expression 1.(0/1)highlighted in red. It states that the function main() was called once 1.(../..), for main() there were zero (0/..) missing call opcodes in the trace data stream, but one (../1) missing return-from-subroutine statement. ARM-ETM RTS User s Guide 13 Use Case RTS.LOAD

14 A mismatch between analyzed CALL and RTS opcodes occurs when sampling the program flow in a bad moment i.e. when the core is just inside the function invocation: The main() function in the sample was invoked but not terminated yet. when the debugger attaches to a running system and starts the analysis inside a function call hierarchy rather than at the root. an error in the data stream Now let s have a look at the program flow itself via the RTS.List command. It works just like the Trace.List command but reads the trace data (e.g. PTM or ETM protocol data) from the file. Both commands do not load the complete file but only read the data necessary for performing the required function like rendering the Trace.List window). NOTE: For handling RTS files having some GBs in size, the use of an OS with and address space of 64 bits is required. NOTE: The long term trace method (enabled via Trace.Mode.STREAM) uses a file format that is not compatible with the RTS files. This is, because long term trace just dumps the raw trace data into a file, while RTS saves predecoded trace data and processing results. ARM-ETM RTS User s Guide 14 Use Case RTS.LOAD

15 Avoiding and Fixing Processing Errors As with normal tracing, with RTS different errors can occur. This chapter is intended to help to resolve these issues. Some background information about decoding trace protocols is provided to help understanding the process. Background on Decoding of Trace Protocols and Error Types The most important errors are flow error and no access to code. Modern trace protocols (e.g. ETMV3 and PTM) create a very compact encoding of the executed opcodes. For decoding this representation of the program flow, it is necessary to know the program image that the processor works upon. For example the PTM protocol mostly reports whether conditional branches were taken or not. If the program code is known, this information allows to reconstruct the complete program flow and deduce which opcodes between the branches were executed. For the classical trace analysis (using commands like Trace.List), the trace protocol data is recorded while the target is running, but the analysis is performed after the target stopped. When the target is stopped, the debugger can read the program image from the target memories. For RTS (using the RTS command group) the trace protocol data is already decoded (processed) while the target is running. As the debugger cannot access the program image in the target while it is running, the program needs to be loaded also to the debugger s virtual memory (which is accessed by the VM: memory access class). If all the executed program code is available in the VM and the VM s contents is in fact in-sync with the executed code, the analysis will be successful. There are some failure cases, however: Physical transmission errors of the trace protocol data due to bad signals on the trace port. This can create outright impossible trace data (patterns that should not ever occur within the given trace protocol) or invalid data that simply does not match the program flow (e.g. through bit errors in the encoding of branch addresses). For a range of target program memory, there is no representation in the debugger s VM. That means, that the debugger will report no access to code when it tries to read the opcodes from the relevant memory page the VM. The opcodes in the target s program memory are different from the opcodes in the debugger s VM. This can occur by self-modifying code (which is generally problematic to trace) or because the setup scripts did not copy the correct program image or copied only parts of the program image to the VM: The result is a flow error. NOTE: While this distinction between no access to code and flow error is generally valid, in practice there is some overlap between both cases. This is because the debugger s VM is managed in pages that are zero-initialized: if an init-script copies a few opcodes to the beginning of a page, the whole page is allocated in the VM:. Belonging to the same page, the opcodes that were not copied will appear available but incorrect (zero) and thus cause a flow error rather than a no access to code error. ARM-ETM RTS User s Guide 15 Avoiding and Fixing Processing Errors

16 Resolving Physical Transmission Errors ( Flow errors ) The first step in resolving errors with RTS (and normal trace) is to ensure correct recording of the trace protocol data. See the manual for the AutoFocus preprocessor and in particular the test focus feature for suggestions to do this. To check the trace setup do a classical trace analysis of your application: trace the execution of the program and have the debugger perform the analysis after stopping the program. Do this analysis with TRACE.ACCESS auto so that the debugger reads the program image from the target. In this test you would also discover problems with self-modifying code. Locating and Resolving Errors No access to code errors If there are errors with RTS despite a correct physical transmission, the problem is likely to be caused by missing opcodes in the VM:. For finding the problem, copy all relevant code to the VM: (as you would do for RTS), but do a classical trace analysis using Trace.ACCESS VM: : [...] RTS.OFF ; use classical trace Trace.ACCESS VM: ; simulate the access mode used on default for RTS Trace.List /Track Trace.FindAll cycle unknown /Track <execute the program> Using these settings, the debugger reads the program image from the VM: and encounters the same problems as RTS would. The advantage of performing this analysis with classical trace rather than with RTS is that Trace.List is not disturbed by errors while RTS.List (currently) has problems handling errors. Among other commands you may use Trace.List, and Trace.List VM: to compare actual target memory and virtual memory, and Trace.FindAll flowerror to locate the problems. After fixing the problems with classical trace, RTS should work without problems. If you still encounter problems, please contact Lauterbach support. NOTE: Even in mode RTS.ON, the classical trace commands like Trace.List are available. However, they only work on the latest data recorded in the analyzer s memory as RTS configures the trace memory as a FIFO. If your lucky and can stop the target quickly after a trace-related error, you may be able to identify it using the method described above. ARM-ETM RTS User s Guide 16 Avoiding and Fixing Processing Errors

17 Profiling a Target Application For profiling your application s patterns regarding executed operations and memory accesses, there is the command RTS.PROfile. It can be used only in mode RTS.ON and displays the accesses made in real-time if there is no processing back-log i.e. if the processing can keep up with the newly created data stream. NOTE: Currently, when the user interface is blocked e.g. while resizing a window with the mouse, the profiling windows will show this period as if there were no events. Once the user interface becomes responsive again, the events accumulated during the pause are shown as if they had occurred in the last observation interval. Another useful command to get a feeling for the behavior of the program is Data.List VM: /ISTAT ; note the VM: memory class specifier By using the VM: memory class specifier, the window remains alive even though the target is running and constantly updates the statistics and coverage data.. ARM-ETM RTS User s Guide 17 Profiling a Target Application

18 Processing Performance Considerations Real-time profiling processes the trace data while it is recorded. This is in contrast to classical flow trace which uploads the trace data only after the target stopped. All windows are updated while the trace is running, but there is currently no limitation that prevents them from consuming too much host processing power so that the processing threads might become too slow and cause the FIFO for the trace data to overflow. Ideally the average processing speed of the host at least equals the average rate of recorded trace data. Bursts of trace data that cannot be processed in real-time are uncritical as the trace memory of the analyzer (up to 4 GB with PowerTrace II) acts as a FIFO buffering the burst data. If the average rate of data recorded at the chips trace port is higher than the processing speed, the analyzer s memory will gradually fill up and processing will stop when the buffer overflows. Therefore, generally speaking, the use of a fast host machine is advisable. In the following sections we present some more detailed considerations on performance requirements and finding performance bottlenecks in the processing system. Requirements for Processing Resources The following table compares the effect of various RTS-options to the default settings (OFF) regarding the amount of generated trace data and the required real-time processing resources. The effect of the option is encoded as follows: 0 : option is neutral, + : some increase, ++ : big increase in required resources: amount of created trace data required real-time processing resources RTS.NestingMode.FLAT 0 0 RTS.NestingMode.TREE 0 + RTS.TImeMode.Sampling 0 + RTS.TImeMode.CycleAccurate RTS.FileMode.SUMMARY 0 0 RTS.FileMode.TASK 0 + RTS.FileMode.FULL 0 ++ RTS.FileCompression.LOW 0 + ARM-ETM RTS User s Guide 18 Processing Performance Considerations

19 RTS.FileCompression.MID 0 + RTS.FileCompression.HIGH 0 ++ Assessing the usage of the host s processing resources There is a number of commands to assess how much performance and I/O bandwidth the debugger is currently using. For using them take in consideration that the processing works in a pipelined manner and the slowest part of the pipeline will limit the overall processing speed. The stages of the processing pipeline are: recording data from the target (analyzer + preprocessor) transfer of data from analyzer to the host (via ethernet or for slow systems via USB) processing the data (optionally) writing the predecoded trace data to an RTS file PROFILE.STREAMTHREAD PROFILE.STREAMIN PROFILE.STREAMOUT PROFILE.STREAMCOM PROFILE.STREAMBUFFER PROFILE.STREAMFILE Time used by the processing threads data entering into the processing pipeline data leaving the processing pipeline after processing data transferred from the analyzer to the host fill level of the FIFO for trace data (must not overflow) data written to RTS file ARM-ETM RTS User s Guide 19 Processing Performance Considerations

20 Current Limitations Requires ETMv3 or Coresight in the target (support for ETMv1 will just be added on customer demand). Some features are not yet supported with PTM (RTS.List, RTS.ListNesting). Only 8bit or 16bit trace port (other trace port sizes are possible in the future, but will just be added on demand). Only normal mode - no wrapped or continuous modes. (will be added when needed, SMP support will also be added). Only simple function nesting is supported - some compiler or kernel constructs may produce stack overflows or underflows. Over the time we will implement also the complex call/return handling of the regular statistic commands, but this will take time. Currently RTOS awareness supports only static model, i.e. tasks must already exist when RTS is enabled and are not deleted during the trace. Sampling based timestamping is only supported for regular ARM ETMs. It will not work for Coresight or CoresightSingle ETMs. Trace speed is limited by transfer bandwidth to the host (about 50-70MB/second). Hardware based compression is planned to support higher speed targets or cycle accurate modes (target is 500MB/second) ARM-ETM RTS User s Guide 20 Current Limitations

21 Troubleshooting Empty result windows or invalid results When the windows showing analysis results (e.g. RTS.STATistic.TREE, RTS.ISTATistic.LM) are empty, check the following: Be sure to copy the program code to the debugger s VM before starting the trace session. This is necessary so the debugger can analyze the trace data in real-time. See the Quick Start Guide for details. If the RTS.STATistic.TREE window is empty, be sure that nested mode was enabled while recording the data (see RTS.NestingMode.TREE). In cycle accurate mode (RTS.TImeMode.CycleAccurate), if time values (min, max, execution) do not make sense, check that you configured the frequency of the trace clock frequency: TRACE.CLOCK <cpu_frequency>.mhz Note the trailing decimal point. after the number specifying the frequency. Empty windows RTS.LIST or RTS.ListNested The list windows RTS.List and RTS.ListNesting exclusively work on trace data stored in an RTS file. Therefore they require the setting RTS.FileMode FULL. Note that the command can be used in the modes RTS.ON and RTS.LOAD. With RTS.ON the data is read from an RTS file that is just being recorded. With RTS.LOAD the data is read from a file that was recorded previously. Flow Errors RTS requires a trace stream without flow errors, especially for the more complicated analysis of the call tree hierarchy. Therefore before attempting an RTS session, be sure that classical flow trace recording works without flow errors. You may want to use the auto-configuration feature of the AutoFocus preprocessor and the focus test command Analyzer.TestFocus to achieve this. If you get flow errors in RTS, even though classical tracing works perfectly, please check that really all executed program code is present in VM. This includes exception vectors and interrupt handlers etc. ARM-ETM RTS User s Guide 21 Troubleshooting

22 If the problem is caused by opcodes that are missing in VM: you can localize the spot using RTS.List. The listing of the program flow stops at the address of the flow error. NOTE: Single stepping through code with RTS enabled, some times causes flow errors. This is a known problem caused by optimizations for the typical use case of RTS i.e. tracing a running target in real-time. Error: No access to code As outlined earlier, real-time profiling requires that all executed code is copied to the debugger s VM: for the analysis. If the debugger encounters an address in the trace stream that is not present in the VM:, it outputs a No access to code error. In the RTS.LIST window these errors are shown as unknown in the column cycle. It is mandatory that the code is available at the time of processing the trace-data and thus while the program is running. As a rule of thumb all code should be present in the VM: before starting the program. If program code is copied to the VM: after starting the program, it may be too late and cause hard to find No access to code errors. For resolving No access to code errors please refer to section System Setup for Real-Time Profiling. Warning: RTS.ON: There is no program code in the debugger s VM... In order to decode the trace data stream, the debugger needs to know the executed program code. Therefore, before enabling RTS, copy all code that might be executed to VM:, including exception and interrupt vectors. Only if there is no program code at all in the VM:, the debugger issues a warning. Note, however, that the absence of this warning by no means indicates that all required code was present. See the Quick Start Guide for a setup example. Error: Streaming not possible in this configuration You will get this error message, if you try to enable RTS (via RTS.ON or via the RTS.state window) before the debugger is attached to the target (SYStem.Mode.Up). ARM-ETM RTS User s Guide 22 Troubleshooting

23 Another reason is that any of the following requirements is not met: a CombiProbe or a PowerTraceII with preprocessor AutoFocus I or II. an ETM port size of 4, 8, or 16 bits. ETM needs to be enabled ARM ETMV3 or ARM PTM ARM-ETM RTS User s Guide 23 Troubleshooting

24 Locked commands and disabled dialog controls While in streaming file load mode (activated by RTS.LOAD) or in mode RTS.ON, some commands are locked and the corresponding dialog controls are disabled. Examples are commands for selecting the detail level (RTS.NestingMode, RTS.TImeMode, RTS.TASKMode) and file modes (RTS.FileMode) and commands like ISTATistic.SAVE. In mode RTS.LOAD, also the control for RTS.ON is disabled to avoid accidentally overwriting the existing RTS file. For unlocking these features execute RTS.OFF. ARM-ETM RTS User s Guide 24 Troubleshooting

25 Glossary Classical flow trace: recording of flow trace data into a buffer memory in the analyzer. In the classical setting, the trace data is analyzed only after the target stopped whereas with real-time profiling the analysis is done in parallel to recording. Debugger virtual memory: a memory area implemented in the debugger instead of in hardware (thus called virtual memory ). In the context of trace analysis the VM: can be used to hold a copy of the program image so that the trace analyzer can access it even thought the target is running (which often prevents reading the target memories). Flat mode: the debugger only gathers information on executed instructions, not taking into account the call graph (function call hierarchy). Flow errors: a flow error is shown when the program flow reconstructed from the trace data does match the program in memory e.g. if the protocol reports a branch but there is not branch in the code. This can happen due to bit errors caused by incorrectly recorded trace data or due to changes in the program code (selfmodifying code). Hard errors: a hard error is reported, when the trace data stream contains byte patterns that would never be generated by the ETM. This can happen due bit errors caused by incorrectly recorded trace data. Nested mode: the debugger calculates the function nesting i.e. the call graph (function call hierarchy). This can happen due to bit errors caused by incorrectly recorded trace data. Real-time profiling (RTS): records, processes, and optionally stores trace data, while the target system is running and emitting new trace data. Real-time streaming is a deprecated term for real-time profiling. The term Real-time Streaming was changed to Real-time Profiling to avoid confusion with the trace mode STREAM. See trace mode STREAM. Trace mode STREAM: a long-time trace storage that allows to record and analyze amounts of trace data beyond the physical memory available in the trace tool (currently up to 4GB) by streaming the data to the hard-disk. ARM-ETM RTS User s Guide 25 Glossary