Do you have an application that needs to detect and react on ECC corruption? If yes, how do you test and verify your application's behaviour?
Basics: ECC stands for Error Correcting Code and is used for error corrections e.g. on memory that must be free of single bit errors. ECC can correct one-bit errors and detect 2-bit errors. ECC needs on 32 bit 7 check bits and on 64 bits 8 check bits.
Now let's assume your embedded application stores e.g. electrocardiogramm data in memory (with ECC) and writes it later to disk. If there is an error, your application needs to react because data diversification can't be tolerated.
But how can you test such a scenario? ECC errors occur very seldom, sometimes there is no error for years - so how can you verify your application's behaviour?
iSYSTEM has a solution. Since winIDEA 9.12.19 you can induce ECC corruption manually using Hardware/Tools/Memory dialog.
In the dialog you set the address and size of memory to corrupt.
Please note that if this is done indiscriminately, the device can be rendered permanently unusable. Currently supported devices are MPC5xxx.
In winIDEA 9.12.7 iSYSTEM introduced the Slow Run mode that allows the acquisition of a complete program trace - also on CPUs without trace port.
Since winIDEA 9.12.14 in addition to program execution, data flow and code coverage analysis Slow Run mode supports also profiling. Profiling analyses when and how long a function is running and provides statisticson many different parameters e.g.
count (how often was the function called)
period (what is the time difference between calls to a function)
net time (time spent in function without subroutines and interrupts)
gross time (time spent in function including subroutines, but without interrupts)
call time (time spent in function including subroutines and interrupts)
Below picture shows a Slow Run trace made over a JTAG interface and the output of winIDEA's profiler and code coverage (CC) analysis. The trace includes the complete program and data flow, although JTAG does not provide a trace port and without Slow Run mode all windows would be empty or - in case of CC - would show not covered.
Hot Attach is a feature available for a long time. "Hot attach" allows the attachment of a debugger to a running target system without affecting its operation.
To "hot attach" an iSYSTEM debugger (iC3000, iC5000) following steps are executed in winIDEA:
Check in "Hardware/ Emulation Options/ Hardware" tab the "Hot attach to target" option
Execute "Download" command from "Debug" menu.
Connect the debug cable to the target system.
Select the "Attach" debug command from "Debug" menu to attach to the target system.
Now the debugger should display "Run" status and the application can be stopped and debugged if necessary.
To disconnect from the target application select "Detach" command from the "Debug" menu.
Since winIDEA 9.12.4 (release date 15.2.2012) upon "Debug/Download" winIDEA can optionally disable "Hot Attach" and perform a regular download.
The location for this setting is: "Debug/ Files for Download/ Options" tab
Initialize debugger, load symbols: This is the default setting for hot attach
Initialize, attach to CPU, download code: This new option performs a regular download, bypassing hot attach configuration. After download hot attach capabilities are restored.
In a multitaksing operating system (OS) the scheduler is the responsible for switching between tasks. Typically a task will only run for a few milliseconds, then the scheduler deactivates the task and activates another to allow the illusion of parallelism.
On deactivation, the task's current context (registers content, program pointer, stack pointer, etc.) is stored in a control structure - the "Task Control Block " (TCB) - and the next task's TCB is loaded. The currently active task is stored in a global OS variable which usually points to the task's TCB.
For execution profiling (analysis when and how long a task runs) winIDEA needs to keep track of task switches. The easiest way to achieve that is data profiling the global OS variable that stores the active task pointer.
To setup winIDEA for task profiling select in "Profiler Configuration" profile "Code" and "Data" and specify in the "Profiler Data Area"the name of the global variable.
If the CPU does not provide data trace, the value of this variable must be signaled using instrumentation trace. Another mechanism is to use pre/post task hooks which will be called on every task switch.
For more information see ProfilerConcepts.pdf and Analyzer.pdf installed with winIDEA (open menu "Help -Technical Notes").
winIDEA build 9.12.7 introduced a new feature - the "Slow Run" mode. Slow Run allows the acquisition of a full program trace - also on CPUs without a trace port!
How is that realized?
In Slow Run mode winIDEA executes the target application at one instruction at a time, which is similar to single step mode. After every step address and data information is retrieved. From that the trace information is collected that is used by the analyzer to display trace and code coverage information.
The high load necessary to collect and calculate all that info, takes up time why this mode is called "Slow Run". Although the analyzer will advance the time stamp for every instruction by 1ns, the effective rate is ~30 instructions per second - depending on the architecture used.
To set winIDEA to slow run mode, check Debug menu "Use Slow Run". Per default it is set to "off".
Do you know how to use any digital or analog signal to trigger your trace?All you need is an iC5000 on-chip debugger with an I/O module!
Connect the signal you like to trigger on to one of the input lines (digital in, analog in) of the I/O module. Configure those lines in winIDEA Hardware/Options/I/O tab.
Next step is to configure an appropriate trace trigger.
Open the "Analyzer Configuration List".
Press the "New" "Trace" button.
Give it desciptive name e.g. "StartTraceOnButtonPress".
Select the I/O module tab.
Check the "Trigger".
Specify the signal to start the trace with.
If you use a digital signal, two combinations of digital inputs can be defined - mask 1 and mask 2. The trigger will be generated if either mask1 or mask 2 match. Within a mask, all checked signals must match the high/low configuration.
If you use an analog trigger, the trigger is generated if the measured voltage is lower/higher that the specified threshold.
To specify the trace content use the "Wizard" button at the bottom or set it manually in the "Trigger" tab.
With iC5000's IO module you can measure digital and analog signals as well as drive them. winIDEA can display these signals in the analyzer so that you can see the signals tracked by the IO module in correlation to your application's program/data trace and also profiler measurements .
The IO module provides:
one system port
8 channels digital in
8 channels digital out
2 channels analog in
2 channels analog out
power measurement
How do you configure winIDEA for the IO module (IOM) ?
First step is to physically connect the signal to one of the input ports, e.g. digital in port 3. Please make sure not to exceed the specified input and output range of the IOM signal interface. All details to the hardware physics can be found in the IOModule.pdf in the winIDEA documentation directory (in winIDEA menu "Help/Technical Notes").
Next configure the IOM in winIDEA in menu "Hardware/Options/I/O tab". Check the "Show" box in front of the signal you use, e.g. DIN3. You can also specify another name for the signal, e.g. "ButtonPress".
To display a graph of external signals in profiler's timeline view select "Show AUX".
This will open the AUX window that shows for every external signal a graph plus values.
In the screenshots the setup for power measurement and its output is also visible.
Today iSYSTEM released winIDEA 2011 build 9.11.80 as the final release build of winIDEA 2011. The download ist available here .
The major enhancement of winIDEA 2011 is the supertrace - a complete redesign of the analyzer to combine the features of trace, profiler and statistics analysis in one session. With supertrace all analyzers are based on a single trace so that a single run is sufficient to retrieve all relevant data.
winIDEA 2011 also includes the standard version of testIDEA - iSYSTEM's real-time unit test tool that allows creation and execution of unit tests without code instrumentation.
Many extensions to isystem.connect have been included in winIDEA 2011 to optimally assist iC5000 and testIDEA. Remote control of winIDEA (and iC5000) in a mini-HIL environment or in a test scenario can be easily achieved. Testers can run scripts manually and also automatically to verify the embedded application.
With this release winIDEA 2011 feature development is finalized. In the future there will be only hotfix builds for winIDEA 2011. iSYSTEM already started further development in the new winIDEA 2012 development version.
Are you recording lots of data to get an insight in the real-time workings of your application? Does it slow down the overall performance of your PC?
Then you may consider following:
Analyzer recordings can be very large. The raw compressed recording itself can be several GB large, after decompression and analysis, the temporary data footprint can increase by a factor of 30-100.
Most of this data is kept on disk in the designated temporay folder. If this folder is located on a slow disk, the overall performance suffers. If you have another disk with better performance available, set the environment variable ISYSTEM_TEMP to a folder on that disk.We also recommend to defragment this disk.
If you are still struggling with performance problems, consider that profiler and coverage analysis are parallelized. So these can take advantage of a multi-core PC to increase the overall processing performance.
We recommend following system configuration:
4-8 core CPU
8GB or more RAM
100GB free space on TEMP drive. The drive should be defragmented.
Since winIDEA 9.11.77 the Special Function Register (SFR) Window has been enhanced to show:
the address for the SFR
the bit position and size for sub-SFRs (in beside picture you see O for offset and S for size)
a radix prefix for the SFR value (0x for hexadecimal, 0b for binary values).
What are Special Function Registers (SFRs)? SFRs are special on-chip CPUs registers that control various functions of a microcontroller, e.g. stack pointer, program counter.
To open the SFR window in winIDEA, you select "Special Function Registers..." command from winIDEA's View menu or click on the SFR window icon in the view toolbar.
The SFR window organizes CPU registers hierarchically into groups and sub groups and registers and sub registers. A group is a collection of registers that serve a module on the CPU e.g. serial port, a register corresponds to a CPU's Special Function Register.
Since winIDEA build 9.11.76 the configuration window of the profiler has completely changed.
One major change is that there are no longer tabs for Code and Data Areas. Code and Data areas are now visible in the bottom half of the configuration window.
If function profiling is enabled then all functions will be profiled if no functions are listed in the code areas list.
There is now a leading check box for every function listed in the profiler data area. By clearing this check box profiler areas can be temporarily disabled. The new configuration will take effect in the next profiler session.
Less frequently used options e.g. "Ignore functions which exit on entry" have been moved to "Advanced..." configuration.
Tail-merge analysis is enabled by default now. It can be disabled/enabled in Profiler/Advanced options.
If tail-merging is used, functions that are tail merge destinations (or stack killers) are now included implicitly but not shown if any of the explicitly specified functions use them.
Since winIDEA build 9.11.69 the precision of floating point comparisons is adjustable.
When would that affect you? Well, every time you calculate with floating point numbers...
A floating point number is represented in a computer by several significant digits used for the number and an exponent, both in binary format. A definite dezimal number e.g. 0,1 can have an indefinite periodic binary representation e.g. 0,0001100110011. In a computer only the first digits of that periodic number are stored which may lead to inaccurateness in calculations, e.g. will 10*0,1 in a computer result in 1,0? Well, it depends on the implementation...
Modern computers have additional to the main CPU (e.g. using 64 bits) a floating point unit (FPU e.g. using 80 bits). Assume you assign x=y=1; and compare cos(x) == cos(y); It can happen that this comparison is not true if cos(x) has been buffered (in memory 64 bit and therefore rounded) while cos(y) has been processed directly from the FPU (80 bit and was not rounded).
To solve this dilemma you can set the tolerable error due to rounding in floating point arithmetic - the so called machine epsilon. When you calculate the absolute error of a floating point comparison, it must be smaller or equal to epsilon (float x, y;): (x-y)<=epsilon
Since winIDEA build 9.11.69 you can now set the value for Floating point compare precision in menu Debug/ Debug Options/ Symbols.
winIDEA's profiler allows you to export your recorded data filtered by sophisticated patterns.
Beside you see the dialog for Profiler's Export.
After having specified a File name to export the data to, you set the export Format. Formats available are plain Text, XML, CSV and the so called Text1. When you select Text1 format you can adjust the output format of many settings in the Options dialog (see screenshot below).
Scope defines the scope of data to export. All Areas exports all areas. Selection exports only areas currently selected in the profiler window. Filter exports areas which match the specified filter wildcard pattern. Only areas with recorded activity will be exported when "Export only active areas" is checked.
Time scope sets if the "entire session" or the selected range only is exported.
In a multitasking environment specify the Context for which data is exported. This selection is only available if profiler session has recorded context switches.
In Information specify what type of data is exported. Statistics includes information like total time and percentage of time spent in the area, number of activations, etc. Timline exports time information e.g. for data time and value that was written and for functionstime and state of activation. Data Object Mappings exports a mapping table for data objects e.g. task IDs.
Launch Associated Viewer tells the system to launch the viewer after export.
For detailed information on the Profiler export capabilities and examples see the Analyzer.pdf that is included in winIDEA's Technical Notes (Menu Help/ Technical Notes/ Analyzer.pdf).
winIDEA supports since build 9.11.63 MPC5xxx TLB (Translation Lookaside Buffer) write access. TLB entries can now be written via MemoryWrite functions (included in isystem.connect API set).
To access a specific TLB entry, the access address encodes the TLB index in bits 16-31 and the MAS register (MMU Assist Registers) in bits 0-15.
The TLB manipulation functions are provided via isystem.connect's CMPC5xxxController class.
Example: import isystem.connect as ic
cmgr = ic.ConnectionMgr() cmgr.connectMRU('')
# get MPC5xxx controller MPCCtrl = ic.CMPC5xxxController(cmgr)
To help customers with power measurement iSYSTEM provides now a so called Power Probe!
As mentioned in last week's blog post the iC5000 I/O module allows now power measurement. But what do you do if your target's voltage and current exceed the input range of the I/O module?
Take iSYSTEM's Power Probe!
The Power Probe is a small board that is connected between the power supply and the target hardware. On the Power Probe you find two resistor blocks - one divider block for voltage and one shunt resistor block for current. If you need to scale down the voltage or current you just select the appropiate resistor by a jumper.
And now you can connect the I/O module to measure the power consumption!
As mentioned in last week's blog post if you use divider resistors remember to specify in "Hardware/ Options/ IO" dialog a "Multiply" value and the Ohm value for the shunt resistor.
The iC5000 I/O module can now measure the power consumption of your target board! And in winIDEA's profiler you can view the uptake rate (current, power, voltage)!
Basically you will use on the I/O module port AIN0 for voltage measurement and port AIN1 for current measurement. Please select in winIDEA "Hardware/ Options/ IO" dialog the appropiate check box (in picture on the right). But before doing so please consider the input and output range of the I/O module. If your signal is higher than e.g. 5V, use a suitable resistor divider.
In winIDEA "Hardware/ Options/ IO" dialog you specify in "Analog IN" names for the incoming signals. If you use a divider resistor, ensure to set the correct "Multiply" value (in picture on the left).
For current measurement use a shunt resistor to protect the IO module. For correct measurements specify the Ohm value of the resistor (in picture on the right).
The actually measured values of current, power and voltage are shown in winIDEA's profiler over the period of time if you have configured the profiler to profile AUX signals too (profiler configuration dialog, section "Profile", check AUX box) .
For more information and a detailed description of the setup see iC5000 I/O module.
testIDEA can now verify the correctness of test specifications against the debug information. The following items are verified: existence of functions and global variables, hiding of global variables by local variables, duplicate IDs.
Why is that a nice feature? It can happen that typos in the test specification e.g. in the function or variable names, wrong number of function parameters or renamed function or variable names in the source code cause invalid test results or even a target crash.
To discover such problems before test execution, iSYSTEM added the new command "Tools / Verify symbols" to testIDEA. Problems are shown in the Status View. By double clicking the problem line an explanation to the problem is shown in the right (light red) window and the Test Specification Editor view switches to the test specification related to the problem.
Most operating systems have means to kill/terminate a task. Killing a task can become necessary when a task is stalled and occupies resources like memory and CPU. The way how task termination is implemented differs between operating systems, but it is an ungrateful way of ending and should only be used when there is no alternative because cleanup of resources is not done, e.g. stack, mutexes, synchronization objects are not released.
Considering this behaviour from a profiler's perspective it's a disaster. A profiler watches function entry and exit points by tracking the stack. As long as the stack is valid, the task is regarded alive, but maybe in suspended state to be resumed in the future. If now the task is terminated without cleaning the stack, the profiler needs to know about it to avoid incorrect measurements.
winIDEA's profiler can now be configured to be aware of these so called stack killers. When execution in the stack killer is detected, all active functions in the task within the current context (whose exit has not been detected jet) are considered preemptively terminated and all stack entries downto it's previous invocation are dismissed.
The stack killer configuration window is shown in Profiler's Configuration when pressing the "Advanced..." button.
Since winIDEA 2011 build 55 (9.11.55) keyboard shortcuts can be configured for external scripts.
To configure shortcuts for scripts open the Tools/Options/Script dialog. In the section "Shortcut scripts" enter the name of the external script.
To define the keyboard shortcut, open Tools/Customize/Keyboard dialog.
Select in category Tools and on the right side the command the Run Shortcut script 1 to create the keyboard shortcut for the first script - in our example ProfilerConfig.py . Set the cursor in the dialog box Press new shortcut, press the key combination to use and select Assign.
When you now use in winIDEA above key combination the script e.g. ProfilerConfig.py will be executed.
Since winIDEA 2011 build 53 (9.11.53) multiple special function registers (SFRs) can be defined for a CPU. In the CPU specification, names of multiple CPUs or modules can be combined with the + sign. This allows adding a few SFRs for a CPU.
In the beside example the default registers for MPC5567 are used with addition of SFRs specified in external definition MySFRs.
Additional custom SFRs files (*.SFR, *.SFG) can be placed in the newly imple-mented SFR subfolder of winIDEA.
After the next restart of winIDEA the custom SFRs will be available.
Line execution profiling can help to detect performance bottlenecks in a function's code.
To setup this feature select in the "Profiler Configuration" dialog the function name you like to profile and check the box "Include function lines" below the function list.
With that setting the profiler shows timeline measurements for every line of that function in the views "Timeline" and also in "Statistics".
The statistics criteria available are:
Count
Net Time time spent in the function only (without interrupts, without subroutines)
Gross Time time spent between function entry and exit, including subroutine calls, but without interrupts
Call Time time spent between function entry and exit including interrupts and subroutine calls
Since winIDEA 2011 build 50 (9.11.50) the debug plug-in has been verified for Eclipse 3.7.0 (Indigo). The existing debug plug-in works fine without changes.
winIDEA is fully integrated into the Eclipse debug environment. Using an iSYSTEM debug plug-in for Eclipse you can use the full debugging capabilities of winIDEA and iSYSTEM´s debuggers from within Eclipse. Eclipse is used as an editor, a project & build manager as well as a debugger. It provides all standard CDT debugger functionality, plus SFR (Special Functions Register) view and Real-time Expressions view. iSYSTEM also provides a Regular Expression Error Parser Plug-in for CDT.
The iSYSTEM debug plug-in provides more than CDT debugger, but less than winIDEA. Comparing to winIDEA, the plug-in does not implement trace, execution coverage and profiler functionality. winIDEA still runs in the background, but during debugging no switching to winIDEA is necessary.
Beside Ganymede (Eclipse 3.4), Galileo (Eclipse 3.5), Helios (Eclipse 3.6) iSYSTEM now also supports Indigo (Eclipse 3.7.0) . All necessary documentation and downloads can be found here:
Since winIDEA 9.11. build 47 iSYSTEM's new analyzer supports now negative wildcards in profiler's Statistics and Timeline view. Negative wildcards are supported using the - prefix.
Press the filter button in the profiler menu to show the profiler filter dialog and specify a negative filter, e.g. " -OS* -Adc".
This will tell the profiler not to show functions that names start with "OS" and "Adc".
What is tail call merging (tail-call optimization or tail-call elimination)? Tail call merging is a compiler optimization used by almost all modern compilers. But many compilers provide options to suppress tail call merging. Without tail-call merge: When calling a subroutine the caller pushes its return address on the stack and hands control to the subroutine. The very last thing the subroutine does is a pop from stack to read the caller's address and return control to this address. With tail-call merge: When a subroutine call is the very last command to execute (in the caller's function), it´s save to jump to the start of subroutine directly without adding a stack frame and reusing the caller's stack. When the subroutine is done, it will return it's results directly to the caller. For more information see Wikipedia/Tail-call
What are the benefits of tail-call merging? The main benefits of tail-call merging are saving stack space which is very important on recursive function calls and saving execution time which is important for embedded applications where every microsecond might count.
How does tail-call merging affect a profiler? For the profiler tail-call merging looks like moving the subroutine's A code into the function body of the caller's function B. In Range Mode execution in function B would be attributed to function B, instead of the optimized function A. That would lead to incorrect time measurements in the profiler.
iSYSTEM's winIDEA has now a new option. If in Profiler/Configuration the option "Tail-merge analysis" is enabled, the profiler performs analysis of tail-call merge optimizations on the fly. This analysis ensures correct measurements in the profiler, but requires a higher level of debug information quality and relies on object code analysis. If the analysis algorithm fails, profiler session aborts. In such case the tail-call merge analysis can be disabled to revert to regular range mode. Another solution is to tell the compiler not to use tail-call merging.
An overlay is one or more regions of program code which is copied at application start or during application execution from its load location (typically ROM memory) into RAM memory. This technique is used to:
Enhance performance when execution from RAM is faster than from ROM
Allow different application modules to be loaded into RAM at different times
Code in an overlay region is typically linked to its execution (RAM) address. Symbolic information can be reported a load or at exectue address.
There are two different types of overlays:
Static overlays: Overlay region which is copied to RAM only once and stays loaded for the duration of the application.
Dynamic overlays: If an overlay RAM region is loaded with different overlays during application lifetime, it is a dynamic overlay.
On-chip trace relies on knowing the code which is executed. A debugger will extract this information from the download file, but in an overlay system no code is loaded at the execution address. If symbolic information is reported at execution address, debugging will work well for static overlays, but will fail for dynamic overlays, because one execution address maps into multiple overlays.
winIDEA currently supports only static overlays. Symbolic information must be reported with execution address. Overlays are Process specific. To configure them Debug/Files for Download/Process tab and edit the appropiate process.
Since winIDEA 2010 build 9.10.144 and winIDEA 2011 9.11.14 iSYSTEM's profiler supports the so called "Range" operation mode additional to Entry/Exit mode. Range mode should be selected when compiler optimizations make the function exit identification unsecure or impossible.
Basics: What does a profiler? The profiler is used to identify performance bottlenecks (which function runs most often), execution time deviations (how long is a function's minimum and maximum execution time) and invocation periods (how often does a function run).
Entry/Exit Mode: Up to now the profiler used the so called Entry/Exit mode. In that mode the profiler is configured to record execution of instructions at a specific function's entry and exit point, and if executed, the instruction address and the time are recorded. From that above measurement values are deduced. This method relies on accurate exit information which is best if profiler hardware has access to real-time program flow - e.g. on an ICE system with access to all buses. Because of the amount of information on ICE systems, filtering should be used to reduce the trace information. Disadvantage of this mode is the reliance on accurate exit information. Compiler optimizations can obscure the exit information.
Range Mode: In range mode the profiler monitors the continuous stream of program flow. If the program counter moves from one function body to another, the profiler considers this a call of a function or the return from the current function (depending on the instruction) and records the instruction address and time. Therefore range mode is independent from function exit information. Range mode is a stateless algorithm that makes it insusceptible to weak debug information, compiler optimizations and RTOS stack manipulations. In addition RTOS task switches are noted by execution profiler even if no data trace is available. Disadvantage of range mode is that the complete program flow must be available which is unpractical for bus trace systems e.g. ICE.
To set range mode, open the the Hardware - Analyzer Setup and change the Profiler Operation mode to "Range" in winIDEA 2011 or "Range Analyzed" in winIDEA 2010.
Realtime unit testing runs test scripts and verifies your application without any influence on its runtime behavior.
Why is that important? Because most unit test tools on the market instrument the application's code and install a test driver through which resource utilization and task execution is changed. Additionally the instrumented code must be compiled, linked and downloaded to the target system for every test case.
The much better approach is realtime unit testing: Realtime unit testing does not require code instrumentation or any test driver. iSYSTEM has enhanced their debug and test tools to allow the generation and execution of test cases from inside the development environment. No test driver is necessary. Without compiling/linking/download the test is executed on the real target hardware.
iSYSTEM calls that realtime unit test because the test is executed on the real hardware without any effects on the runtime behavior.
How does realtime unit test work?
First you need a working hardware that is connected by an iSYSTEM debugger (Blue Box e.g. iC5000, iC3000) the PC. Second the software must basically work to initialize the hardware and run until main().
At that point testIDEA takes over. Based on a test specification testIDEA puts the parameters for that function test on the stack – that’s the only additional resource needed by testIDEA - , executes the function in realtime, compares the return values to the expected ones specified in the test specification and returns to main().
testIDEA is a free and open programming interface (API)that is completely integrated in winIDEA. With that API set one can write test applications/cases but also automatically execute them on the hardware connected by iSYSTEM tools. testIDEA also includes an interactive GUI for generating test cases and test reports.
Starting with winIDEA 2011 build 28 iSYSTEM redesigned winIDEA's analyzer window which now unifies trace and profiler analysis functionality. Both analyses can run in parallel on a single recording session.
Based on that new design winIDEA now also offers a new profiler statistics view. Any statistical aspect of the profiler session can be displayed as a column in the statistics view.
Statistics on following objects with minimum and maximum values are available :
Call Time: time spent between function entry and exit including interrupts and subroutine calls
Net Time: time spent in the function only (without interrupts, without subroutines)
Gross Time: time spent between function entry and exit, including subroutine calls, but without interrupts
Period: how often the function is called
To select the columns to view you press the button with the clock symbol or right click the header line below the the toolbar.
One of the new features in winIDEA 9.11.34 is a measurement plugin that allows you to see details of your embedded hardware. The new measurement plugin is available for the iC5000.
The measurement plugin is started from Plugins/Measurement.
Run Duration shows the time the CPU was running since the last time the user set it to running. The accuracy of this value is approximately 20ms.
CPU Clock, Vref and Trace Clock are measured on the debug interface and show the CPU/System clock, reference voltage and on-chip trace clock of the embedded hardware.
GND Faults are the number of observed groundtransient events. An event is registered when debugger and traget GND potentials differ by more than 250mV. The GND potentials are sampled at 500ns intervals. If this value is non zero, verify that the debugger and embedded target GND have a good contact. Switching target on or off will normally cause a few transient events.
If the plugin displays "?", then either the emulation system or the target hardware does not support measuring.
Since winIDEA version 9.11.34 the watch window features enhanced displays of arrays.
Per default winIDEA will display arrays in the watch window as an array of 8-bit characters.
If you select the option "Display char arrays as zero terminated strings" in Debug/Options/Symbols, then arrays of type char will be displayed as zero terminated strings.
Additionally to beside setting you can use watch modifiers or the context menu in the watch window to specify a destinct array interpretation.
To force string interpretation use ,s modifier or select from context menu char[].
To force array interpretation use ,a modifier or select from context menu Display char[] as string.
Here an example: char sz[] = "Hello World";
To allow viewing of specific elements of large arrays, watch modifiers can be used to set the first displayed element and the number of displayed elements.
This is the format of the watch modifier: <watch expression>, a[<first element][.number of elements>] The modifier can also be set by selecting Set array offset... from the context menu.
Example: sz,a3 // display array elements starting from sz[3] sz,a3.2 // display 2 array elements, starting at sz[3] sz,a.2 // display first 2 array elements
iSYSTEM has published two new technical papers to iSYSTEM's webpage.
How to overcome/avoid High Frequency Effects on Debug Interfaces This article discusses design considerations for Printed Circuit Boards (PCBs) to prevent high frequency effects. MCUs get more and more complex by higher integration and performance at less power consumption. Due to that the on-chip trace signals are subject to (increased) signal distortion which can prevent a trace tool from capturing the trace stream correctly. Design guidelines help to overcome these high frequency effects...
How reliable is Code Coverage information shown in Source Code? 100% code coverage measurement on source code is not equal to 100% code coverage measurement on object code level. The examples in this article show how the usage of complex instructions (e.g. for loop), complex conditions (e.g. if statement) or library/operating system functions add object code that is not directly traceable to source code statements. This inserted object code could include dead code or never taken code paths.... See how to find this untraceable code...
An embedded application must properly initialize the CPU and surrounding components to be able to run correctly. There are however situations during development and production when it is beneficial to condition the system before the application runs, e.g. disabling of watchdog timers, configuration of system clock or configuration of chip-select logic...
winIDEA handles initialization at following events:
After CPU emulation is started and before download is performed (Hardware/ Emulation Options/ Initialization tab)
After program download completes (Hardware/ Emulation Options/ Initialization After Download tab)
The layout of both tabs is very similar, so we discuss available options on the Initialization tab.
The Initialization option (see beside picture) defines the action to take when initializing the CPU:
none - no initialization is performed
Init sequence - the initialization sequence is performed as defined in an external file which is best created from the application boot code
Reset target, Run... - the target is reset and the CPU is set to running for the specified number of seconds. This option also runs a bootstraper programmed.
Reset, Run..., Init. seq. - the target is reset, the CPU is set to running for the specified number of seconds and the initialization sequence is performed. this combines bootstraper and some additional initialization.
When theLoad from fileoption is checked, the the initialization is loaded from an external file (*.ini, *.mac)
The Address offsetoption allows to specify if the memory initialization offset is read from CPU or specified manually.
When Reset CPU after DL/reset commands optionis checked, then the CPU is reset after download completes.
The Add..., Properties and Remove... buttons become available when Load from file option is NOT checked. Although an initialization file is recommended, for a few and simple items interactive configuration is available. Beside you see the configuration dialog.
For more information read the InitializationSequence.pdf document in the <winIDEA installation>/DOC/TechnicalNotes folder.
According to Beizer, 100% statement coverage at source code level might cover 75% or less statements at object code level (reference [1], reference [2]). That means if you only use source code coverage you have NOT tested 1/4 of your application's code!
But where does that come from...?
Remember the blogpost on Code Coverage: Relation between Source and Object Code? Every time you use complex instructions (e.g. for), complex conditions (e.g. if) or library or operating system functions object code is added that is not directly traceable to source code statements. Sometimes also the compiler generates object code to bridge the gap between what is possible in source code and on the processor e.g. a conversion from floating point to integer.
What impact has this?
DO-178/ED-12B Section 6.4.4.2b states that if "... the compiler generates object code that is not directly traceable to Source Code statements. Then, additional verification should be performed on the object code..." So if an application has to conform to standards like above then the object code has to be covered too. To get an application approved following three steps must be addressed (cite from [reference 3]):
detect and identify any added object code
establish the functionality of that code; and
verify the correctness of the added, untraceable code sequences
How can you achieve object code coverage?
You can easily achieve object code coverage using iSYSTEM's on-chip debug tools and analyzers. iSYSTEM's tools measure code coverage by recording all addressesexecuted on the processor. Code instrumentation is not used for that. Code coverage results displayed in source code are correlations of the low level binary data (that was used for code coverage measurement) to high level source code. Any object code insertations by the compiler or by library functions are easily visible in iSYSTEM's code coverage analysis window.
winIDEA2011 supports the transition into low power state and its return to normal power for MPC 551x and MPC560x CPUs.
Low power handling is enabled optionally by checking the Low Power Debug option in Hardware/Emulation Options/CPU/CPU Setup/MPC5xxx as not all CPU masks implement debugger support internally.
When the CPU exits low power state, the emulator stops it and reinitializes the on-chip debug module. This ensures that breakpoints and trace do not miss any code execution. After the OCD initialization the CPU remains stopped. If the CPU should resume running, check the Run after exiting low power state option.
When the CPU is about to enter low power mode, the emulator can stop it when the option Stop before entering low power state is checked. This allows review of the application context. The CPU status indictes that the CPU is stopped before entering low power mode.
winIDEA is fully integrated into the Eclipse debug environment. Using an iSYSTEM debug plug-in for Eclipse you can use the full debugging capabilities of winIDEA and iSYSTEM´s debuggers from within Eclipse. Eclipse is used as an editor, a project & build manager as well as a debugger. It provides all standard CDT debugger functionality, plus SFR (Special Functions Register) view and Real-time Expressions view. iSYSTEM also provides a Regular Expression Error Parser Plug-in for CDT.
The iSYSTEM debug plug-in provides more than CDT debugger, but less than winIDEA. Comparing to winIDEA, the plug-in does not implement trace, execution coverage and profiler functionality. winIDEA still runs in the background, but during debugging no switching the winIDEA is necessary.
Beside Ganymede (Eclipse 3.4) and Galileo (Eclipse 3.5) iSYSTEM now also supports Helios (Eclipse 3.6). All necessary documentation and downloads can be found here:
Code coverage is a measure used in software testing. Code coverage helps to find code that is never executed. This “dead code” represents undesired overhead when assigning memory resources and also a potential hazard if this code was not executed during testing. You may already know statement coverage that marks code (statements/instructions) as executed or not and decision coverage (also known as Branch coverage) that marks conditional instructions as evaluated to true or false or both (at least once).
But what is now offline and realtime execution coverage?
Let's start withexecutioncoverage. iSYSTEM tools measure code coverage by recording all addresses being executed on the processor without any code instrumentation. Code coverage results displayed in source code are correlations of the binary low level data (that was used for measurement) to the high level source code. In iSYSTEM nomenclature code coverage is called execution coverage in contrast to data or access coverage.
As the name already says offline execution coverage uses recorded data and analyzes them. Offline analysis allows statement as well as decision coverage.
Statement Coverage: each processor instruction is marked as executed or not executed. By correlating this information upwards to the high level source code, executed and not executed lines of source code are identified.
Decision Coverage: conditional instructions are analyzed to identify if a condition has been evaluated or not. For this analysis the coverage session must be stopped (therefore “off-line” execution coverage). By cumulatively merging the information for each condition four different states are possible:
the condition has never been evaluated,
the condition has been evaluated to true,
the condition has been evaluated to false,
the condition has been evaluated at least once to true and at least once to false.
Realtime execution coverage is based on hardware logic in the analyzer and is available for all in-circuit emulation systems with bus trace. The tool monitors in real-time what program addresses are executed and which records are updated. Real-time execution coverage can run indefinitely. Realtime execution coverage allows only statement coverage because there is no history information, and without that no decision coverage is possible.
Starting from the source code, there is a chain of transformations that produce the object code that will run in the actual target. These modifications directly affect code coverage analysis because it is very complex to establish which object code correlates to what source code line.
For C programs usually these steps are: preprocessing, compilation, optimization, assembly, linking and conversion. Details vary between systems (compilers, assemblers, linkers, converters). These steps are not bijective: information is added and removed in every step.
The following examples should be well understood when interpreting source code coverage information measured by iSYSTEM tools:
Complex Instructions The object code may not correspond to the source code as seen from the perspective of a source level programmer. Take this example: 1 int i; 2 for (i=0; i<10;++i) 3 { 4 somefunction(i); 5 } Line 2 is typically (no matter of the processor archtecture used) split in two or three blocks: one to initialize the loop, another the check the condition and incremeent the loop variable and a tail to cleanup ... (click here to read on...)
Complex Conditions For example: 1 if (a==3 || b==4) 2 { 3 somefunction(c); 4 } Line 1 of the example can be only partially tested, even if it is reached from the program. If this condition is reached during execution and evaluation short-circuit logic applies, then in the source code window the coverage information will show the line as not executed. If you drill down the assembler information for this line you will see that only part of the code was executed... (click here to read on...)
Compiler Optimizations Compilers may merge several source code lines, deem some unnecssary and/or reorder the execution flow. iSYSTEM tools take great care to show accurately what is actually going on. In the source code view of coverage information you can tell at once if a line of code generates any object code at all. Each source code line that generates object code has next to it a lowered square that is, depending on the coverage information available, red (if code was not executed), green (if code was executed) or has an arrow indicating that there is a conditional instruction... (click here to read on...)
Libraries As iSYSTEM tools gather coverage information directly from the hardware, analysis of library code isn´t different to analysis from code written by the user. If source code is not available, the information is given on the object and assembler levels only,... (click here to read on...)
Compiler Generated Code This is expecially true, but not limited, for smaller processors. Sometimes the compiler needs to introduce code to bridge the gap between what is possible in source code and on the processor. This is mostly the case for operations that don't translate directly to machine code... (click here to read on...)
Compiler Bugs Seldom, but still, compiler can have bugs. These bugs are rare on the code that is generated, as compilers are usually tested in this respect. Most of the time bugs are in the debug information generated by the compiler and used by other tools. It is important to remark that these happen seldom, but shouldn´t be ruled out.
Have you ever wondered what "(1t,6f,0b)/8 (44%)" means in winIDEA's Code Coverage window in the Conditionals column?
We changed the abbreviations for decision coverage to increase the accuracy of decision coverage results shown. We now use the term "Conditionals" (instead of the previously used "Branches") because not all branches are conditional statements. Now what is a conditional statement? A condition usually results in branch and jump instructions in assembler that lead to code that is not always run through (because of the jump...). When we use the opposite for explanation: an UNconditional statement contains only opcodes that are always executed and do not depend on the CPU condition register.
Now what is acutally shown in winIDEA's Code Coverage window?
The "Lines bar" shows a graphical representation of the percentage of lines that were covered for a certain item. The "Lines" column displays the amount of lines covered, the total amount of lines and a percentage figure. If the Lines column doesn´t show anything but the "Sizes" and "Conditionals" column are not empty, then there is no source code available for the assembler code executed (which is usually the case for library functions, e.g. operating system functions).
The "Sizes Bar" displays graphically the percentage of bytes that is covered or not for a given item. The "Sizes" column displays the amount of covered bytes, the total number of bytes and the percentage of bytes covered.
The "Conditionals" column provides information on how many conditional instructions have been evaluated to true (t) or false (f) or in both ways (b). Both ways means that the condition has been evaluated at least once to true and at least once to false. The number after the slash (/x) tells the total number of conditional instructions found. The percentage figure represents how many of all possible conditional outcomes have been covered.
Auto calibration is a feature of iSYSTEM’s powerful on-chip debuggers to reduce noise, skew, crosstalk, etc. and to ensure a high quality trace data. Autocalibration allows the on-chip debugger (e.g. iC5000) to adjust the sampling position by shifting the sampling voltage and sampling delay in reference to the clock. This allows the tool to fine tune the instant when the signal is sampled to a moment where the signal is more stable.
Autocalibration is realized by different means. On all channels and for all reference voltages the signal is sampled twice and checked when the signal is stable. To achieve that, any input signal is routed parallel into two registers that use different clocks. The clock delay is programmable, but it is ~1ns apart. The voltage level based on Vref is also shifted. It can be adjusted in both directions to allow sampling at several different threshold voltages. Then the (two) signals are sampled using different threshold values. If the signal is not changing in the 1ns period, the signal is considered stable and “sampled good”. If the signal changes then it is “sampled unpredictable”.
The sampling results are shown in winIDEA’s Trace Line Calibration results view.The graph is based on Vref and Phase which is the clock delay. If the signal is stable it shows a “.”. If the signal is traveling from low to high (or opposite), an “X” is shown. Already from the graph you can establish “data eye” areas, where it is save to sample.
Usually the auto calibration logic in the Blue Box decides automatically on “Recommended” Vref and Phase values (shown as “R”). But in cases of huge noise this might not be possible and the user has to set these values manually in “Current” input boxes (shown as “o” in the graph).
On the iTRACE Probe 2 every signal line can be shifted and delayed individually (important for PCB designs where the onboard debug lines have different lengths and therefore different shifts). Additionally differential signaling is used that transports every signal over two lines where one line runs the inverted signal in the opposite direction. This way any signal distortion should be very limited across both lines.
With Autocalibration the iC5000 can capture up to 2Gbps data over a 16bit port. With the iTRACE Probe 2 a data bandwidth of 5600Mbps can be achieved on a 16bit port and using 4 iTRACE Probes 2 up to 20000Mbps (=20Gbps!) data bandwidth are possible.
iSYSTEM's powerful on-chip debuggers enable you to identify performance bottlenecks using the function profiler. The user can find which functions are most time consuming or time critical and need to be optimized. Function profiling is realized by tracing function entries and exits. The execution time of a function is the difference between these two points.
Some CPUs with Nexus as debug interface feature so called ownership trace messaging (OTM) which includes a so-called ownership trace register (OTR) that can be configured to contain information necessary for a debugger to provide task information to a user. There are several OTM formats allowed and specified in the ORTI standard.
In practice, an operating system writes to the process ID register (PID0) which yields an ownership trace message on every write. The on-chip debugger's function profiler records these OTM messages and displays the task activities based on it.
In winIDEA's profiler settings you can specify the OTM format in "OTM encoding". There are different encodings supported by winIDEA, e.g. the entry in beside screenshot means:
Multiple OTM messages
Bit7 is stop bit
Bit6 is start bit
bits following are ID fields, 2 bits
then there is data in little endian format
winIDEA is compliant to ORTI 2.1 and 2.2 standard.
For about half a year winIDEA features the usage of trace trigger templates. A library of trace trigger templates can be created by a specialist and shared with other users who can quickly create and manipulate the trace trigger for a specific task.
A template trigger provides a level of abstraction on top of the trigger configuration, which makes its use quite straightforward. The idea is:
An experienced user familiar with on-chip trace engine can create and test a specialized trigger configuration: e.g. record all acceses to variable MyVar while executing function MyFunc
Once the configuration is tested, only a few parameters are marked as configurable (e.g. name of the variable and the function) and the configuration is saved as a template.
The template is shared between other users, who can use it for this purpose, but need to specify only the configurable parameters.
Any number of templates can be created. Any regular trigger can be made into a template. iSYSTEM already provides a growing library of preconfigured templates.
Once a trigger configuration is operating correctly, click the Create Template button in the trigger configuration dialog. Fill in a name and a description for the template. The Changed items list displays all settings from the default trigger configuration. If one of these items should be configurable in the template, move it the the Parameters list.
Trace refers to a consistent, complete or section-wise recording of program execution, with or without variable accesses and values, without requiring any resources of the MCU. It displays the sequence of code flow with time information and also analyzes its content. A real trace includes MCU-independent time stamps.
The trace provides a developer a method to find sporadic or intermittent program errors and to verify realtime events against time requirements. The definition of complex triggers allows to catch any possible event. Events outside of the controller (e.g. AUX or clips lines) can also be included.
A good trace is non-intrusive and non-instrumented and does not influence the real-time behaviour of the application. The trace works on optimized code and allows search and filter operations. With the iSYSTEM API set traces can be automated and controlled remotely. This is very benificial for long term tests using test scripts.
All trace information can be exported to HTML, XML or text files for reports or further analysis.
In iSYSTEM's winIDEA two different recording methods are available where the trace buffer size can be set in winIDEA:
Record everthing: This configuration is used to record a contiguous program flow either from the program start or up to the moment when program stops. The trace records and displays until the trace buffer is full.
Use trigger/qualifier: With this configuration trace recording is based on a trigger. The position of the trigger can be set - the trigger can start or stop the trace or the trigger position is in the middle of the trace buffer. To catch any possible event, trigger definition ranges from simple to very complex triggers. There is a wizard to help with trigger configurations.
In winIDEA you can specify the content and color settings of the trace window. You can choose between Disassembly, Disassembly Data, Label, Source Line, Address, Function Data, On-Chip Trace, Bus activity (BTM, DMA, DQM, ...). Here an example trace window:
With the start of winIDEA 2011 iSYSTEM has changed it´s release policy. From now on there are released, verified and hotfix builds. Also new is the tested platform document (that comes with every verified build) that tells you what Blue Box - MCU combination has been tested.
Released builds are released once a year and are regression tested for several months. Released builds include binaries, full documentation, SDKs, Python interface and compilers. The latest released build is currently winIDEA 2010.
Verified builds give customers access to new features and newly supported microcontrollers. Those features are made available in the winIDEA version currently under development, at the moment winIDEA 2011. Verified builds are regression tested and the tested platform document tells you what Blue Box - MCU combination has been tested. There will be about five verified builds a year and they can be downloaded from iSYSTEM's download area.
Hotfix builds are made for important and urgent fixes and features, also hot CPUs. Hotfix builds are only limited tested and are not available for download on the web. If you need a hotfix build, call iSYSTEM's support. There will be about two hotfix builds per week.
iSYSTEM's proprietary Script Language (ISL) gets absorbed in winIDEA's Python interface. Customers who have already written ISL scripts can now simply convert them to Python scripts using winIDEA's ISL to Python converter.
ISL can be used in the way as it is (status winIDEA version 9.11.22, 29th March 2011) but it won´t get enhanced any further. If you like to use new and upcoming winIDEA features we recommend to migrate existing ISL scripts to Python scripts using winIDEA's Python converter.
The ISL to Python converter is available from winIDEA's context menu when an ISL scipt is loaded.
With iSYSTEM testIDEA you can write test applications/cases but also automatically execute them on your hardware connected by iSYSTEM tools.
In the last weeks we already published several videos on the creation and running of tests, on the usage of variables and stubs, on the inheritance of test specifications and on test report generation.
Today we like to explain how you can use function and data profiler from inside testIDEA to optimize your application's performance.
You can profile every function inside testIDEA and collect stastistics on the results. A profiler helps identifying performance bottlenecks. You can determine how long a function ran in relation to the overall recording time.
In our example we profile a function that is calling 4 subroutines.
For that we specify in the Test Specification Editor - Function the top level function name to test - in our example Address_DifferentFunctionParameters(). In Test Specification Editor- Profiler window select run mode "Start" and set the name for the profiler output file. You could use "Trigger name" to specify a trigger when to start profiling - in our example we do not use it because we start profiling when function Address_DifferentFunctionParameters() starts.
We recommend to set "Save history" to "Yes" to use winIDEA´s timeline view to show which function was interrupted at what time for how long and what other functions were called how many times.
In "Profiler" - "Code areas" window list all function names that should get profiled - in our example the toplevel function Address_DifferentFunctionParameters() plus all its subroutines Func1() to Func4().
For every function set time and hit limits. If any limit gets exceeded, the test will fail.
In "Profiler" - "Data areas" window list all variables that should get profiled and specify time and hit limits. Profiler will only collect statistics from the variables in this list.
If we run now this test, we see in testIDEA´s "Profiler"- "Code areas" and "Data areas" window the results for every function and every variable profiled.
winIDEA displays a chart of the profiling test results in winIDEA´s profiler window. In timeline view every function currently running is shown in bright red. Light red color means that a subroutine is executing. The data window shows when and how long the variable iCounter is set to the destinct value.
Switching to statistics view gives an overview on how much time was spent in a destinct function.
With iSYSTEM testIDEA you can write test applications/cases but also automatically execute them on your hardware connected by iSYSTEM tools.
In the last weeks we already published several videos on the creation and running of tests, on the usage of variables and code coverage, on the inheritance of test specifications and on test report generation.
Today we like to explain how you can exclude functions from testing by using stubs.
When a function under test calls another function which we do not want to include in the current test, we can specify a stub.
The stubbed function will not be called, but parameters and return values will be set according to test specification.In our example we test Func4() which calls Func1(). We do not like to execute Func1(), therefore we stub it.
First we write a test specification for Func4(). Parameters and return value are set as always.
To stub Func1() specify in Test Specification Editor - Stubs the function name Func1, as Parameters 10 and a return value x. In the Assignments section set a value for x, e.g. 20.
When you now run your test, Func1() will not be executed and its return value will always be 20.
With iSYSTEM testIDEA you can write test applications/cases but also automatically execute them on your hardware connected by iSYSTEM tools.
In the last weeks we already published several videos on the creation and running of tests, on the usage of variables, on the inheritance of test specifications and on test report generation.
Today we like to explain how to collect code coverage information while tests are executed.
To collect Code Coverage information when running tests inside testIDEA set first all function parameters in Test Specification Editor - Function window.
Then open Test Specification Editor - Coverage window. Select "Start" as the Run mode, enter a file name and the Open mode for the file. Details on the different options you find in the tooltips when moving the mouse pointer over the items.
In our test we like to save the coverage statistics after test - therefore we select yes - and we do not close the file after test.
A rangeset specifies the functions on which code coverage statistics are collected. In Rangeset Name specify the rangeset name used by winIDEA. If you do not specify a Rangeset Name, the default name isystem.test is used. The content of the rangeset is set in the "Coverage" - "Statistics" window by adding functions to the "Function" list. Code Coverage information will only be collected on the functions in "Function" list.
In our example we like to cover Func1() and Func4(), although the test is specified on the toplevel function Address_DifferentFunctionParameters().
In the "Coverage" - "Statistics" window you can specify statistics requirements.The test will fail if coverage results are lower than specified. If you don't want to verify coverage, but only to record it, simply set expected coverage to 0 %.
If you like to export Code Coverage statistics specify the export format and a file name. Additional to statement coverage you can collect "Decision coverage" results (also called branch coverage) by selecting "Yes".
When you now run this test you see in Test Specification Editor the actual Code Coverage Results.
winIDEA will leave the code coverage window open after test. You see that Code Coverage statistics have only been collected on Func1() and Func4() and you can check Code Coverage results for every line of code.
With iSYSTEM testIDEA you can write test applications/cases but also automatically execute them on your hardware connected by iSYSTEM tools.
In the last weeks we already published several videos on how to create and run tests in testIDEA, how to generate test reports to document the test process and its results and how to use variables to pass values to a function in test. Today we like to explain how the test tree is structured and how you can use inheritance to simplify your test setup.
Often tests are grouped based on a common property. To provide this functionality, tests can be organized hierarchically in a tree structure.
In the base test we specify all properties that should be common/the same for all derived tests.
In our example we use a base test, where we test function Func4() but we stub function Func1() to always return 20 and we also specify Code Coverage in the base test.
We now derive a test specification by right clicking that base test and selection of "New derived test". We assume that we like to test Func4() again, but with different parameters, e.g. -1,0,0.
The derived tests inherits the complete test specification from it´s base test - in our example it will also have Func1() stubbed and Code Coverage specified.
Lets run the first derived test and look at the test report. You can see in the test results that for the derived test also Func1() was stubbed with return value 20 and that Code Coverage is set.
If a derived test specifies a property that is also specified in the parent base test, that property is NOT inherited, meaning that the derived test specification precedes.
Lets look at the second derived test. It has a Stub of its own which returns for Func1() 60. When we run this derived test, we can see in the Test Results that it uses as return value for Func1() 60, but still has Code Coverage inherited from its parent base test.
