TDT 1.2 Release Notes and FAQ March 2002 This document gives additional information about the use of the ARM Trace Debug Tools TDT 1.2 (build 1031) For more information, please see the Trace Debug Tools User Guide. Frequently Asked Questions 1) Which buffer board do I need to collect trace from my ARM core module? There are two possible pinouts for single processor ETM target connector. This are type A and type B. Most boards have type B connectors. The following table summarizes the connector pin-out type for various ARM target boards. Target ARM Part No. Pin-out type CM7TDMI * HPI-0056A A CM7TDMI * HPI-0056B A CM9x6E-S HPI-0066A A CM9x6E-S HPI-0066B, C or D B CM9x0T HPI-0070A, B or C B LM-XCV400+ HPI-0059A A LM-XCV400= HPI-0059B A LM-XCV600E+ HPI-0072B B LM-EP20K600E+ HPI-0073A B * Non-standard configurations contact ARM for further information. Specific Trace Capture hardware and supported pinouts. ARM MultiTrace: The ARM MultiTrace supports pin-out type B only. Agilent E5904B option 300: This Trace Port Analyser is designed to work with Pin-out type B. (In Agilent terminology type C). How ever type A (In Agilent terminology type A&B) pin-outs may be supported by requesting a suitable buffer board part number E5903-66516 from Aglient support. Tektronix Logic Analysis Systems: These system are designed to work with pin-out type B only. 2) Where are the gateway and gateway2 dlls? Software for connection to Agilent emulation probes is no longer shipped with TDT. Support for Agilent emulation probes is available through the ARM ADI product. Please contact your sales representative for further information. 3) When is the syntax of an address entered through the tabbed sub-window
of the configure capture dialog checked? If you modify the addresses in a rule using the tabbed subwindows in the configuration capture dialog the syntax of the address is not checked until you finish working on the subwindow. The syntax is checked when you do one of the following: - Click on a different rule in the rules subwindow. - Click on a different tab for the current rule. - Press the OK button to complete defining the rule set. 4) When are counters decremented? Counters are decremented on every cycle for which the decrement counter rule evaluates to TRUE. In particular a counter that has a rule that is true when the execute address is within an address range will count the number of cycles executed, not the number of instructions executed, within that address range. A counter with a rule of the form if [TRUE] then Decrement Counter will decrement every cycle, even if the processor is in debug state. As such a rule of this form is unlikely to be useful. [DE 38137] 5) Why does "Stall processor to prevent overflow" not work on my system? This option will only work if the ASIC you are using supports it. While the software can find out whether the ETM itself contains the logic to support this, it can not tell whether the FIFOFULL signal output by the ETM is connected to the external logic required to stall the processor. As such TDT may enable this option when your hardware does not actually support it. Refer to your ASIC documentation to find out whether your hardware fully supports this option. [DE 35993] 6) How do I use a data comparator to test for particular values in byte or halfword memory accesses? When using a data comparator the filter and test value will be applied to the whole data bus. As such, if you wish to act on the processor reading or writing a single byte or halfword you must know which byte lane or lanes the data will be in and set the comparator value and filter appropriately. For example, on a little endian system, byte accesses to address 0x22 will occur on byte lane 2, so to check for the value 1 being read or written from address 0x22, set the data value to 0x00010000 and the filter to 0x00ff0000. 7) What do the index number in the trace window mean? The absolute values of the index numbers are meaningless, however, when using cycle accurate mode, the difference between two consecutive index number tells you how many cycles the second instruction took to execute. If there is a trigger point in the trace then this always has an index number of 0. Index numbers following the trigger point are positive and increase with distance from the trigger point. Index numbers before the trigger point are negative and decrease with distance from the trigger point. Note that if you are not using cycle accurate tracing then nothing useful can be deduced from the difference between two consecutive index numbers. [DEs 37319, 40557, 46317] 8) Where is the trigger? The record on which the trigger occurred will always have index 0. This record will only be in the trace window if an instruction was traced on the trigger cycle.
Otherwise the trigger will have occurred between the last record with a negative index and the first record with a positive index. Note that triggers are not precise, and may occur a few cycles before or after their requested position. [DE 46315] 9) Why do I get synchronisation lost errors at the beginning of an XScale trace output? Debug control of the XScale core is accomplished using a monitor which is downloaded onto the target. The monitor cannot avoid some of itself being traced just before it returns control to the previously executing image. The monitor is not part of the image loaded into the debugger thus TDT does not have information about it. The instructions therefore cannot be decompressed hence the error message. [DE 97360] 9) Why might I see a large discontinuity in the trace after FIFO overflow? If the ETM s FIFO overflows and, when the FIFO has emptied, the instruction that caused the overflow is still being executed, the ETM can produce incorrect trace. TDT will detect and recover from this condition if it can. If recovery is not possible then TDT will suppress trace until it can guarantee correctness. This behaviour may be switched off if you wish to see the possibly incorrect trace anyway. In particular the ETM may trace the instruction both before and after the FIFO overflow, and if data is being traced it may trace the data, and data addresses, incorrectly after the FIFO overflow. The data tracing will be correct following the next indirect branch, but the traced data addresses may be incorrect for up to 1024 cycles following the FIFO overflow. This problem is only likely to occur on cached processors with very slow memory systems. [DE 45267] Release notes Trace display inconsistent with processor activity 1) Interrupts and prefetch aborts traced early When the processor takes an interrupt or prefetch abort the ETM will sometimes trace the branch to the exception vector one or two cycles early. When this happens the trace output may show the wrong instruction as having been interrupted or aborted. In addition, the last instruction executed before the interrupt or abort may be missing from the trace. In the case of an interrupt, the instruction actually interrupted may often be determined by examining the address at which execution continued when the interrupt handler exited. [DE 34137] 2) Incorrect Trace paused messages When using a system containing an ETM9 rev 0 the trace window will occasionally display Trace paused instead of Debug state. This is due to a fault in ETM9 rev 0, which is fixed in rev 0a and later revisions. [DE 36297] 3) FIFO overflow not reported at end of trace When using an ETM7 rev 0 or an ETM9 rev 0 or rev 0a the tools will sometimes fail to report overflows at the end of the trace output. This happens if trace never restarts after the ETM FIFO has overflowed (e.g. because trace is disabled before
the ETM has recovered from the FIFO overflow). In these circumstances the tools cannot tell that the FIFO has overflowed or that any data has been lost, and will not report the FIFO overflow. This is not a problem when an ETM7 or ETM9 rev 1 since with these versions of the ETM the tools are able to check the state of the FIFO when tracing stops. [DE 37319] 4) Incorrect output following semihosting call When semihosting is enabled SWI instructions in the trace output may be followed by a Synchronization Lost message, or by a corrupt instruction. This will only happen on systems containing an ETM9 rev 0 or 0a, and is caused by the ETM9 generating spurious data when it enters debug state. No data is missed from the trace output, so this error may be ignored. [DE 38023] 5) Last instruction before a breakpoint may not be traced The last instruction executed before the processor stops at a breakpoint will often not be traced. In particular if you try to trace while single stepping instructions in AXD you will often get no output. Miscellaneous problems with TDT 6) Stopping execution while logging to file may not work It may not be possible to stop execution of the target while logging trace to a file. To work round this stop the log to file, stop execution, then restart the log to file. [DE 94009] 7) Trace does not remember saved rules on per session basis AXD allows you to save sessions for later recall. Unfortunately the session file will always refer to the default trace configuration (.tcf) file. It is therefore only possible restore one set of ETM configuration rules via session files. [DE 115561] 8) Time stamping state is not saved between sessions AXD does not preserve whether time stamping information has been requested between sessions. [DE 115559] 9) Counters do not reset when tracing is stopped using the ETM ARMulator ARMulator will fail to reset counters if tracing is stopped then started again during execution. With hard targets counters are reset when trace is stopped. [DE 129809] 10) Synchronization of source and trace windows when scrolling upwards When scrolling down, the source window pointer moves on sensibly, but if you are scrolling upwards, the source point only moves on when you get to the instruction itself. When data trace is turned on, this may look a bit odd, because you can be scrolling over data for an instruction but with the source pointer still pointing at the following instruction. 11) Spurious DBE Warning 00048 DBE Warning 00048 occurs in the debug log window under certain circumstances. This warning may be ignored. This error is more probable when connected to an XScale target using Stop Processor when buffer full mode. [DE 42541]
12) Problems with automatic conversion of old TDT 1.0 configuration files to new (TDT 1.1 and 1.2) format. When trying to open an old (TDT 1.0) trace configuration file, you are prompted whether or not you wish to convert to new style. It is not always possible to convert the file, and an error message to this effect will be given. In this case, the file is left in its old state, and you will need to set the configuration by hand. [DE 44033] 13) Problems when changing the target during a debug session It is possible to display a rule that is not supported by the current hardware. This only occurs if one has changed the target. If the rule uses features that don t exist on the current hardware you will not be able edit these aspects of the rule. If this occurs, delete or disable the rule, and enter a rule that the current hardware supports. [DE 43571] 14) Switching target processors with Agilent emulation probes Very rarely, Agilent emulation probes can stop responding to the debugger sometime after switching between target core types in the ARM ADI target configuration window e.g. from 966E-S to 7TDMI. This causes the debugger to hang. The problem seems to occur more frequently with hot-plugging of the trace hardware. You are advised to avoid hot-plugging if this is possible. If the problem occurs, close the debugger and power-cycle the target hardware. [DE 36539] 15) Performance problems when using Agilent Logic Analyzers When using an Agilent Logic Analyzer as a trace buffer certain performance problems may occur. Single stepping will be very slow. It may take up to two minutes to display the first trace output after tracing stops. [DE 37901] 16) Wrong error message if TDT license is incorrect If you do not have a valid, and correctly installed, license for TDT, and configure the TDT version of AXD to use a trace buffer, then, when you finish configuring AXD it will give an incorrect error message. This message will say that it is unable to connect to the target, and will not tell you that the license is invalid. AXD will only tell you that it is unable to find a TDT license when you restart it. [DE 44829] 17) Problems with tracing exceptions In many programs, the exception vectors do not form a part of the image, but are written to memory by the program. As such, while the program is running TDT does not know their contents and cannot decompress the instructions in the exception vectors. Furthermore, when exception is traced the trace decompresser will lose synchronization and will not regain it until an indirect branch occurs in the trace stream. As such, if the exception vectors contain direct branches to the exception functions, then these functions will not be traced. There are a number of possible workarounds for this problem: a) Stop the program, and reload trace (using the reload trace option from the trace window context menu). b) Build an image that includes the exception vectors, and load this into the debugger using load symbols only. c) Modify the code to contain indirect branches in the exception vectors.
d) Trace only the exception functions. The trace decompresser can always synchronize when tracing starts or restarts. Note that just disabling tracing of the exception vectors will not work, since the ETM will ignore attempts to disable trace for very short periods. [DE 44985] 18) Setting the buffer size and buffer size changes If you set the buffer size in the Configure ETM window then this is not checked for validity until you (re)start tracing. Also, if any other changes in trace configuration change the buffer size, then you will not see these changes until you start tracing. In particular, if you are using MultiTrace in certain modes the buffer size depends upon the port width, but you will not see the buffer size changing until you restart tracing after changing the port width. [DE 45281] 19) Changing column widths corrupts scroll bar on Windows 95 On Windows 95, if you change the width of the columns in the trace window the scroll bar slider will move, and will no longer reflect the position in the trace buffer. To correct this press the Page Up or Page Down key. [DE 46487] Tips on using TDT 20) Image format You are strongly advised to use the default ELF format, not (obsolete, SDT) AIF format, images when using TDT. Trace output will be very slow if you are using AIF format images. 21) ELF/DWARF image required to decompress trace data from a running program You must load an ELF/DWARF image (a.axf file) into the debugger before decompressing any trace output. If you try to collect trace on a running program without loading any symbols (either by connecting to a running target, or by setting the PC and then running the target) the resulting trace will fail to decompress. To fix this; load the appropriate image using Load symbols only then select the Reload trace menu item on the Trace menu. If you try to decompress trace output for a stopped program without first loading an image into the debugger the decompression may be very slow. [DE 34445] 22) Use of cycle accurate tracing If cycle accurate tracing is used with a target system containing a rev 0 or rev 0a ETM then, if tracing is enabled, the TPA will capture all cycles that occur while the processor is in debug state. This can rapidly fill the TPA s buffers, hence preventing the collection of useful trace information. To avoid this problem, either disable cycle accurate tracing, or set the Trace Enable condition such that the ETM only traces areas of the code that do not contain any breakpoints. For example, tracing the instructions within a single function with cycle accurate tracing enabled will normally work correctly, but tracing all executed instructions will normally fail. Depending on the configuration of the debugger, tracing exceptions and SWIs will normally fail, since the debugger, by default, puts breakpoints on the exception vector. [DE 33903]
23) Rule "if true trigger (and stop)" does not stop program If you specify a rule of the form "if [TRUE] then Trigger (stop on trigger)" then the program will not stop unless it is already running when the rule is defined. The reason is that the break signal is generated before the program starts running, and as such is ignored. [DE 38139] 24) Use of Real Monitor with trace When using Real Monitor with trace hitting a breakpoint will not stop tracing or cause the collected trace data to be displayed. To stop tracing either stop it explicitly using stop tracing from the trace menu, or configure tracing with a trigger condition. Also note that, using the rule if [TRUE] then Enable Tracing the ETM will trace the real monitor code as if it were normal application code. This can be avoided by setting an address range on the Enable Tracing rule that excludes the Real Monitor code. [DE 44751] 25) Resource counts during rule definition When defining a rule the dialogs show all resources not used by that rule as available, even if some are already allocated to other rules. This allows you to define two rules that use the same resources, and then choose which to enable, but can be misleading when defining a set of rules that are intended to work together. [DE 44989/45575] 26) Non-stop debugging and semihosting The semihosting C library expects a debugger to be continuously connected to the target. If your program uses semihosting calls or SWIs, and you disconnect AXD from the target, and then attempt to reconnect without stopping the target, you are likely to find that your program has crashed, or stopped at a breakpoint. Even if it has not done so, the semihosting C library does not support connection to a running program, so semihosting calls may not work after you reconnect. [DE 47153] 27) Decompressing undecompressible trace output If some parts of the trace output are not decompressible, for example because AXD does not know the contents of the associated memory, AXD will still attempt to decompress the remainder of the trace. Under these conditions AXD does, however, have to restart the decompression algorithm following every undecompressible cycle. Consequently, it may take a very long time to save a large trace containing a lot of undecompressable trace output to a file. [DE 47061] 28) ETMs with incorrect SYSOPT input Some ASICs containing rev1 ETMs incorrectly tie the ETM s SYSOPT bus to 0. This can never be a correct value for SYSOPT, since it is telling the software that the ASIC does not support any trace port configurations. When TDT1.1 detects such an ASIC it will allow you to set any trace port configuration supported by the trace buffer. In this case the software cannot check that the ASIC actually supports the configuration you set, so you are advised to check in the ASIC s documentation what configurations it supports. [DE 47209] 29) No trace appears with Real Monitor when foreground task is stopped If you are using trace with real monitor, and you stop the foreground task, then the trace window will not update (even if trace has triggered) until some other window is
refreshed. To avoid this problem, enable timed refresh in the Configure Interface dialog box. [DE 48510]