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.
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 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:
Today iSYSTEM presented a concept and associated tool setup enabling users of iSYSTEM tools to show proof that the deployed tools work as specified.
ISO26262 is a standard that ensures functional safety in road vehicles. Parts of this specification describe provisions that automobile suppliers and/or manufacturers must fulfill in order to “minimize the risk of systematic faults in the developed product due to malfunctions of the software tool (introduce or fail to detect errors). Hence qualification has to be accomplished for software tools used in the development and test process before the actual development starts.
To implement the standard's requirements at customer side, iSYSTEM offers organizational measures and documentation as well as a tool setup for the validation of dedicated tool functionality.
One organizational measure is for instance detailed documentation about the iSYSTEM tool development and test process. Basically it is an individual safety manual adapted to the needs of a customer and contains for example:
Tool features-/functions descriptions that are used in a safety project
Explanations how these functions should be used
Manuals on the application of software and hardware, “Getting Started Guides”, etc.
Descriptions on the system prerequisites in general and in reference to the target processor
Descriptions on well-known workarounds for a specific micro controller
The safety manual informs the developer how to use iSYSTEM tools for the development of safety critical applications.
If a specific function of an iSYSTEM tool has to get validated based on ISO26262, iSYSTEM provides a “Tool Pre-Qualification Kit”. This consists of reference hardware plus test cases to validate several functions of an on-chip debug and trace tool such as:
Standard debugging and IDE functions, e.g. memory read, write, step, memory dump, download, flash programming, etc.
Advanced debugging with trace and profiling (especially time measurements)
Software test with code coverage and unit test
This allows iSYSTEM customers to show the proof that iSYSTEM tools perfectly fit in the context of a safety project as required by the ISO 26262 standard.
IEC61508, ISO26262, DO178B/C, IEC62304, EN5012x - They all and highly recommend testing. Some also include the qualification of tools used for the development of a safety application. So it is time to discuss this with you! Please register for our roadshow in Germany starting September 2011: Download the agenda for Germany
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...
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. iSYSTEM testIDEA is a free and open programming interface (API) that is completely integrated in winIDEA.Test applications, test cases and the accordant test reports can be written in many different programming and scripting languages (Python, Java, C/C++, C#, Perl, TCL…). testIDEA also includes an interactive editor for generating test cases and test reports.
To see how to specify your first test in testIDEA, run below video.
In our demonstration we use a sample workspace included in winIDEA examples directory for an MPC5554 evaluation board. The Blue Box used is an iTRACE GT.
To launch testIDEA use winIDEA´s "Test" menu and select "Launch testIDEA".
Verify that the connection to your target is working. To do so use menu "Run" - "Init Target".
You can see in the background winIDEA´s download window which shows that testIDEA is calling winIDEA.
This initialization also checks that testIDEA is connected to winIDEA - you should see a green CONNECTED in the bottom left corner - and it reviews that the workspace path in testIDEA and the workspace path in winIDEA fit. You can adjust testIDEA´s workspace path in "Tools" - "Options..." - "Workspace Path".
Most controls on the the initial screen are grayed out, which means you cannot enter any data until the first test case is created.
Create test cases either with the main menu "File" - "New base test" or with right mouse click in the Test Tree window and select "New base test".
The New test dialog opens. Use Refresh to retrieve a list of all functions available in the download file. Select the Function you like to get tested.
Type in values for the Parameters. If you can´t recall the function definition press Source and winIDEA´s document window will switch and show you the function you like to test.
If pointers are passed use variables in the test specification editor. How to use variables see in a later section.
In Verification specify an expression for the expected return value, e.g. rv==20 or you include global variables, e.g. rv==iCounter+20.
Ret.val. name is the variable name containing the return value after test.
To save your test specification press OK.
To test that function use "Run Selected".
More information on testIDEA and how to install it you find on iSYSTEM´s web page.
iSYSTEM released winIDEA 2010 - the newest version of it´s powerful IDE and debugger. Addtional to many new winIDEA features this version also includes testIDEA - iSYSTEM´s new tool to write and execute test applications and test cases.
With iSYSTEM testIDEA you can write test applications/cases but also automatically execute them on customer’s hardware connected by iSYSTEM tools. iSYSTEM testIDEA is a free and open programming interface (API) that is completely integrated in winIDEA.Test applications, test cases and the accordant test reports can be written in many different programming and scripting languages (Python, Java, C/C++, C#, Perl, TCL…). testIDEA also includes an interactive editor for generating test cases and test reports.
winIDEA has been expanded to support many new microcontrollers with their specific features. This is reflected in several changes in the winIDEA user frontend. Major enhancements have been included in the isystem.connect API set that allows to remote control winIDEA from many scripting languages like (Python, Java, C/C++, C#, Perl, TCL…). This makes an integration of winIDEA in customer specific development and test processes very easy. Improvements have been added to Profiler, Trace, build manager (and other components...). New features are included like debug and trace support of overlay regions, display of new types in watch windows, caching of real-time accesses, integration of Python scripts in watch and SFR windows, RTOS support for OSEK, Hilscher rcX and Keil RTX, workspace, trace trigger and breakpoint templates... For a complete list of all included features see What´s new .
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:
A paper that describes a basic workplace setup of an embedded software developer in the year 2011. It points out today’s challenges arising from low level functionality design as well as different ways of testing such software. It includes the aspect of test automation, how to test IO drivers and how to do functional testing (black box and white box, which is code coverage) within a developer's workplace [...]
... yes, embedded systems software and hardware development changed a lot in the last couple of years. 32-Bit monsters, millions of lines of code, testing, testing, testing, and software design on a very high abstraction level (just to name a few things). A real challenge for those who just started exploring the world of embedded ...
We just updated our slideshare account. There you will find the latest powerpoint presentations about iSYSTEM Blue Box Technology for embedded development and test.
You may now download libraries, examples and documentation for C# and Perl. Just extract the zip files into the SDK folder of your winIDEA installation.
The extensive (script) language support within winIDEA allows the users to write their own scripts and/or applications to remote control iSYSTEM tools. Remote controlling means actively steering or acquiring data from a target system. This
could be an Excel script filling a table of temperature readouts over time, a
production stage application which programs the microcontroller FLASH and
verifies RAM, application which, through data acquisition, realizes unit test,
a hardware-in-the-loop system test, etc.
At Embedded World 2010 Rapita Systems showed iSYSTEM's new hardware platform iC5000 together with their performance measurement and timing analysis tool RapiTime.
However, we were wondering why they put our competition on the same level ;-).
iSYSTEM finished its first series of workshops in south Germany.
"It was not just a workshop. We were able to address the right topics at the right time: Test automation with isystem.connect and some advanced basics of the use of high-end debug features such as tracing, profiling and coverage. The workshop showed that iSYSTEM is very well positioned along the complete embedded software development and test process and ready for future growth", said Erol Simsek Director Sales & Marketing of iSYSTEM AG.
Learn more about isystem.connect and download the presentations of our developers Marko and Primoz from our slideshare account:
isystem.connect for developers: isystem.connect is iSYSTEM´s generic API and basis to connect to winIDEA, to get full control over debugging and much more
isystem.test for testers: builds on isystem.connect and adds powerful unit testing capabilities
isystem.connect goes "mini"-HIL: builds on isystem.connect and adds control over external hardware
sepp.med
GmbH, iSYSTEM AG and the FZI (ResearchCenter for Information Technology in Karlsruhe) cooperate to define and enhance methods and tools for testing embedded
software. The project titled eMOTE ("*E*mbedded *Mo*del-based
*Te*sting") is funded by the BMWi (Federal Ministry of
Economics and Technology) and will last for two years. More ...
Yesterday the first Blue Box Workshop took place in Schwabhausen. The workshop was fully booked and it was a great success!
Topics of the workshop were
"Development and Test Process Automation using isystem.connect"
"Debug Interfaces of different MCU Architectures and their influence on Tracing, Profiling and Code Coverage"
Workshop participants were impressed by the large field of application offered by the API set isystem.connect. Not only test processes can be easily automated using standard scripting languages like Python, C++, Java..., the API set also eases unit tests by providing a wizard for writing the tests.
The second workshop part revealed the dependencies between debug options offered by the MCU itself and their influence on the debugging functionalities available to a developer in the debugging tool. Several participants called it a revelation to see in life demos how the amount and quality of debug and trace information changes between different MCUs.
Next workshop is planned in Stuttgart on 25th February 2010. And more workshops will follow all over Germany! Please check our event calender!
All I want for Christmas… is to thank you all for your confidence in iSYSTEM and iSYSTEM products! The past year was demanding – you all know – but we used the chance and put all our might in developing a new generation of products!
Free 1-day workshop on isystem.connect, Tracing, Profiling and Code Coverage Dates scheduled: 9th Feb.2010 in Schwabhausen, 25th Feb.2010 in Stuttgart Click here for agenda and registration details
We wish you all a merry Christmas and a happy New Year! Have a happy holiday season and a new year filled with peace and prosperity!
iSYSTEM’s winIDEA fully supports Python 2.6 since version 9.10.31. This allows developers to run Python scripts inside winIDEA and also to call winIDEA functions from Python scripts running at command line. In a debug and test environment this adds powerful debug and unit test capabilities and control over external hardware while running tests from script, e.g. when running HIL tests (Hardware In the Loop).
WinIDEA is the integrated development environment designed by iSYSTEM. WinIDEA contains all tools necessary for embedded software development (e.g. edit, build, debug and test) in one shell. Additionally WinIDEA interfaces and drives all Blue Boxes – the various On-Chip debuggers and In-circuit emulators manufactured by iSYSTEM.
Python is a popular scripting language with extensive programming capabilities available on Windows, Mac OS X and Unix operating systems and is much more flexible than e.g. shell scripts or batch files.
In the year 2010 an embedded software development and test workplace could look like this: In addition to a software development tool that would be a debugger with or without trace support, a stimulation hardware for the target system is used (e.g., sbRIO from National Instruments as a mini-HIL).
Thus, a developer may drive a lot of function tests already while developing software. All is done in a single tool environment that is as close as possible to the real hardware (and real-time) as well as in an early stage of the development and test process.
The connection between NI's sbRIO platform to iSYSTEM tools is realised using iSYSTEM's open API isystem.connect. This generic interface also includes a free LabVIEW VI library to drive the described test approach from within LabVIEW.
iSYSTEMs running team will participate again at #B2RUN Munich. As every year, it will be a fantastic atmosphere along the track and may provide the right drive for iSYSTEM’s runners! Get an impression of the run and the iSYSTEM TEAM before, during and after the run: Live streamand pictures (available starting July 24) of the run. Additional photos will be provided via this blog and on flickr. We all hope that the announced thunderstorms will not go down in Munich:-).
iSYSTEM's vision is to easily enable developers and testers using and integrating embedded development and test tools within the complete development process. iSYSTEM's software architecture (blue box architecture) includes several interfaces. Most important is the isystem.connect interface that allows the integrated development environment winIDEA to be driven by an external application which can actively steer it or just acquire data from a target. This could be an Excel script filling a table of temperature readouts over time, a production stage application which programs the microcontroller FLASH and verifies RAM, an application which, through data acquisition, realizes unit tests, a hardware-in-the-loop system test, etc. In addition to above interface iSYSTEM provides a so called plug-in API that enables applications to become part of winIDEA. Thus a user may easily extend and tailor the functionality of the IDE.
Here are some examples for plug-ins already implemented in winIDEA:
Virtual Console A small graphical interface plug-in to add some visualization on the PC. As an example iSYSTEM provides a traffic light demo that uses the ARM or MPC simulator included in iSYSTEM's IDE.
Watch XML This sample plug-in is delivered with source code. It serves as an example on how to write your own plugin. Its functionality is similar to a watch window but its content is defined by an external XML definition file.
GDB server This plug-in implements GDB services through which access to and control of the target application is provided to gdb and other tools that use the gdb remote serial protocol to winIDEA.
XCP This plug-in implements the XCP protocol support in a similar fashion as the GDB protocol. A debugger may connect via a standard debug interface such as JTAG to a target system and read out data. This data can be sent via XCP to an application that “understands” this protocol (e.g., Vector CANape) to visualize this data. This may unload the sometimes high CAN bus load.
Sciopta Kernel Awareness This plug-in was developed by Sciopta. It displays the current state of the operating system, including tasks, stack usage etc.
PowerPC 55xx MMU & cache viewer This is a MPC55xx specific plug-in. It displays the current configuration state of the memory management unit and CPU cache in full detail.
NEC V850 Cycle Counter This is a NEC V850specific plug-in. It displays the state of the cycle counter, which indicates the number of CPU cycles elapsed since the last time the CPU was stopped. This provides a simple performance measurement metric.
Cortex Status This is an ARM Cortex M specifc plug-in. It displays various CPU diagnostic information, like number of CPU cycles executed since RESET, number of CPU cycles executed spent processing exceptions, number of CPU cycles spent sleeping etc.
The SDK directory is part of the winIDEA installation and contains sample code and documentation of all iSYSTEM APIs.
Blogteam: Erol, in the last weeks we learned how tracing and profiling help to detect bugs and bottlenecks in embedded applications and assist in improving the performance. Now let´s talk about Code Coverage. Erol, can you explain us what it does?
Erol: Code coverage is mostly used to detect dead code, that is code that is not executed (not tested). Code coverage is a functionality of an emulator and on-chip debugger with trace to record and document all addresses that are executed and accessed during program execution. With iSYSTEM tools this is done without instrumenting the code, on the object code level. Other tools work on the source code level and use code instrumentation to measure at least 4 different ways of code coverage: Statement or Execution Coverage, Decision or Branch Coverage, Path Coverage and Condition Coverage.
Statement or Execution Coverage checks if every instruction has been executed at least once. 100% Statement coverage confirms that there is no code that has not been executed. But this does not cover the context of the code e.g. if/else instructions where only one branch can be executed in a single test. Here could be an undetected fault despite 100% statement coverage. Due to that decision coverage tests are used to check if all code branches dependent on a true/false decision are executed. To check not only that boolean expressions in control structures have been tested but every possible path in every function Path Coverage is used. Complete path coverage tests every possible way from the entry to the exit. Hierarchic conditions are reviewed by the Condition Coverage test. Boolean conditions are checked with true and false, multiple conditions are tested with every atomic condition set to true and false.
Each of these different code coverage forms require a different number of test cases. Modern tools can create test cases in a half automated manner. Dependent if these tools are based on source code or on object code different coverage forms are available.
Blogteam: Ok, and what will it do for me?
Erol: Code Coverage helps you to improve the quality of your application, for instance to identify "dead" code, to detect non-initialized variables, to monitor stack consumption of an application. Because we do not instrument your code, we do not influence the runtime behaviour of your application. So your test cases show you the reality, also in worst-case scenarios. A totally different aspect to code coverage is that today many companies need to comply to safety related standards and have to document their complete development process including testing. Code coverage tools allow you to automate test case generation and the recording of test results.
Blogteam: So, you think Code Coverage could help to reduce development costs too?
Erol: Well, I think it will reduce the overall costs within the complete development cycle. Especially if you think about the costs after a product has been pushed into the market. Today it is extremely important to detect and remedy a bug as soon as possible.
iSYSTEM and GÖPEL electronic join forces in the field of hardware component tests. The technology partnership between GÖPEL and iSYSTEM is the catalyst for prompt preparation and integration of microcontroller knowledge into existing GÖPEL tools.
Up to now both companies worked in different areas of the product development process: iSYSTEM in the area of software development as well as software test and verification for embedded systems, whereas GÖPEL specialized in Boundary Scan tests which are tests associated to hardware production.
To cope with the challenges of future hardware components tests, boundary scan and JTAG emulation must be combined. For this merge extensive microcontroller knowledge is necessary. Emulator and debugger manufacturers like iSYSTEM have developed this expertise over many years.
iSYSTEM is now select member of the so called GATE (GOEPEL Associated Technical Experts) program.
iSYSTEM's vision is to easily enable developers and testers to use and integrate embedded development and test tools within the complete development process. iSYSTEM's software architecture (blue box architecture) includes several interfaces that allow the integrated development environment winIDEA to be driven by an external application that can actively steer it or just acquire data from a target. This could be an Excel script filling a table of temperature readouts over time, a production stage application, which programs the microcontroller FLASH and verifies RAM, an application which, through data acquisition, realizes unit test, a hardware-in-the-loop system test, etc. Adapters for several industry standard protocols like GDB, OLE Automation, LabVIEW, and XCP are built on top of these interfaces and are shipped alongside the IDE. More info www.isystem.com/connectivity
One of iSYSTEM’s strengths is the connectivity to other products along the
complete development process of an embedded system. The benefits of this
connectivity for a customer include automating major parts of a development as
well as traceability throughout the complete development process. The majority
of iSYSTEM’s products present a link between the embedded system and the host
PC. Open interfaces allow for the flexible integration and application of the
iSYSTEM solutions in the entire development process.
In our new video library you will find some statements
of iSYSTEM partners who already use these open interfaces to connect their tools
to iSYSTEM tools to generate the added value as described above.
