TASKING VX-toolset for TriCore v6.0r1
Release Note


This release note covers the changes between v5.0r2 and v6.0r1 of the TASKING VX-toolset for TriCore.

For release notes prior to v6.0r1, please visit the TASKING TriCore support website.


Important Notices


Support for the special function registers (SFR) of the HSM is available through a separate installer. For security reasons related to the HSM,  Altium will verify the possible availability of the SFR installer to an end user with Infineon. Once Infineon gives Altium permission to release the SFR installer, we will make it available through a secure FTP location.

DAS 4.6.0 support

The v6.0r1 has been tested with the latest DAS version 4.6.0 of Infineon. No problems have been found. It is recommended to use DAS 4.6.0  with TriCore v6.0r1. Download here.

Linker problem with an MCS stand-alone AURIX PLUS project

Refer to AURIX PLUS support and TCVX-40319.

In normal conditions you will need a TriCore application which initializes the MCS memories (via the copy-table). However you have the possibility to create an elf-file for MCS without TriCore though. This gives no problems with the AURIX derivatives (tc1.6.x). When tryin gthis for the new architecture AURIX PLUS (tc1.6.2) you will encounter a linker problem.

There are no AURIX PLUS derivatives yet available, hence only the processors "userdef162" has been made available for preliminary projects. When you try to build an MCS project for AURIX PLUS using processor "userdef162" you will get the linker error "lmcs F019: unrecoverable error: caught unknown exception". This is caused by the 'copy' attribute in the vector-table entries. The attribute is essential, because otherwise the tables are not initialized via the copy-table. You could create your own variant of the userdef162.lsl and the included gtm lsl file. Then remove the copy attribute defined at the begin of the gtm lsl file. However, since an MCS without TriCore does not really make sense it is advised to wait for the next release in which this inconvenience will be resolved.

New in v6.0r1

This section gives an overview of the most important new features and improvements in v6.0r1. See the sections with fixed issues for a complete list.

AURIX Configuration Tools (ACT) v1.0rb3

This new toolset release includes the first version of the AURIX Configuration Tools (ACT), provided to you in collaboration with Infineon Technologies. ACT consists of three main components:

While the Pin Mapper and the RTOS are qualified and fully released components, the iLLD Configurator is provided as the third public beta, based on iLLD files from Infineon that do have the beta status. While using ACT, you may occasionally check if there are any updates available through the update option in Eclipse.

ACT is provided as complimentary Bonus Technology and supported to a limited level.

TASKING Pin Mapper for AURIX

Nowadays many microcontrollers are equipped with a large number of on-chip peripheral modules.These microcontrollers are made available in surface mount packages with various numbers of physical pins. The number of pins usually does not allow all peripheral modules to be used simultaneously. Hardware registers on the microcontroller allow for configurable assignment of peripheral module signals to physical pins. This means that you have to select the proper device for your application and properly initialize hardware registers from software. The purpose of the TASKING Pin Mapper is to assist you in performing those tasks.

The TASKING Pin Mapper is integrated in the AURIX Configuration tools. For more information about using the TASKING Pin Mapper, see the "Pin Mapper user guide".


Most applications consist of tasks with both hard and soft real-time constraints. If these tasks are single purposed, you could implement them as semi-independent program segments. Still you would need to embed the processor allocation logic inside the application tasks. Implementations of this kind typically take the form of a control loop that continually checks for tasks to execute. Such techniques suffer from numerous problems and do not represent a solution for regular real-time applications. Besides, they complicate the maintenance and reusability of the software.

A Real Time Operating System (RTOS) is a dedicated operating system fully designed to overcome the time constraints of a real-time system. An RTOS, like any other operating system, provides an environment in which you can execute programs in a convenient and structured manner, but without the risk of failingthe real-time constraints.

The TASKING RTOS is integrated in the AURIX Configuration tools. For more information about using the TASKING RTOS, see the "TASKING RTOS user guide".

TASKING Software Platform for AURIX

With TASKING Software Platform you can quickly configure drivers which can be used in your applications. A Software Platform is made up of iLLD Drivers from Infineon. The exact contents of a Software Platform depend on the need of your application. The Software Platform Builder is used to manage your Software Platform. It is both a graphical editor and a code generator. Collections of software modules are delivered as Software Platform repositories.The driver configuration also incorporates initialization code generated by the TASKING Pin Mapper.

The TASKING Software Platform is integrated in the AURIX Configuration tools. For more information about using the TASKING Software Platform, see the "Software Platform user guide".

MCS compiler toolset

The MCS toolset has been updated to support the GTM 3 which is available in the AURIX PLUS architecture. In this toolset the new and first MCS compiler is integrated.

Contact Altium for a license upgrade if you want to use the GTM/MCS compiler.

Refer to TCVX-40688.

Support for the new architecture AURIX PLUS TC1.6.2

With this release support is added for the new AURIX PLUS architecture TC1.6.2. Although there are no derivatives yet available it is already possible to design you applications using the special cpu name userdef162. Support is available in the IDE, compiler, assembler, linker and debugger.

The various derivatives of the achitecture will support 1 to 6 TriCore cores (TC1.6.2P) and 0 to 10 MCS cores, 1 Standby Controller (XC800) and an optional Hardware Security Module (HSM). The PFlash can go up to 16MB (distributed between the TriCore cores) and DFlash to 1MB.

Refer to TCVX-40319.

Support for new TC1.6.2 instructions

The new architecture AURIX PLUS comes with an extension to the instruction set.

CRC32 for big endian data
Planned. Via intrinsic.
CRC32 for little endian data
Planned. Via intrinsic. Yes
CRC32 for byte data
Planned. Via intrinsic. Yes
Arbitrary width and polynomial CRC calculation Planned. Via intrinsic. Yes
Reorder bytes within word Planned. Via intrinsic. Yes
Count number of bits set in word Planned. Via intrinsic. Yes
Floating point (32bit) to half precision floating point (16bit) conversion
Half precision floating point (16bit) to floating point (32bit) conversion Yes
Load high bits of address value No

The LHA instruction is partially implemented. Only an immediate can be used in the instruction. For the next release it is planned to support relocations too.

Simulator update

To support the new AURIX PLUS architecture it is required to upgrade to the latest simulator from Infineon, TSIM v1.16.62. Therefore this version is included in this release.

Also the PCP simulator has been upgraded to, TSIM v1.38. This version is also included in this release.

New AURIX PLUS simulator configuration

When running the simulator for AURIX PLUS it is required to specify the option -tc162p. This needs to be done via the new defined OConfig file. This is because the default behavior of tsim16p_e is that of AURIX™ Performance core TC16P (B-Step).

This is done automatically by the IDE when creating a new project for the AURIX PLUS architecture.

Support EABI v2.9

With this release, updates have been made to fulfill the new EABI v2.9.

EABI: DWARF version 2.0 or higher

Refer to EABI v2.9 chapter 4.5.

The DWARF version is no longer restricted to 2.0. In the EABI compliant mode (--eabi-compliant) the DWARF version was forced to 2.0. With this release this is no longer valid. The EABI DWARF version is the default, being 3.0. Nevertheless it is still possible to use --dwarf-version=2 to force dwarf 2.0 to be generated. However, this option has been deprecated and will be removed in a future major/minor release.

EABI: Extended functionality for base registers A0 and A1.

Refer to EABI v2.9 chapter and 4.2.3.

The section names for variables declared with __a0 and __a1 have changed. As well as the fact that __a1 can be declared without const.
Before EABI v2.9 (old)
Since EABI v2.9 (new)
int const __a0 var;
int const __a0 var = 1;
.rodata_a0 , rom
int       __a0 var;
int       __a0 var = 1;
int const __a1 var;
int const __a1 var =1;
.ldata , rom
.rodata_a1 , rom
int       __a1 var;
int       __a1 var = 1;
The #pragma section now supports for all 4 base register the type: a<n>data, a<n>rom and a<n>bss. The behavior is conform the above table.

You should take care of extending your LSL like:

     select ".sbss.*"
     select ".bss_a0.*"
     select ".sdata.*"
     seelct ".data_a0.*"
     select ".ldata.*"
     select ".rodata_a1.*"

Please note that mixing A0 rodata and A1 rodata may not be possible or may lead to undefined behavior.

EABI: Support data type _Float16

The _Float16 type is defined in "ISO/IEC TS 18661-3 Draft Technical Specification – December 4, 2014 WG14 N1896"

Refer to EABI v2.9 chapter 2.1.2.

Refer to TCVX-40522.

The new architecture AURIX PLUS supports an instruction to convert a 32-bit float into a 16-bit float, and one to convert it from 16-bit to 32-bit. The TriCore compiler now supports the _Float16 type ( as defined by the ISO draft specifications ). Although the EABI mentions data type __float, this may be changed when the specification is final. When required you can use "#define __float _Float16" (or via compiler command line option -D__float=_Float16) to comply to the current EABI version.

Note: The _Float16 type is only a storage type, meant to save memory space. When doing calculations a _Float16 variable will first be converted to a normal float and afterwards converted back.

In the floating point library 4 new files have been added for the run-time conversion between 16-bit and 32-bit floats:

For these sources the header libfloat.h has been added to the include directory.

New Integrity Check utility

In this release a new utility is being integrated, the Integrity Check utility (ichk). With this utility you can check the integrity of an application. This utility checks access restrictions on memory in light of ASIL specifications and MPU configuration.

Based on an ISO 26262 ASIL level it is required to partition code and data into different safety groups. This is especially required within multi-core automotive applications. Different safety groups have different verification and validation criteria. Subsequently, safety groups have to be isolated from each other: bugs in low-safety-level code should not effect high-safety-level data, and high-safety-level code should not depend on low-safety-level code. So, low-safety-level code is not allowed to write in high-safety-level data sections, and high-safety-level code is not allowed to call low-safety-level functions.

The integrity check utility analyzes an ELF file for possible violations of these safety restrictions. It tries to rule out possible traps by the MPU at run-time. As this is based on local static analysis, not all possible violations can be found, and false positives may occur.

The partitioning of the application is done in LSL definitions.You can define different named safety groups by selecting either sections by name or by address ranges. The linker reads and interprets the LSL file and adds an extra section to the ELF file with all memory areas and their corresponding safety level and a list of all restrictions between different safety levels.

The compiler adds extra ELF sections with verification information about a) which variable is accessed by which function and how it is accessed and b) data flow information.

The integrity check utility reads the verification sections added by the compiler and the linker and analyzes the application for possible violations of these safety restrictions.

Contact Altium for a license upgrade if you want to use the Integrity Check utility.

In the Eclipse IDE this utility can be enabled via the checkbox "Check software partitioning (ISO 26262-6:7.4.11)" on the Properties->C/C++ Compiler->Diagnostics tab. Refer to the TriCore user guide, chapter "8.10 Integrity Check utility".

Refer to TCVX-40687.

New compiler option --software-partitioning-info

With this option the compiler adds information about symbol accesses to the output file in special verification sections. This information can be used by the integrity check utility.

New linker option --software-partitioning-info

With this option the linker adds information about section access rights to the output file in special verification sections. This information can be used by the integrity check utility.

The access rights have to be specified in LSL using the new safety class extension description. Refer to the TriCore user guide chapter "8.10.3 Define safety class areas and access rights".

New compiler option --control-flow-info

With this option the compiler adds control flow information to the output file. The compiler generates a .debug_control_flow section which describes the basic blocks and their relations. This information can be used for code coverage analysis on optimized code.

Eclipse IDE update to version 'Luna'

This release holds an updated version 4.4.1 with CDT 8.5.0 of the Eclipse IDE named Luna. For features, improvements and bug fixes please refer to the Eclipse community web-site.

Updated SFR Files

The following derivatives have updated SFR files:

SFR support for the new AURIX derivative TC27x D-step

SFR support has been added for the AURIX derivative TC27x D-step. Refer to TCVX-40140.

Removed obsolete derivatives TC11iB and TC2D5T

The derivatives TC11iB and TC2D5T are discontinued by Infineon and have therefore become obsolete. Hence the support for these derivatives has been removed. All dedicated TC11iB and TC2D5T files, like libraries, have been removed too.

MMU libraries

Only the tc1130 has optional MMU support. Therefore only for tc1130 there are special MMU libraries: ctc/lib/p/tc1130_mmu and ctc/lib/tc1130_mmu. These are the original tc13_mmu libraries.

All other MMU libraries have been removed from the distribution.

Deprecated tool option --dwarf-version=<n>

Option Comment / tool messages
By default in EABI compliant mode, the DWARF version is 3.0. The option can still  be used, but in a future major/minor release the option will be removed.

ctc: W768: --dwarf-version has been deprecated, DWARF 3.0 is default
astc: W720: Dwarfversion < 3 is deprecated

Deprecated data type __bit

Data type
Comment / compiler message
__bit The __bit data type (used by the deprecated __atbit() qualifier) is being deprecated since it is the same as _Bool. Hence the _Bool data type should be used instead.

W769: for object "<xxx>", __bit has been deprecated, use _Bool instead

Removed (deprecated) options

--cpu=tc<xxxx> the control program still recognizes this option and translates this to "-D__CPU_TC<xxxx>__ -D__CPU__=tc<xxxx>" for the tools
--tasking-sfr the control program still recognizes this option and translates this to "-Hsfr/regtc<type>.sfr" for the compiler and "-Hsfr/regtc<type>.def" for the assembler
--no-tasking-sfr -
--no-default-section-alignment use --code-section-alignment and --data-section-alignment
--section-per-data-object -
--runtime-prefix=<text> use linker --new-task
--symbol-prefix=<text> use linker --new-task
--fpu-present -

Removed (deprecated) qualifier __atbit()

__atbit() use classic method of C masking and shifting, intrinsic functions __extru and __imaskldmst or bitfields.

Removed C++ automatic instantiation options

With the advent of C++11 the exported templates feature has been dropped.

In the C++ compiler automatic template instantiation was enabled by default. This causes the C++ compiler to generate an extra file with the .ti file name suffix. However, for compatibility with existing code and older compilers the C++ front end does not require this in some modes.

So this .ti file can be prevented from being generated by turning off automatic template instantiation.

This also means that the command-line options that go along with this disabled feature have become useless too. Hence these are removed. When being used, the C++ Compiler will throw an error.


Refer to TCVX-40257.

High Level Dumper new features

1) In an application there is always only one entry-point. This is masked with _START. However in a multi-core application the _START is only working for CORE0. The other cores have no marker. To be able to dump the call-graph for another core a new option is introduced by which the start-address or function can be specified:


When using this option the --copy-table option has to be specified too.

Refer to TCVX-40289 and TCVX-40366.

2) With the introduction of the Integrity Check utility the High Level dumper has been extended with the -Fa sub option. This option will dump the safety groups, access rights and the verification section contents of an application (when build with --software-partitioning-info option).

Script debugger multi-core hardware debug support

With this release the script debugger is now also supporting multi-core debug. An example can be found in the distribution which demonstrates this feature: ctc\examples\dbgtc\multicore.

Refer to TCVX-40534.

New script debugger examples

Two examples have been added to the release which show the usage of the script debugger. These may help you to create scripts for running automated tests. The examples are: ctc\examples\dbgtc\multicore and ctc\examples\dbgtc\execution.

Refer to TCVX-40534 and TCVX-40435.

Fixed issues for v6.0r1


New Feature


The list of open issues for v6.0r1 can be found on the internet.

Quick start

For a quick start, just start the TriCore Eclipse IDE 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 project examples, PCP project examples, MCS project examples, 8051 project examples and/or ARM example projects.

Another icon on the Welcome page, the 'First Steps' icon, links to the 'TriCore Getting Started' document. This is a good starting point for exploring the capabilities of the environment and the tools.

License Information

TASKING products are protected with TASKING license management software.

License key

You need a license key when you install a TASKING product on a computer. When you order a TASKING product from Altium or one of its distributors, a license key will be sent to you by email or on paper.

See the Getting Started with the TASKING VX-toolset for TriCore guide for information on obtaining a license.

Local TASKING License Server (not applicable to evaluation licenses)

If you have ordered a TASKING product with a floating license, you can have it serviced by the Remote TASKING License Server (the most convenient solution) or through a Local TASKING License Server (in case you have no external network access for example). Consult your Altium representative for assistance on deciding what the best setup would be for your situation.

If you like to setup up a local license server, we kindly refer you for more information to Support for TASKING License Management System (TLM) on our website. Here you can also download the Local TASKING License Server package.

It is advised that you install the Local TASKING License Server before you install products that require this server.