TASKING VX-toolset for TriCore and PCP v3.0r1
RELEASE NOTE
This release note covers the TASKING VX-toolset for TriCore and PCP version 3.0r1. The toolset
comes with a new IDE, based on Eclipse and the latest TASKING debugger technology. New C Compiler
optimizations have been introduced and the EDG front end of the C++ Compiler has been updated.
The new 'Audo Future' derivatives TC1767 and TC1797 are supported.
The following parts are described:
For a quick start, just start the 'TASKING VX-toolset for TriCore and PCP' from the
start menu. This will start the Eclipse based development environment. You will
be asked to select a workspace. In case you used Eclipse before it is
recommended to select a new workspace. After clicking OK, you will see the
'Welcome' view. On this view you will see icons that link to specific
information. You can, for example, select the 'Samples' icon and import the TriCore
examples and/or the PCP examples.
Another icon on the Welcome page, the 'First Steps' icon, links to the
'TriCore Getting Started' and the 'PCP Getting Started' documents. This is a good
starting point for exploring the capabilities of the new environment and the tools.
Bundles
Altium's TASKING VX-toolset for TriCore and PCP is available as Standard, Professional
and Premium Edition.
At installation time all tools are installed, no matter what bundle you purchased. However,
each tool is protected with its own unique key. Together with the software you receive a set
of keys - specific for the bundle - unlocking the appropriate tools.
15-day Trial
When using the product without a valid license, the tools will run in
trial mode. This means you can use the toolset 15 days with
full functionality. When running in trial mode, each tool will report this.
Eclipse
The Integrated Development Environment (IDE) that is built
on the Eclipse framework provides a seamless workbench
for the complete toolset including the debugger of
the VX-toolset. The IDE provides facilities for project
configuration and management, C/C++ and assembly code
aware editing, build management, debugging, profiling
and more. It provides wizards to help you to set up your
embedded TriCore or PCP project and to configure your
target board settings to debug your project on hardware.
The Eclipse editor supports C, C++, assembly language
and header files with syntax highlighting, auto completion,
context assistance and tool tips. As you would expect from
a de facto standard IDE, it provides full support for all
relevant source code version control systems.
Conversion tool
A conversion tool is available to help you migrate your
EDE/CodeWright project to the new Eclipse based environment.
The tool can be started from the
File|Import...|TASKING C/C++|TASKING TriCore EDE Projects menu.
Derivatives support
The devices tc1910/tc1912/tc1920b and pxb4225/pxb4260 have become
obsolete, therefore they are not supported anymore in this version
of the toolset.
The new AUDO Future derivatives tc1767 and tc1797 are supported.
These devices are based on the TriCore 1 V1.3.1 architecture, which
adds an expanded instruction set as compared to the TriCore 1 V1.3
architecture. ELF files created for the new derivatives will have
the E_FLAGS field set to EF_TRICORE_V1_3_1, indicating the new architecture.
Sfr files in include/sfr
The files describing the special function registers for each derivative
(with extensions xml, def and sfr) are moved to a separate directory 'include/sfr'.
The C++ compiler is based on one of the latest versions of the EDG front end,
version v3.8, which conforms well to the ISO/IEC 14882:1998 C++ standard. By
upgrading to version v3.8 the usage of the C++ compiler has changed as well.
Refer to the 'TASKING VX-toolset for TriCore User Guide', specially section
'11.2 C++ Compiler Options', for detailed information.
Code profiling
Profiling is the process of collecting statistical data about an
application. With these data you can analyze which functions are called,
how often they are called and what their execution time is.
Two methods, dynamic and static profiling, are provided.
When applying dynamic or run-time profiling, the compiler adds code to your
application that takes care of the profiling process when the application is
executed.
Static profiling provide a good alternative if you do not want that your code
is affected by extra code. This method is less accurate however.
The IDE provides facilities for showing the profiling data in a
graphical way.
Run-time error checking
The new option --runtime controls a number of run-time checks to
detect errors during program execution.
User mode option
To implement the workaround for silicon bug CPU_TC.068, the compiler used to
generate ENABLE and DISABLE instructions. However, since these instructions are
not allowed when the TriCore is operating in User Mode 0, this used to
lead to a trap.
With the new option --user-mode you can tell the compiler in which mode
(part of) the application is running. For instance when --user-mode=user-0
is selected, the compiler is forced not to use restricted instructions such as
the ENABLE and DISABLE instruction.
Core selection
With the new option --core it is possible to specify which core is used.
This option is relevant only if the --cpu is not specified as well, since
the compiler is able to derive the core from the selected cpu.
For example if --core=tc1.3.1 is specified, the compiler is allowed to use
the new instructions as introduced in the TriCore 1 V1.3.1 architecture.
GUI support
The IDE allows you to create both TriCore projects and PCP projects. A
PCP project always requires the presence of a TriCore project as well, before it
can be debugged.
A PCP project contains the PCP code for one of the channels, the TriCore project
contains the TriCore code that at least starts one of the PCP channels.
Refer to the PCP examples and the 'PCP Getting Started' document, on how to set
up a PCP project using the IDE.
Note that the PCP assembler is no longer part of the TriCore tools in the 'TriCore\ctc'
directory, it is located in the 'TriCore\cpcp' directory instead. If you are using the
control program to invoke the PCP assembler, then select the PCP control program for
this purpose.
The TriCore control program does not support the PCP assembler anymore.
As a consequence it is no longer possible to have PCP code as part of a TriCore project.
First, always the PCP tools are used to create a relocatable output file (linked only) in a
separate PCP project. Next the TriCore tools are used to create the absolute
output file (linked and located) using the created relocatable PCP output file.
Far support
The new memory qualifier __far allows you to put variables in the TriCore linear space.
This way you can share memory between the TriCore and PCP cores. The PCP example
'pcp-multi' shows how to implement the sharing of memory.
Interruptible channels
With the new option --interrupt-enable it is possible to have PCP code that
can be interrupted. This is not trivial since the PCP tools uses a static
stack mechanism for performance purposes. Please refer to the PCP example
'pcp-multi' on how to set up a project with multiple, interruptible channels.
Also refer to the 'PCP User Guide' document, section 1.8.2 for more information
on the subject.
Global compiler optimizations
By using mil-linking, all sources can be fed to the compiler at once. This means
that the compiler can take care of application wide (global) optimizations, such
as code compaction.
By using another technique called 'memory partitioning', it is possible to reduce the
number of times the data pointer needs to be reloaded.
These optimizations lead to more compact code.
Linker optimizations
For C++ projects it is required that the linker cleans up multiple equal
template instantiations, to avoid the code-size to grow unnecessary.
Therefore the linker optimizations 'delete-unreferenced-sections', 'delete-duplicate-code'
and 'delete-duplicate-data' are switched on by default.
Calls directives/stack usage
The compiler generates call graph information and stack usage for each function.
The linker gathers this information and prints the call graph and an estimation
of the stack usage in the map file. Note that this estimated stack usage is the
sum of the user and the interrupt stack.
The library sources are stored in a packed file in the library directory.
To unpack this file just execute the 'install-lib-sources.exe' tool in the
library directory. Without a valid license the library sources cannot be unpacked.
Integrated debugger
The VX-toolset's debugger is based on Altium's latest
debugger technologies released in 2006. The debugger
has been redesigned from the ground up and made
ready for market trends like integrated kernel-awareness
and multi-core debugging. Utilizing the Eclipse IDE
workbench it comes as a plug-in with a seamless
integration to the editing environment. With the
VX-toolset for TriCore and PCP it provides an execution
environment for the simulator and for the supported boards.
MiniWiggler II support
The TASKING debugger is compatible with selected Infineon starter kits through DAS.
As physical connection either a parallel cable through an on-board wiggler can be used, or
Infineon's USB-JTAG Wiggler box or the so-called MiniWiggler II.
Hitex board 1766 and 1796
Two boards of Hitex have been added to the list of supported target boards, notably
the 'Hitex HiMOD TC1796 Applications Module' and the 'Hitex MMTC1766 Minimodule'.
Simulator configuration
The configuration files MConfig and DConfig are read in and used by the simulator.
This configuration depends on the derivative being used. If the IDE is used, these
configuration files are created and updated automatically.
Flash support
If enabled, the target application is downloaded onto the target. If the debugger detects that
the download area contains flash memory, it will automatically start up the built-in flash tool.
Limitations debugging the PCP
Currently the debugger is not able to show a stack trace for PCP applications. The PCP
tools create a static stack, and the debugger does not know how to retrieve return addresses
if no stack or frame pointer is available.
When DWARF Debugging Information Format v3.0 is used, it would be possible
to retrieve this kind of information. However that would be in contradiction with the EABI
that prescribes the DWARF v2.0 standard.
All stack related features, such as stack breakpoints and return from function won't work
for the same reason.
Copyright 2007 Altium BV