TASKING VX-toolset for TriCore and PCP v3.0r1


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:

Quick Start

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.

Licensing issues


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.

General Improvements


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'.

TriCore C++ Compiler

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.

TriCore C Compiler

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.

PCP C Compiler

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