Freescale S12X Family In-Circuit Emulation

Transcription

1 _ Technical Notes V Freescale S12X Family In-Circuit Emulation Contents Contents Introduction Differences from a standard environment Common Guidelines Port Replacement Information Emulation Options Hardware Options CPU Configuration Power Source and Clock Initialization Sequence Synchronisation of Two or More Emulators Setting CPU options CPU Options Debugging Options Advanced Options Memory Expansion Debugging Interrupt Routines Memory Access Access Breakpoints Trace On-Chip Trace On-Chip Trace & Access Breakpoints Troubleshooting Scenarios Active Trace Troubleshooting Scenarios Execution Coverage Profiler Functions Profiler Data (OSEK) Profiler Emulation Notes isystem, May /70

2 1 Introduction Debug Features Unlimited Breakpoints Access Breakpoints Real-time Access Trace Profiler Execution Coverage 1.1 Differences from a standard environment The In-Circuit Emulator emulates the target CPU, which is removed from the target, as good as possible. Beside the CPU, additional logic is integrated on the POD. The amount of additional logic depends on the emulated CPU and the type of emulation. A buffer on a data bus is always used (minimal logic) and when rebuilding ports on the POD, maximum logic is used. As soon as the POD is connected to the target instead of the CPU, electrical and timing characteristics are changed. Different electrical and timing characteristics of used elements on the POD and prolonged lines from the target to the CPU on the POD contribute to different target (the whole system) characteristics. Consequentially, in worst case signal cross-talks and reflections can occur due to bad target connection, capacitance changes, etc. Beside that, pull-up and pull-down resistors are added to some signals. Pull-up/pull-down resistors are required to define the inactive state of signals like reset and interrupt inputs, while the POD is not connected to the target. Because of this, the POD can operate as standalone without the target. 1.2 Common Guidelines Here are some general guidelines that you should follow. Use external (target) Vcc/GND if possible (to prevent GND bouncing), Make an additional GND connection from POD to the target if the Emulator behaves strangely, Use the reset output line on the POD to reset the target whenever Emulator resets the CPU, Make sure the appropriate CPU is used on the POD. Please refer to the POD Hardware reference received with your POD. No on-chip or external watchdog timers can be used during emulation (unless explicitly permitted). Disable them all. 1.3 Port Replacement Information In general, when emulating the single chip mode, some ports have to be rebuilt on the POD because original ports are used for emulation typically ports used as address and data bus in extended mode. Standard integrated circuits are used to rebuild "lost" ports. Rebuilt ports are logically compatible with original CPU s ports, but electrical characteristics may differ. The differences may become relevant when standard integrated circuits are used and operating close to electrical limits, e.g. when input voltage level is close to specified maximum voltage for low input level ( 0 ) or specified minimum voltage for high input level ( 1 ) or if, for example, the target is built in the way that the maximum port input current must be considered. isystem, May /70

3 2 Emulation Options 2.1 Hardware Options Clear Emulation Memory Active Emulator Options dialog, Hardware page This option allows you to force clearing (with the specified value) of emulation memory after the emulation unit is initialized. Clearing emulation memory takes about 2 seconds per megabyte, so use it only when you want to make sure that previous emulation memory contents don't affect the current debug session. isystem, May /70

4 2.2 CPU Configuration With In-Circuit emulation besides the CPU family and CPU type the emulation POD must be specified (some CPU's can be emulated with different PODs). CPU Setup Active Emulator Options dialog, CPU Configuration page Opens the CPU Setup dialog. In this dialog, parameters like memory mapping, bank switching and advanced operation options are configured. The dialog will look different for each CPU reflecting the options available for it. Set Default This button will set default options for currently selected CPU. These include: Vcc and clock source and frequency Advanced CPU specific options Memory configuration (debug areas, banks, memory mapping) Note: Default options are also set when the Family or a POD is changed. isystem, May /70

5 2.3 Power Source and Clock The Vcc/Clock Setup page determines the CPU's power and clock source. In-Circuit Emulator Options dialog, Vcc/Clock Setup page Note: When either of these settings is set to External, the corresponding line is routed directly to the CPU from the target system. Clock Source Clock source can be either used internal from the emulator or external from the target. It is recommended to use the internal clock when possible. When using the clock from the target, it can happen that the emulator fails to initialize. It is dissuaded to use a crystal in the target as a an external clock source during the emulation. It is recommended that the oscillator is used instead. Normally, a crystal and two capacitors are connected to the CPU's clock inputs in the target application as stated in the CPU datasheet. A length of clock paths is critical and must be taken into consideration when designing the target. During the emulation, the distance between the crystal in the target and the CPU (on the POD) is further more increased; therefore the impedance may change in a manner that the crystal doesn't oscillate anymore. In such case, a standalone crystal circuit, oscillating already without the CPU must be built or an oscillator must be used. When the clock source is set to Internal, the clock is provided by the emulator and its frequency can be set in steps of 1 khz. Note: The clock frequency is the frequency of the signal on the CPU's clock input pin. Any internal manipulation of it (division or multiplication) depends entirely on the emulated CPU. Vcc Source This setting determines whether the emulator or the target system provides a power supply for the CPU. isystem, May /70

6 2.4 Initialization Sequence Usually, there is no need to use initialization sequence when debugging with an In-Circuit Emulator (ICE) a single chip application. Primarily, initialization sequence is used on On-Chip Debug systems to initialize the CPU after reset to be able to download the code to the target (CPU or CPU external) memory. With an ICE system, the initialization sequence may be required for instance to enable memory access to the CPU internal EEPROM or to some external target memory, which is not accessible by default after the CPU reset. The user can also disable CPU internal COP using initialization sequence if there is a need for that, etc. Initialization sequence is executed immediately after the CPU reset and then the code is downloaded. The initialization sequence can be set up in two ways: 1. Set up the initialization sequence by adding necessary register writes directly in the Initialization page within winidea. 2. WinIDEA accepts initialization sequence as a text file with.ini extension. The file must be written according to the syntax specified in the appendix in the hardware user s guide. Excerpt from the sample Demo.ini file: S PTBD B 12 S PTBDD B FF //comment isystem, May /70

7 The advantage of the second method is that you can simply distribute your.ini file among different workspaces and users. Additionally, you can easily comment out some line while debugging the initialization sequence itself. There is also a third method, which can be used too but it s not highly recommended for the start up. The user can initialize the CPU by executing part of the code in the target ROM for X seconds by using 'Reset and run for X sec' option. isystem, May /70

8 2.5 Synchronisation of Two or More Emulators S12X development system allows synchronization of two or more emulators. There are two special pins on the POD: SR - synchronous reset SS - synchronous stop The corresponding pins of all Emulators must be connected together. This means that all SR pins must be connected together, and all SS pins must be connected together (but, of course, separated from each other). Synchronization Options The Emulator operation is specified in a special dialog, the 'Hardware/In-circuit emulation/synchronization' tab. Both, SR and SS line can operate independent of each other as master or slave. The user must specify the operating mode in the 'Synchronization' tab. Synchronous Reset (SR) line Master: when the CPU resets, the reset will also be broadcast on the SR line; Slave: only monitors the activity on the SR line. Synchronous Stop (SS) line Master: when the program stops, this will be broadcast on the SS line; Slave: monitors the activity on the SS line and automatically stops or goes into running depending on the messages received on the line. Both lines, synchronous reset and synchronous stop are open drain lines it means that they can operate as input or output. If you define the Emulator as master, open drain line (SR, SS) operates as output and if you define the Emulator as slave it operates as input. isystem, May /70

9 RESET Emulator Target Entry (RUN RESET) Immediate Immediate Exit (RESET RUN) 150 E cycles Immediate Note: If you are using two emulators with S12X CPU running on the same clock, they will start synchronously. Also the RESET output line on the POD is delayed until the CPU starts. You can use this line to synchronize a third CPU. Run/Stop Entry (RUN WAITING) Emulator Exit (WAITING RUN) 0-12 µs On next source line isystem, May /70

10 3 Setting CPU options 3.1 CPU Options The CPU Setup, Options page provides some emulation settings, common to most CPU families and all emulation modes. Settings that are not valid for currently selected CPU or emulation mode are disabled. If none of these settings is valid, this page is not shown. RESET from Target Enabled CPU Setup, Options page When checked, the target reset line is sensed, which can then reset the CPU while the CPU is running. Interrupts Enabled When Stopped Source step debug command is considered as a stop mode from the debugger s standpoint although it is implemented by setting breakpoints (hidden to the user) on adequate addresses and running the program up to them. This particular option refers to the stop mode, but it really impacts source step behaviour only. When the program is stopped, the CPU enters in so-called BDM mode in which the CPU cannot service any interrupt. Any pending interrupts are serviced after the program is resumed. When this option is checked, I (Interrupt Mask) flag in the CCR register is not modified by the emulator. It means that when the user program is stopped or stepped through the sources, I flag is not affected by the emulator. For instance, if interrupts are enabled and there is an active interrupt request, it will be serviced during source step. When this option is unchecked, the interrupts are disabled in stop mode. After the user program is stopped, the emulator, hidden from the user, memorizes the current I (Interrupt Mask) flag state and sets it, which result in disabled interrupts. When the user program is resumed, the emulator first restores original I flag and then resumes the program. There is no problem when the Run command is being used, but a problem can occur under certain conditions when a single step command is being used. While in stop and executing a single step in the disassembly window there are no problems. During single step in the disassembly window the emulator itself detects any instruction that changes the state of I flag and handles it correctly. For example, interrupts are active and the program is stopped. The emulator memorizes the I flag state isystem, May /70

11 and disables interrupts. Now the user executes single steps in the disassembly window and, for example, once the SWI instruction (software interrupt) is stepped. At this moment, the CPU pushes the content of the CCR register to the stack, where the Interrupt Enable flag is stored and jumps to the address where the interrupt vector points to. Before the user s program was stopped (from running), the interrupts were active (I flag cleared) and after the program was stopped, they were disabled (I flag set) by the emulator. Therefore an incorrect I flag value (CCR register) is now pushed to the stack. Since the emulator can detect such an instruction it modifies the stack with the proper I flag value. If this would not be done, the program execution would be changed after RETI instruction is executed on software interrupt routine exit. Interrupts in the user s program would now be disabled and not enabled as before while the program was running. But when using step in the source window (source step) the above problem becomes relevant and the user should never forget it. The source step is actually executed with RUN command with prior setting breakpoints on the required source lines. If for instance SWI (software interrupt) occurs during the source step execution, the CCR value with disabled interrupts will be pushed to the stack and after returning from the software interrupt routine (RETI) the same value is popped up from the stack. When the user resumes his program, interrupts are disabled and not enabled, as they were, before the program was stopped. During the source step the emulator cannot detect instructions that changes the state of I flag as it is the case with single step in the disassembly window. 3.2 Debugging Options Execution Breakpoints Debugging options The development system can use two types of breakpoints: 'Internal CPU' specifies the usage of the internal CPU breakpoint logic (also referred to as hardware breakpoints), which features four breakpoints. The main advantage of this option is that the code is not being modified; the program memory is only used for program storage. Note that the debugger, when executing source step debug command, uses one breakpoint. Hence, when all available hardware breakpoints are used as execution breakpoints, the debugger may fail to execute debug step. The debugger offers 'Reserve one breakpoint for high-level debugging' option in the Debug/Debug Options/Debugging' tab to circumvent this. By default this option is checked and the user can uncheck it anytime. isystem, May /70

12 'Emulator' specifies the usage of emulator breakpoints (also referred to as software breakpoints). This is done by code modification, where break instructions are inserted, where a breakpoint is required. The number of breakpoints is unlimited and unnoticeable to the user, unless the code integrity is being checked. 3.3 Advanced Options Operation Mode The POD supports single chip and expanded mode. Single chip mode can be emulated in two ways: Use internal FLASH Advanced options In this case, Synchronization of multiple emulators, Task breakpoints and Break on trigger functionalities are not available! Emulate internal FLASH - Internal flash is replaced by RAM overlay memory. In this case, Synchronization of multiple emulators, Task breakpoints and Break on trigger functionalities are available only when emulator breakpoints are used! Due to the CPU pitfall, S12XDP512 mask L15Y runs only up to 33MHz (ECLK) when running from the overlay memory (Emulate internal FLASH). If the target application runs at higher frequency, Use Internal FLASH mode must be used! This option is not available for S12XEP100, S12XF512 and S12XHZ512 ActivePRO PODs only Expanded mode can be emulated by running from internal FLASH (CPU is running without wait states) emulation of internal FLASH (CPU is running without wait states) running from external FLASH (CPU is running with wait states) isystem, May /70

13 emulation of external FLASH (CPU is running with wait states) When the CPU is running from internal FLASH, the FLASH is programmed during download. When FLASH (internal or external) is emulated it is replaced by emulator s RAM. Stop when XGATE stops If this option is checked, the X12 program is stopped when XGATE stops. Synchronize start from reset on The target reset signal resets the CPU immediately. However, when the target reset line becomes inactive, the CPU reset line is belayed for few hundred milliseconds by the emulator. If there is an active external watchdog, the CPU restart must be synchronized with the external watchdog. Then this option and 'RESET From Target Enabled' option must be checked. The watchdog timer event allows reset synchronization on the rising edge of external watchdog (target) reset. Note that the external watchdog must be a periodic signal (while forcing the CPU to a reset state). After the CPU starts, the external watchdog must be refreshed by the application, which ensures the target reset line not to be active. Assume target RESET When the CPU is reset by an internal CPU reset source (e.g. COP), the CPU reset line is driven actively. This reset can be detected by the emulator which extends this reset to be able to initialize and start the emulation correctly. At that point, original reset source is no longer known to the emulator and there is no way for the emulator to figure it out. However, this information is required for the emulator to fetch the program counter from a proper vector. Assume target RESET option allows the user to specify, which reset vector is fetched after the CPU reset. The emulator can assume that target reset is generated because of: external reset, which yields PC fetch from 0xFFFE Clock monitor failure, which yields PC fetch from 0xFFFC) COP Failure, which yields PC fetch from 0xFFFA) The emulator allows testing of single internal reset source at the same time. When the reset is issued by the emulator (debug reset), it will always fetch the PC from 0xFFFE. Use COP The CPU has an internal watchdog, that must be refreshed periodically, or the CPU resets. The COP can be disabled in STOP (while the CPU is stopped by BDM), which is necessary for debugging. Since the register, which turns off COP is a write-once register, the whole register must be written. Use COP is a global option with which the COP usage is selected. If this option is enabled, the option to insert COPCTL is available. If COP is enabled, the software presets the COPCTL register (address 0x003C) with the value, entered into the COPCTL field. It makes sure automatically that RSBCK (the bit that disables COP when the user's program stopped respectively when the CPU is in the BDM mode) is always active. When COP is enabled and used, the 'RESET From Target Enabled' option (chapter 3.1) must be enabled. At COP reset the CPU drives the CPU reset line, which the emulator can only recognize as target reset. When experiencing problems with the emulator when using COP, check, whether you have a correct/valid interrupt vector table. If for instance COP interrupt vector is defined by mistake as a watchdog interrupt vector, it may look like the COP resets the CPU when the interrupt occurs. isystem, May /70

14 Advanced Operation If software breakpoints are used, the program memory can be used in two ways: Task debugging. This operation mode enables task breakpoints. These are breakpoints, available only in a certain task, which can be set in the 'Debug/Operating System' dialog. Synchronization/Trace break. Normally, there is a delay when the stop command is used. This mode minimizes the time needed to stop the CPU and is used for quickly stopping the CPU. Advanced Operation setting is available only when Emulate internal FLASH operation mode is selected and Use emulator breakpoints is selected for the execution breakpoints. Clock Selection The CPU has a XCLKS pin, which controls whether a crystal in combination with the internal loop controlled Pierce oscillator is used or whether full swing Pierce oscillator/external clock circuitry is used. The XCLKS pin selects the oscillator configuration during RESET low phase. Using the development system, XCLKS signal from the target is not connected to the CPU since the same pin is used for other purposes when the CPU is operating in the emulation mode. Instead, the user must define which clock type is implemented in the target using Clock Selection setting. Make sure that Full swing Pierce oscillator or external clock source is selected when the internal emulator clock is used. 3.4 Memory Expansion This page configures the mode of the on-chip memory expansion unit. Memory Expansion isystem, May /70

15 Memory Expansion Enabled If Memory Expansion is being used, this option must be checked. According to this selection, the mapping on the POD is automatically configured. ROMHM This option sets the ROMHM bit in the MISC register. With this bit turned on, access to the Flash Memory in the area of 0x4000-0x7FFF is turned off. ROMHM=0 - The 16K byte of fixed FLASH EEPROM in location 0x4000-0x7FFF can be accessed ROMHM=1 - disables direct access to 16K byte FLASH EEPROM from 0x4000-0x7fff in the memory map. The physical location of this 16K byte FLASH can still be accessed through the Program Page window. The option must be checked, if direct access to FLASH 0x4000-0x7FFF is disabled. The ROMHM must have the same value as the user uses in his application. Erase FLASH before download When the option is checked, a mass erase of the internal flash is performed prior to the debug download. When the option is unchecked, the debugger erases only sectors which need to be programmed during the debug download. This behaviour is typically required when program flash is additionally used for the EEPROM emulation, where it may be undesired to loose the EEPROM emulation data stored in the flash due to the flash mass erase performed before the debug download. Note: This option is available for S12XEP100, S12XF512 and S12XHZ512 ActivePRO PODs only. Bank FD Mapping S12X 0xFD bank (bank address: 0xFD8000-0xFDBFFF) is a mirror picture of a logic area 0x4000-0x7FFF. The same memory area can be accessed either as a bank 0xFD or as a logical area 0x4000. The user must select this setting based on how the application is linked. Trace, profiler and execution coverage results rely on this setting. Wrong setting will yield bad results in the trace, profiler and execution coverage. 4 Debugging Interrupt Routines An interrupt routine can only be debugged when the interrupt source for this routine has been disabled; otherwise you will keep reentering the routine and thus run out of system stack. For example, there is an interrupt routine with 10 source lines. Let s assume that the interrupt routine is called periodically by a free running timer. A breakpoint is set on the first source line in the interrupt routine. Program execution stops at the breakpoint. Now source step is executed. Source step is actually executed using RUN command with prior setting of breakpoint on adequate source line. In this particular case, while source step is executed, the CPU executes the code and before the source step actually completes, a new interrupt call is generated by the timer. Consequentially new values are pushed onto the stack and the CPU stops on breakpoint again. If you repeat source steps in such interrupt routine new values are pushed to the stack and you can easily run out of stack. An interrupt source can be disabled in two ways: Disable the interrupt process when the program is stopped (stop mode) refer to chapter 3.1 describing Interrupts Enabled When Stopped option. Stop mode is entered whenever the CPU is stopped and the emulator remains in stop mode until the Run command is executed. (During Step, Step over, etc. commands, stop mode persists). isystem, May /70

16 Do not place a breakpoint on any instruction in the interrupt routine where interrupts are not yet disabled. You should also not step over any instruction that re-enables the interrupt, but run the program only up to that point. isystem, May /70

17 5 Memory Access S12X development system feature standard monitor memory access, which require user program to be stopped and real-time memory access based on BDM interface, which allows reading and writing the memory while the application is running. Real-Time Memory Access All S12X development systems feature real-time memory access. The debugger can access CPU memory without disturbing the program being executed. Using hardware commands and on-chip BDM firmware, the debugger can access required resources in real time. In general, on-chip BDM firmware uses CPU dead cycles, when real-time read or write memory access is required. In worst case, some CPU cycles might be stolen. Note: Real-time access is available only for memory, which can be accessed through single memory read/write access. Watch window, memory window and SFRs window can be updated in real time. Monitor Access When monitor access to the CPU s memory is requested, the emulator stops the CPU and instructs it to read the requested number of bytes. Since all accesses are performed using the CPU, all memory available to the CPU can be accessed. The drawback to this method is that memory cannot be accessed while the CPU is running. Stopping the CPU, accessing memory and running the CPU is an option, which, however, affects the real time execution considerably. The time the CPU is stopped for is relative and cannot be exactly determined. The software has full control over it. It stops the CPU, updates all required windows and sets the CPU back to running. Therefore the time depends on the communication type used, PC's frequency, CPU's clock, number of updated memory locations (memory window, SFR window, watches, variables window), etc. isystem, May /70

18 6 Access Breakpoints The same on-chip debug resources are shared among hardware execution breakpoints, access breakpoints and on-chip trace trigger. Consequentially, debug resources used by one debug functionality are not available for the other two debug functionalities. In practice this means that no trace trigger can be set for instance on an instruction address, when four execution breakpoints are set already. Access Breakpoints dialog Four hardware comparator combinations are available, including a match and state machine. For each comparator, the appropriate core (S12X or XGATE) can be selected and the address, area, type, access type, data and mask can be specified. Please, refer to the 7.1 On-Chip Trace and the 7.2 On-Chip Trace & Access Breakpoints Troubleshooting Scenarios sections on how to configure access breakpoints. Trace trigger and access breakpoints use the same debug resource and consequentially, the dialogs look alike. The only difference is the final action, which is either a program break or a trace trigger. isystem, May /70

19 7 Trace The development system features full CPU bus trace named Active Trace, which is implemented externally to the CPU. It s limited to the S12X bus and does not allow recording of XGATE activity. Additionally the development system supports on-chip trace, which allows recording of both, S12X and XGATE activity. Onchip trace has many drawbacks comparing to the Active Trace: small trace buffer, very limited data trace, no time stamps, limited trigger and no qualifier at all. Per default, Active Trace is recommended to be used. It makes sense to use on-chip trace only when XGATE activity must be analyzed. Trace operation mode is selected in the Hardware/Analyzer dialog. All address entries in the trace trigger & qualifier dialogs take bank address by default unless there is memory area selection next to the address item. 7.1 On-Chip Trace The same on-chip debug resources are shared among hardware execution breakpoints, access breakpoints and on-chip trace trigger. Consequentially, debug resources used by one debug functionality are not available for the other two debug functionalities. In practice this would mean that no trace trigger can be set for instance on instruction address, when four execution breakpoints are set already. S12X on-chip trace features 64 x 8 Bytes trace buffer, which can record X12 and XGATE program changes. Trace uses branch-trace mechanism. Then it s up to debugger to interpolate the program trace for sequential instructions from a local image of program memory contents. In this way, the debugger can reconstruct the full program flow. Trace can record 128 program changes when recording only X12 or only XGATE activity. 64 program changes can be recorded when recording both, X12 and XGATE activity. Reconstructed program normally contains over 1000 program instructions, which may sound a lot but in practice it s negligible considering that the code is written in C language and comparing to the size of the Active Trace buffer. Trace can record in three modes: Normal mode records all code fetches when the program fetches isystem, May /70

20 Loop mode records all program fetches except if there are two or more consecutive Detail mode records 64 data accesses. Each data access is identified by address, data, and access type (RD/WR). It cannot be found out which code caused each data access since no code fetches are recorded. Pretty complex events (state machine) can be configured for a trigger event. Depending on whether the user needs to look forwards or backwards, the trigger can be located at the beginning, at the end or in the middle of the trace buffer. Frame 0 in the trace record points to the first program change after the trigger event. Thereby, the trigger event itself is ahead from the frame 0. Moreover, the trigger event itself may not be even visible in the trace record. For instance, if a trigger is set on a data access and trace records code fetches (normal mode), no data accesses and thus no trigger event are recorded. Trace and access breakpoints configuration dialog entirely follows the trace description in the CPU datasheet and there should be no indistinctness on how to set up a trigger after reading the CPU user s manual. Trace configured to trigger on SendCANMsg execution and to record S12X activity only (no XGATE). Trace Filter The settings in this section are used to filter out unwanted results. Store S12X activity stores only S12X activity S12X and XGATE activity stores S12X and XGATE activities isystem, May /70

21 Range Specifies the range of data to be saved. All all data is saved From 0x to Comparator D all data from the beginning to the address specified in Comparator D is saved From Comparator C to 0x7FFFFF all data from the address specified in Comparator C to 0x7FFFFF is saved From Comparator C to Comparator D all data between the addresses specified in Comparator C and Comparator D is saved Trace Mode Defines the normal capture, the Loop 1 or Detail capture, as per Freescale specifications. Trigger Position Begin - yields maximum post trigger size (7/8 after the trigger) End - yields maximum pre trigger size (1/8 after the trigger) 7.2 On-Chip Trace & Access Breakpoints Troubleshooting Scenarios Following examples demonstrate on-chip trace use. Note that the same examples apply also for the access breakpoints where a trigger event becomes a breakpoint event. Trace Trigger and Access Breakpoints dialogs are almost identical since the same on-chip debug resources are used to break the CPU (access breakpoint) or trigger the trace. First, select On-Chip trace operation mode in the Hardware/Analyzer Setup dialog. This setting is not relevant for access breakpoints use. isystem, May /70

22 Example: The application writes to a memory range 0x1020-0x1040 although normally it shouldn t. Trace will trigger on first CPU write into the memory range from 0x1020 to 0x1040. Setting Mask to 0 ignores specific Data value. Trace configuration Equivalent access breakpoints configuration isystem, May /70

23 Example: The application misbehaves when an unexpected 0x08 byte is written to address 0x1064. Following trace configuration will record program around the event write 0x08 to the address 0x1064. Trace configuration Equivalent access breakpoints configuration isystem, May /70

24 Example: In the application, an unexpected 0x15 byte is written at address 0x101D. This example differs from the previous example in the address alignment. The on-chip comparator configuration is different when setting trace trigger or access breakpoint on an odd or an even address. Trace configuration Below access breakpoints configuration stops the application on first CPU byte write 0x15 to the address 0x101D. Equivalent access breakpoints configuration isystem, May /70

25 Example: I m getting an unexpected 0x150A word written at address 0x1200. Following trace configuration records the program around the event word write 0x150A to the address 0x1200. Trace configuration isystem, May /70

26 7.3 Active Trace Troubleshooting Scenarios Active Trace operation mode must be selected in the Hardware/Analyzer dialog in order to use Active Trace. First configuration is used to record the continuous program flow either from the program start or up to the moment, when the program stops. The trace can start recording on the initial program start from the reset or after resuming the program from the breakpoint location. The trace records and displays program flow from the start until the trace buffer fulfills. As an alternative, the trace can stop recording on a program stop. Continuous mode use allows roll over of the trace buffer, which results in the trace recording up to the moment when the application stops. In practice, the trace displays the program flow just before the program stops. The program can stop due to a breakpoint hit, an erratic state of the CPU or a stop debug command issued by the user. Example: The application enters unexpectedly in a halted mode (sleep mode, power down mode) during normal program execution. Such cases can be investigated only by using the trace since the CPU is no longer under the debugger s control while in halted mode. Using the trace, the course of program before the halted mode entry is recorded and the source of the unexpected entry can be found. Select Record everything operation type in the Trace configuration dialog and make sure that Continuous mode option is checked to ensure that the trace buffer rolls over while recording the running program. The trace will stop as soon as the program execution is stopped. Select minimum or maximum buffer size depending on the required depth of the trace record. Have in mind that the minimum buffer uploads faster than the maximum. With these settings, the trace records program flow while it s running. As soon as the program enters halted mode or is stopped due to any other reason, the trace stops recording. The source of the problem can be analyzed easily since the program flow before the program stop is recorded. isystem, May /70

27 Trace Configuration dialog Simple triggers and/or qualifiers set on a data being accessed or an instruction being executed are described in the following five examples. If it s required that the trace trigger event breaks the program, check the On trigger break execution option in the Trace Configuration dialog. Example: The trace starts recording after the Type_Struct function is called for the fifth time. Select Use trigger/qualifier operation type in the Trace configuration dialog, add and name a new trigger (e.g. AddressTrigger), and open Trigger and Qualifier Configuration dialog. Trace Configuration dialog isystem, May /70

28 Select n*b for the trigger condition. When the trigger on a first occurrence is required, A can be selected instead of n*b in the trigger condition field. Set Type_Struct entry point for the event B and set 5 in the counter field. When configuring an event on a code, select OP-CODE Fetch access type for the Control Item to obtain correct results, which may otherwise be distorted due to the CPU pipeline queue. Select either Memory Write or Data Read access type when configuring an event on a data. If the minimum buffer size is selected (default selection) and the trace buffer was filled completely, then a first half of the trace buffer contains program executed before the trigger and a second half contains program executed after the trigger. When a maximum buffer is selected, the trigger position can be set at the beginning, center or at end of the trace buffer. Set the position based on your particular case since the code being of interest can be executed after or before the trigger event. The trace is configured. Initialize the complete system, start the trace and run the program. Trigger and Qualifier Configuration dialog Let s inspect the results. Trigger point (frame 0) holds fifth Type_Struct function entry. isystem, May /70

29 Trace Window results Example: The code writing 0x166 to the icounter variable needs to be analyzed. The same trace configuration can be used to verify that the variable never gets written 0x166 as for instance expected from the application. In such case, the trigger would never occur normally. Select Use trigger/qualifier operation type in the Trace configuration dialog, add a new trigger and open Trigger and Qualifier Configuration dialog. Select A for the trigger condition. Configure 0x166 memory write to the icounter variable as the event A. Set icounter address in the Address Item dialog and check the Cover entire object range option. Event A Address Item dialog isystem, May /70

30 Next write a value in the Data Item dialog and select proper data size. Maximum Data Item size is limited by the CPU architecture. Only 8 and 16-bit values are valid and can be monitored properly in case of 16-bit CPU. Correct triggering on 32-bit variable requires code arming. Event A Data Item dialog Set Memory Write cycle type in the Control Item dialog. The trace is configured. Initialize the complete system, start the trace and run the program. isystem, May /70

31 Trigger and Qualifier Configuration dialog If a 0x166 write to the icounter variable occurs, the trace triggers and displays the code that caused the write. Trace results isystem, May /70

32 Example: Timer2Int routine only is recorded. Select Use trigger/qualifier operation type in the Trace configuration dialog, add a new trigger and open Trigger and Qualifier Configuration dialog. Select Anything for the trigger condition and Q event for the Qualifier. Define Timer2Int routine for the event Q. When configuring Address Item for the event Q, select Timer2Int routine from the Symbol Browser and check Cover entire object range option. By doing so, the Address Item is configured on a range bounded by Timer2Int entry point and Timer2Int exit point. A range size is displayed below the option, being 150 bytes for Timer2Int routine. The trace is configured. Event Q Address Item dialog isystem, May /70

33 Trigger and Qualifier Configuration dialog Initialize the complete system, start the trace and run the program. The trace records Timer2Int routine activity only. Example: Trace monitors the value of icounter variable while the application is running. Select Use trigger/qualifier operation type in the Trace configuration dialog, add a new trigger and open Trigger and Qualifier Configuration dialog. Select Anything for the trigger, Q event for the Qualifier. Configure write to icounter variable as the event Q. Set icounter address in the Address Item dialog and check Cover entire object range option. Next, set Memory Write for the bus cycle type in the Control Item dialog. The trace is configured. isystem, May /70

34 Trigger and Qualifier Configuration dialog Initialize the complete system, start the trace and run the program. The trace records all writes to icounter variable. Trace results isystem, May /70

35 Example: In this example, the trace triggers on rising edge of an external signal. The trace can trigger on an external event through an optional AUX Card, where the external signal must be connected. Select Use trigger/qualifier operation type in the Trace configuration dialog, add a new trigger and open Trigger and Qualifier Configuration dialog. Select A condition for the trigger and keep default Everything condition for the Qualifier. Configure AUX condition within the A event area. 1 matches with rising edge and 0 matches with falling edge of the external AUX signal. Trigger and Qualifier Configuration dialog isystem, May /70

36 Advanced Triggers The development system offers several advanced trigger and qualifier configurations: Watchdog Trigger Duration Tracker Q between B and C Pre/Post Qualifier Data Change Watchdog Trigger A standard trigger condition, logically combined from events A, B and C, is not used to trigger directly the trace, but it s responsible for keeping a free running trace watchdog timer from timing out. The trace watchdog timeout is adjustable. When the trace watchdog timer times out, the trace triggers and optionally stops the application. The problematic code can be found by inspecting the program flow in the trace history. Typical use: If the application being debugged features a watchdog timer, the trace watchdog trigger can be used to trap the situations when the application watchdog timer times out and resets the system. Typically, a trace watchdog reset condition is configured as a memory write to a specific memory location (e.g. watchdog register), which resets the watchdog timer to the start of a new time-out period. In case of the external watchdog timer being reset by the target signal, the external trace (AUX) input, where the signal must be connected, is configured, instead of a memory write. Time-out period of the trace watchdog timer must be set less than the period of the application watchdog so the trace can stop the application just before the application watchdog times out and resets the system. If the application itself doesn t feature a watchdog mechanism, the trace watchdog trigger can be used to supervise the application. The user needs to determine a part of the code that is executed periodically and its execution period, while the program behaves expectedly. The code, resetting the trace watchdog timer, can be, for instance, a function or data write/read access. The execution period is set for the trace watchdog timer timeout period. When the application misbehaves, the watchdog reset code is no longer executed within the normal execution period, the trace watchdog timer times out and the trace triggers. The code being executed a definite time after the program start can be analyzed. Configuring Watchdog Trigger The user needs to enter the period of the trace watchdog timer and define the trace watchdog reset condition, which can be logically combined from events A, B and C. 1) Check the Watchdog option and specify the time-out period in the Trigger field in the Trigger and Qualifier Configuration dialog. isystem, May /70

37 Trigger field 2) Next, define the trace watchdog reset condition. Typically, only the event A is selected for the trace watchdog reset condition and then e.g. a CPU memory write or a reset watchdog routine, resetting the watchdog, is configured for the event A. Of course, a more complex condition can be set up instead of the event A only. Trigger conditions Example: Motorola S12X target application features on-chip COP watchdog, which enables the user to check that a program is running and sequencing properly. When the COP is being used, software is responsible for keeping a free running watchdog timer from timing out. If the watchdog timer times out it s an indication that the software is no longer being executed in the intended sequence; thus a system reset is initiated. When COP is enabled, the program must write 0x55 and 0xAA (in this order) to the ARMCOP register (0x3F) during the selected time-out period. Once this is done, the internal COP counter resets to the start of a new timeout period. If the program fails to do this, the part will reset. Also if any value other than 0x55 and 0xAA is written, the part is immediately reset. The COP timer time-out period is 21 ms in this particular example. It may vary between the applications since it s configurable. The watchdog timer is reset within 18 ms during the normal program flow. The trace is going to be configured to trap COP time out and stop the program before it initiates the system reset. The user can find the code where the program misbehaves in the trace history. Select Use trigger/qualifier operation type in the Trace configuration dialog, add a new trigger and open Trigger and Qualifier Configuration dialog. Select A then n*b for the trigger condition, check the Watchdog option and enter 20 ms for the trace watchdog timer time-out period. isystem, May /70

38 Configure the event A (reset sequence first part) as memory write 0x55 to the address 0x3F (ARMCOP register) and the event B (reset sequence second part) as memory write 0xAA to the address 0x3F (ARMCOP register). Following picture depicts current trace settings. Trigger and Qualifier Configuration dialog While the application operates correctly, the trace never triggers. When the application misbehaves, the trace triggers and stops the program before the system reset is initiated. If a maximum trace history is required, select maximum trace buffer size and position the trace trigger at the end of the trace buffer. Example: The application features (external) target watchdog timer, which is normally periodically reset every 54.7 ms by the WDT_RESET target signal. The trace needs to be configured to trap the target watchdog timer time out and stop the program before the system reset is initiated. Then the user can find the code where the program misbehaves using the trace history. One of the available external trace inputs (AUX0) is used, where the WDT_RESET signal from the target is connected. Refer to the hardware reference document delivered beside the emulation system to obtain more details on locating and connecting the AUX0 input. Select Use trigger/qualifier operation type in the Trace configuration dialog, add a new trigger and open Trigger and Qualifier Configuration dialog. isystem, May /70

39 Select A for the trigger condition, check Watchdog option and enter 540 ms for the trace watchdog timer time-out period. Next, configure AUX0=1 for the event A. The trace will trigger as soon as the target WDT_RESET signal stops resetting the target watchdog within 540 ms period. Following picture depicts current trace settings. Trigger and Qualifier Configuration dialog Again, while the application operates correctly the trace never triggers. However, when the application misbehaves, the trace triggers and stops the program before the system reset is initiated. If a maximum trace history is required, select maximum trace buffer size and position the trace trigger at the end of the trace buffer. Example: The code being executed 2.3 ms after the CPU start has to be recorded. Select Use trigger/qualifier operation type in the Trace configuration dialog, add a new trigger and open Trigger and Qualifier Configuration dialog. To record part of the program, which is distant from the CPU start point in a manner of time, select A->B duration tracker for the trigger condition, check the Watchdog option and enter the time when the trace triggers. Don t define anything for events A and B. This will ensure that the trace watchdog timer never resets and triggers on the first time-out that is after 2.3 ms. isystem, May /70

40 Additionally, the trace can stop the program execution after 2.3 ms by checking On trigger break execution option in the Trace Configuration dialog. This trace configuration can be used to stop the program at any time. Complete program flow around the trigger point can be recorded, or interesting parts only by using the qualifier. Q between B and C qualifier type cannot be used in this configuration. Following picture depicts current trace settings. Trigger and Qualifier Configuration dialog Start the session. Initialize the system, start the trace and run the application. Next picture shows that the assembler instruction INY, belonging to the +aa; source line of the Type_Enum function, is executed 2.3 ms after the program start. It may be a bit confusing since the assembler instruction INY holds 0 ns time stamp in the trace window. It s due to the fact that this is a trigger event, which always holds 0 ns time stamp. All recorded frames hold time stamp values relative to the trigger event respectively trigger frame. In this particular example, first instruction executed after reset (address 0xF000) holds 2.3 ms time stamp, which is correct. isystem, May /70

41 Trace results isystem, May /70

42 Duration Tracker The duration tracker measures the time that the CPU spends executing a part of the application constrained by the event A as a start point and the event B as an end point. Typically, a function or an interrupt routine is an object of interest and thereby constrained by events A and B. However, it can be any part of the program flow constrained by events A and B. Both events can be defined independently as an instruction fetch from the specific address or data write/read to/from the specific memory location or an active auxiliary signal. Trigger field Duration Tracker provides following information for the analyzed object: Minimum time Maximum time Average time Current time Number of hits Total profiled object time Total CPU time Duration tracker results are updated on the fly without intrusion on the real time program execution. Additionally, the duration tracker can trigger and break the program, when the elapsed time between events A and B exceeds the limits defined by the user. Maximum (Max Time) or minimum time (Min Time) or both can be set for the trigger condition. Set maximum time when a part of the program e.g a function must be executed in less than T MAX time units. Set minimum time when a part of the program e.g. a function taking care of some conversion must finish the conversion in less than T MIN time units. Exceeding the limit(s) can stop the application and the code exceeding the limits can be found in the trace window. Max Time is evaluated as soon as the event B is detected after the event A or simply, Current Time is compared against Max Time after the program leaves the object being tracked. Min Time is compared with the Current Time as soon as the event A is detected or simply, Current Time is compared against Min Time as soon as the program enters the object being tracked. isystem, May /70

43 Based on the trace history, the user can easily find why the program executed incorrectly. Trace results can be additionally filtered out by using the qualifier. Example: There is a Timer2Int interrupt routine, which terminates in 420 µs under normal conditions. The user wants to trigger and break the program execution when the Timer2Int interrupt routine executes longer than 420 µs, which represent abnormal behaviour of the application. Select Use trigger/qualifier operation type in the Trace configuration dialog, add a new trigger and open Trigger and Qualifier Configuration dialog. Select maximum buffer size and position the trigger at the end of the buffer. Select, A->B duration tracker for the trigger condition. Next, we need to define the object of interest. Select, Timer2Int entry point for the event A and Timer2Int exit point for the event B. Make sure you select Fetch access type for the control bus for both events since the object of our interest is the code. Check the Max Timer > option and enter 420 µs for the limit. Following picture depicts current trace settings. Trigger and Qualifier Configuration dialog isystem, May /70

44 If the program must stop when the trigger condition occurs, check the On trigger break execution option in the Trace Configuration dialog. Note that the CPU stops few CPU cycles after the trigger event due to the latency of the hardware, processing the trigger and stopping the CPU. Trace Configuration dialog Before starting the trace session, open Duration Tracker Status Bar using the trace toolbar. Existing trace window is extended by the Duration Tracker Status Bar, which displays results proprietary for this trace configuration. Duration Tracker Status Bar toolbar The trace is configured. Initialize the system, start the trace and run the application. The application either runs or it is stopped by the trace trigger since we opted for the On trigger break execution option. First, let s assume that the application behaves abnormally and the program stops by the trace trigger. It means that the CPU spent more than 420 µs in Timer2Int interrupt routine. Let s analyze the trace results. isystem, May /70

45 Trace results Go to the trigger event by pressing J key or selecting Jump to Trigger position from the local menu. The trace window shows the code being executed 420 µs after the application entered Timer2Int interrupt routine. By inspecting the trace history we can find out why the Timer2Int executed longer than 420 µs. Normally, the function should terminate in less than 420 µs. Next, let s analyze duration tracker results displayed in the Duration Tracker Status Bar. Duration Tracker Status Bar reports: Timer2Int minimum execution time was µs Timer2Int average execution time was µs Duration Tracker Status Bar Timer2Int maximum and current execution time was µs Last execution of the Timer2Int took longer than 420 µs, since we got a trigger, which stopped the program. This time cannot be seen yet since the program stopped before the function exited. The Status Bar displays last recorded maximum and current time. Timer2Int routine completed 27 times. The CPU spent 6.37 ms in the Timer2Int routine being 22.85% of the total time. The duration tracker operated for ms. If the Timer2Int routine doesn t exceed Min Time nor Max Time values, the debugger exhibits run debug status and the duration tracker status bar displays current statistics about the tracked object from the start on. Status bar is updated on the fly while the application is running. isystem, May /70

46 Note 1: Events A and B can also be configured on external signals. In case of an airbag application, the event A can be a signal from the sensor unit reporting a car crash and the event B can be an output signal to the airbag firing mechanism. Duration tracker can be used to measure the time that the airbag control unit requires to process the sensor signals and fire the airbags. Such an application is very time critical and stressed. It can be tested over a long period using Duration Tracker, which stops the application as soon as the airbag doesn t fire in less than TMIN and display the critical program flow. Note 2: Duration Tracker can be used in a way in which it works like the execution profiler (one of the analyzer operation modes) on a single object (e.g. function/routine) profiting two things, the results can be uploaded on the fly while the CPU is running and the object can be tracked over a long period. Define no trigger and the duration tracker updates statistic results while the program runs. Q between B and C events In this configuration, the trace records particular CPU cycles, which are executed within the specific area defined by start and stop condition. Example: The user wants to record memory writes to the icounter variable within the Type_Pointers function only. Select Use trigger/qualifier operation type in the Trace configuration dialog, add a new trigger and open Trigger and Qualifier Configuration dialog. Select Q between B, C events in the Qualifier combo box. Event B represents start and the event C stop trace recording condition. Recorded CPU activity can be further filtered out by the qualifier event Q. Qualifier field Configure Type_Pointers entry point for the event B and Type_Pointers exit point for the event C event. Finally, configure icounter memory write cycle for the event Q. As soon as the event B occurs, the trace starts considering the qualifier Q and records the CPU cycles matching with the Q condition until the event C. Event B represent enable and event C disable condition for the qualifier Q. isystem, May /70

47 Trigger and Qualifier Configuration dialog Next picture shows the trace results. icounter variable is modified by the Type_Pointers function approximately every µs. Trace results Due to the CPU behaviour, it s possible that the icounter memory write is not recorded by the trace (at current trace settings) although being modified by the application. Let s assume that we have a following function: isystem, May /70

48 void Type_Pointers() { char c; char *pc; char **ppc; } c='a'; pc=&c; ++c; ++*pc; ppc=&pc; ++(**ppc); ++icounter; The program flow recorded by the trace would be: Trace results isystem, May /70

49 Trace results show that icounter memory write is actually executed after the Type_Pointers function exits. Therefore, the trace configured like in the example, would not record any icounter memory write cycles although expected by the user. Pre/Post Qualifier Pre Qualifier can record up to 8 CPU cycles before the qualifier event and Post Qualifier up to 8 CPU cycles after the qualifier event. The qualifier can be configured in a standard way and then additionally up to 8 CPU cycles can be recorded before and/or after the qualifier. Qualifier field Example: The application writes to the 16-bit icounter variable from various functions. Normally, only a function Type_Pointers writes 0x32 to the icounter variable, which results in displaying a special graphic character on the LCD display connected to the CPU. However, it seems there is a bug in the application since the special character is displayed on the LCD also when the Type_Pointers is not called at all. The code writing 0x32 to the variable icounter and not belonging to the Type_Pointers function must be found. The trace needs to be configured to record 0x32 writes to the icounter. Additionally, a section of the code executed before the write needs to be recorded to be able to find the source of the write. Using filter in the trace window, the user can filter out the code, which normally modifies the icounter, and find the problematic code. Select Use trigger/qualifier operation type in the Trace configuration dialog, add a new trigger and open Trigger and Qualifier Configuration dialog. Leave the trigger set on Anything by default. Select Q event for the Qualifier and configure Record 8 samples before Q. Finally, define the event Q. Set icounter address and check Cover entire object range option in the Address Item dialog. isystem, May /70

50 Event Q Address Item dialog Enter a value in the Data Item dialog and select proper data size. Select 16 bits data size since icounter is a 16-bit variable. Event Q Data Item dialog Finally, set Memory Write for the bus cycle type in the Control Item dialog. The trace is configured. Following picture depicts current trace settings. isystem, May /70

51 Trigger and Qualifier Configuration dialog Initialize the system, start the trace and run the application. The trace records icounter 0x32 memory write cycles and eight previous CPU cycles. In this example, the trace buffer fills up slowly and the trace is stopped manually after the special character is displayed on the LCD when it shouldn t. Let s inspect the trace results. isystem, May /70

52 Trace results In the example, the trace recorded 58s of the CPU execution, which yields 8078 CPU cycles (frames). The trace buffer is quite empty comparing to the maximum possible trace buffer since there can be up to 128K frames recorded. Due to the huge amount of recorded cycles, we need to filter out all the expected CPU cycles to be able to allocate the problematic code. Some intuition is necessary to be able to find the problematic section of code. One of possible approaches will be described. Trace results show that normally Type_Pointers function exit precedes icounter 0x32 memory writes. Save the trace record at this point (File/Save As ). Next, modify the qualifier settings in a way that only one CPU cycle is recorded before the qualifier. Make another trace record with new trace settings. Qualifier field isystem, May /70

53 Trace results As before, Type_Pointers exit point precedes the memory write. We could start manually searching for a frame differing from the Type_Pointers exit point but it could take a while since the buffer can have up to 128K frames. Let s use the filter being built in the trace widow to find the problematic code. Configure filter named Filt1 set on icounter memory write and filter named Filt2 set on Type_Pointers exit point. Filter expressions: Filt1 = (Address == {#icounter}) & (Content = "Memory Write") Filt2 = Address == {Type_Pointers_EXIT_} Hide states defined by these two filters by unchecking the State View Visibility check boxes in the States and Filters dialog. Only a problematic code remains in the trace window. State and Filters dialog isystem, May /70

54 Trace results - problematic code allocated The problematic code is allocated at address 0xF1EA and 0xF26A. Double-click on the assembler instruction (first frame) or on the source line (second frame) pinpoint code being the source of the problem. If more CPU cycles than a single one before the problematic write are required, open the previously saved trace record and search for the problematic addresses 0xF1EA and 0xF26A. below picture depicts the code at address 0xF26A writing 0x32 to the icounter variable. Trace results Note: An alternative to this example is to use Q between B and C events trace configuration. Set trigger to Anything and select Q between B, C events in the Qualifier combo box. Event Q remains configured like in the example. Then configure Type_Pointers exit point for the event B and Type_Pointers entry point for the event C. The trace now records the code matching with the qualifier and not belonging to the Type_Pointers routine. isystem, May /70

55 Data Change A trigger or qualifier condition can be set on a change of a certain variable. Additionally, it can be set that the condition matches only when the data value is changing to a particular value. A single value, bit mask or a range can be entered for the value. Pre/Post Qualifier can be used supplementary. Example: The trace records every write changing the 16-bit idatachangevar value and the belonging code modifying the value. The trace has to start recording on first CPU_Pointers function call. Select Use trigger/qualifier operation type in the Trace configuration dialog, add a new trigger and open Trigger and Qualifier Configuration dialog. Select A for the trigger condition and configure event A by entering CPU_Pointers entry point for the Address Item and OP-CODE Fetch cycle for the Control Item. Select Q event for the qualifier and define event Q. Enter the address of the idatachangevar variable in the Address Item dialog either manually by writing its physical address or by picking up the idatachangevar address from the Symbol Browser. Make sure that Cover entire object range option is checked too. In the Data Item dialog, check the Monitor data value change option and set 16 bits for the Data Size since 16-bit variable is going to be monitored. Event Q Data Item dialog Select Memory Write cycle type in the Control Item dialog. isystem, May /70

56 Q Control Item dialog Finally, configure Post Qualifier to record 4 samples before the event Q. This will ensure that the code (4 CPU cycles) modifying the idatachangevar variable will be recorded too. It s up to the user to record more or less cycles before the event Q. Following picture depicts current trigger and qualifier settings. Trigger and Qualifier Configuration dialog Initialize the system, start the trace and run the application. isystem, May /70

57 Trace results Let s analyze the results. idatachangevar variable changes the value at frames -1, -6, -11. Double-click on the source line or assembly instruction before the memory write, points to the code writing a new value. Trigger point (CPU_Pointers function entry) itself is not recorded since the trigger point doesn t match with the configured qualifier condition. Memory writes modifying the variable are recorded only. Memory writes writing the same value like previous memory write are not recorded. Plain qualifier condition ( Monitor data value change option unchecked) must be used when all memory writes have to be recorded. Example: The trace has to record every write modifying 16-bit idatachangevar variable to a value 0x6 and the belonging code. Select Use trigger/qualifier operation type in the Trace configuration dialog, add a new trigger and open Trigger and Qualifier Configuration dialog. Set the trigger condition to Anything and the qualifier to Q Event. Next, configure event Q. Address and Control Item are set in the same way like in the previous example. Don t forget to check Cover entire object range in the Address Item dialog. Enter 0x6 value, check Monitor data value change option and select 16 bits data size for the Data Item. Finally, configure the Pre Qualifier. Record 4 samples before Q is set in this example. isystem, May /70

58 Below picture depicts current trigger and qualifier settings. Event Q Data Item dialog Trigger and Qualifier Configuration dialog isystem, May /70

59 Initialize the system, start the trace and run the application. Trace results The trace record shows that idatachangevar variable is modified by different code. Double-click on the source lines will point out the program section writing 0x6 to the idatachangevar variable. In this particular example, Address_TestScopes and Type_Mixed write 0x6 to the variable. isystem, May /70

60 8 Execution Coverage Execution coverage records all addresses being executed, which allows the user to detect the code or memory areas not executed. It can be used to detect the so called dead code, the code that was never executed. Such code represents undesired overhead when assigning code memory resources. The development system features a so called off-line execution coverage and real-time execution coverage. Off-line execution coverage is entirely based on the trace record. It first uses trace to record the executed code (capture time is limited by the trace depth) and then offline executed instructions and source lines are extracted by means of software and finally the results displayed. Off-line execution coverage tests the code for two metrics: statement coverage and decision coverage Real-time execution coverage covers complete CPU program space and can run infinite time, which means in practice that the application can run for days and then the execution coverage results can be analyzed. Refer to a separate Execution Coverage User s Guide for more details on execution coverage configuration and use. Trace, Profiler and Execution Coverage functionalities cannot be used at the same time since they are all based on the trace. Single functionality can be used at the time only Typical Use Keep default Active Trace operation mode selected and select execution coverage operation mode in the Hardware/Analyzer Setup dialog. isystem, May /70

61 Select off-line operation mode when there is a need for decision coverage metrics and select real-time operation mode when an infinite time operation is a major concern. In case of off-line operation mode, buffer size selection becomes available too. Next, select Execution Coverage window from the View menu and configure Execution Coverage settings. Typically, All Downloaded Code option is used. The debugger extracts all the necessary information (e.g. addresses belonging to each C/C++ function) from the debug info, which is included in the download file and configures the system accordingly. Refer to software user s guide for more details on configuring Execution Coverage and its use. Execution Coverage is configured. Reset the application, start Execution Coverage and then run the application. The execution coverage results are displayed when the CPU or the execution coverage is stopped. Source & Disassembly Window: Execution Coverage results isystem, May /70

62 Execution Coverage Window results isystem, May /70

63 9 Profiler 9.1 Functions Profiler Profiler is most often used for profiling functions. Functions profiler records executed function entry and exit points and then run time-analysis is run over the collected information. As a result it gives details on how much time (minimum, maximum, average) has the CPU spent in the particular function. Available information allows the user to optimize those parts of code, which are most time consuming or time critical. The debug download file must contain accurate debug information when using Functions profiler to analyze C/C++ application. Normally, Functions profiler extracts all the necessary information from the debug information, which is part of the download file and will yield bad results if incorrect addresses for function entry and exit points are contained in the debug information. Active Trace, Profiler and Coverage functionalities cannot be used at the same time since they are all based on Active Trace. One function can be used at the time only. Configuring functions profiler Keep default Active Trace operation mode selected and select working profiler buffer size in the Hardware/Analyzer Setup dialog. Open Profiler window from the View menu and configure Profiler settings. Check the Functions option in the Profile field. isystem, May /70

64 Profiler configuration settings Check the Keep history option when Code Execution view is required during the results analysis. When the option is checked, profiler results are kept in the PC memory even after the statistics is calculated. This may slow down the profiler operation considerably, depending on the maximum trace buffer size and selected profiler buffer size. Hence, it is recommended to uncheck the option when Code Execution view is not required. Finally, profiled C/C++ functions are selected by pressing New button. It s recommended that All C Functions is selected for the beginning. The debugger extracts all the necessary information from the debug info, which is included in the download file and configure the hardware accordingly. Functions profiler is configured. Reset the application, start the Profiler and then run the application. The Profiler will stop collecting information on a user demand or after the trace buffer becomes full. Then the recorded information is analyzed and profiler results displayed. By clicking on the function, its minimum, average and maximum time is displayed. Moreover, the time spent in the function and total session time is displayed. When Count is selected from the local menu instead of Time, a number of function calls within the profiler session is displayed. isystem, May /70

65 Functions profiler results Code Statistics view Functions profiler results Code Execution view isystem, May /70

66 9.2 Data (OSEK) Profiler While the Functions profiler is based on code execution, Data profiler is based on data accesses. Initially, Data profiler was introduced to profile OS tasks and service activities. Example: The development system is built around OSEK operating system. Set up the Profiler to record OS task and service activity. First, OSEK support must be enabled in winidea. Select OSEK in the Debug/Operating System dialog and then press the Setup button. Next, specify the path to the OSEK ORTI file and define which OS objects needs to be profiled. isystem, May /70

67 Analyzer Tools dialog Open Analyzer Tools dialog by pressing Analyzer Tools toolbar in the Profiler window. Check Data option in the Profile field and make sure that Include OS objects option is selected. In this case, no data areas have to be defined since the debugger extracts the necessary information from the ORTI file in order to profile OS tasks and/or OS services. Reset the system, start the profiler and run the application. Press Show Statistics View toolbar to view time and activity statistics. Data Statistics view isystem, May /70

68 Individual object s statistics can be inspected by selecting the object and then selecting Properties from the local menu. Properties Press Show Execution View toolbar to view execution history. Data History view isystem, May /70