TASKING VX-toolset for TriCore v6.1r1
Release Note (updated: 24-10-2016)


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

For release notes prior to v6.1r1, 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.

Cross-Linking statement

Cross-linking allows linking of (e.g. validated) object code built with a certain toolset release into a project that is being developed with a newer toolset release.

For this version of the toolset, Altium guarantees compatibility of code developed with version v4.2r2 and v5.0r2 of the product, under specific conditions. For the list of conditions, please refer to the TASKING VX-toolset for TriCore User Guide, paragraph 7.5.

Fix in TriCore EABI bit-field alignment violation - backwards compatibility option

TriCore EABI v2.9 Chapter Bit Fields:

"Except for the special case of zero-width bit fields, or to comply with the prohibition against crossing more than one Half-Word boundary, bit fields are always allocated beginning with the next available bit in the union or structure. No alignment padding is inserted, except for the two cases noted"

The TriCore C compiler implementation was not according to this chapter. With this release this has been corrected.

To be able to be backwards compatible the C compiler --eabi option has been extended, --eabi=+char-bitfield. This option is only required to support backwards compatibility with TriCore C compiler versions prior to v6.1r1.

Please refer to TCVX-38895.

DAS 5.0.0 support

The v6.1r1 has been tested with the latest DAS version 5.0.0 of Infineon. It is recommended to use DAS 5.0.0 with TriCore v6.1r1. Download here.

Note that multi-core debugging may not work as expected with DAS v5.0.0. DAS v4.6.0 may resolve them. Please contact our Customer Support for recommendations.

Tool build number change

Up to the previous release each tool was represented by its own dedicated build number. With this release all tools in the product have the same build number. The build number has changed from 3 digits to 8.

In case you are using scripts that read the banner information or note sections from the tool invocation or generated files, it might be necessary to update your scripts to accept the updated build number.

8051 toolset upgrade

Altium is constantly improving the TASKING development, build processes and the environment. Up to the previous version of the TriCore product the various target toolsets were maintained separately and integrated during releasing. With v6.1r1, all target toolsets are already integrated during development. This means that there are no differences between the various target tools (like compiler and archiver) other than target specific features.

For the 8051 toolset this was a great step forward since the v6.0r1 release. Many updates have been applied, too many to mention them in this release note. Therefore, please see the TASKING VX-toolset for 8051 User Guide for all available options of the tools.

TASKING Debugger

The various target toolsets all used to have their own debugger, which was located in the bin directory (e.g. in ctc/bin and carm/bin). With this release the various debuggers have been merged into just one and it is located in the bin directory in top of the installation directory, adjacent to e.g. ctc and carm. In this directory also the script debugger (dbgtc) is located.

AURIX™ Configuration Tools (ACT) iLLD driver

Infineon occasionally updates the iLLD driver. While the TASKING Eclipse update mechanism tries to follow the same update pace there can nevertheless be delays. Please retry to update at a later time or contact TASKING support for more information. To find out which version of iLLD you are using click the iLLD service in your software platform document and inspect its properties.

New in v6.1r1

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

Support for BOSCH ADX Specification (TriCore and MCS)

The output produced by the TASKING High Level Dump utility can be used as input for address calculation tools. The output format is compliant with "BOSCH ADX Specification, Address List Format for A2L Address Calculation Compiler vendors, Version 1.10, 2015-04-27".

Refer to TCVX-41238.

Eclipse IDE update to version 'Mars SR1'

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

TriCore: AURIX™ Configuration Tools (ACT) v1.0r1

This new toolset release includes the latest version of ACT v1.0r1. Enhancements are:

For more information see the manuals Using the TASKING Pin Mapper for AURIX and Using the TASKING Software Platform for AURIX.

TriCore: Support for the new architecture AURIX 2G, TC1.6.2

With this release simulator support is added for the new AURIX 2G architecture TC1.6.2. There is currently one derivative available, TC39x A-Step. However, you may design your applications for TC3xx in general by 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 16 MB (distributed between the TriCore cores) and DFlash to 1 MB.

Refer to the TC3x user manual of Infineon for more information.

TriCore: Simulator update

To support the new AURIX 2G architecture the latest version of the simulator from Infineon, TSIM v1.16.80, is included in this release.

The PCP simulator has been upgraded too. TSIM v1.39 is included in this release.

TriCore: New AURIX 2G simulator configuration

When running the simulator for AURIX 2G it is required to specify the option -tc162p. This needs to be done via the newly 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 you create a new project for the AURIX 2G architecture.

TriCore: Compiler support for AURIX 2G derivative TC39x A-Step

The Compiler support for the TC39x A-Step is based on user manual v1.3 of Infineon. Register files have been updated accordingly and are available in this release.

TriCore: New C compiler intrinsics for AURIX 2G

New compiler intrinsics have been added to support the AURIX 2G architecture better. These intrinsics are:

Intrinsic Function
uint __crc32b( uint b, uchar a )
Calculate the CRC of 8 bits of 'a' and return the result. The fist argument 'b' contains either an initial seed value, or the cumulative CRC result from a previous sequence of data. Generates the crc32.b instruction.
uint __crc32bw( uint b, uint a ) Alias for (existing): __crc32( uint b, uint a )
uint __crc32lw( uint b, uint a )
Calculate the CRC of four bytes in little-endian order of 'a' and return the result. The fist argument 'b' contains either an initial seed value, or the cumulative CRC result from a previous sequence of data. Generates the crc32l.w instruction.
uint __crcn( uint d, uint a, uint b )
Calculate the CRC value for 1 to 8 bits of 'b' using a user-defined CRC algorithm with a CRC width from 1 up to 16 bits and return the result. The first argument 'd' contains an initial seed value, or the cumulative CRC result from a previous sequence of data. The second argument 'a' specifies all parameters of the CRC algorithm. Generates the crcn instruction.
Definition of the bit-fields of 'a' can be found in the manual.
uint __shuffle( uint a, uint c )
Shuffle the order of the bytes of 'a' according to 'c' and return the result. The value 'c' contains four 2-byte fields which specify which bytes from 'a' are chosen to return. The value of each 2-bit byte select field specifies the index of the source byte from 'a'. Generates the shuffle instruction.
Definition of the bit-fields of 'c' can be found in the manual.
uint __popcntw( uint a )
Count the total number of ones in 'a' and return the result. Generates the popcnt.w instruction.
void * __lha( uint o )
Compute the 32-bit effective address (EA) of absolute address offset 'o' and return the EA. Generates the lha instruction when 'o' is an immediate value, otherwise generates a shift left 14 and move address instruction. (sh dx,dy,#14 mov.a ax,dx).

Note: uint means unsigned int, uchar means unsigned char.

Note: These intrisinsics are only supported when the compiler option --core=tc1.6.2 is used.

TriCore: New C compiler intrinsic __fesetround

A new compiler intrinsics has been added to support rounding mode: void __fesetround( int round )

The __fesetround function establishes the rounding direction represented by its argument 'round'. If the argument is not equal to the value of a rounding direction macro, the rounding direction is not changed. The rounding direction macros are FE_TONEAREST, FE_UPWARD, FE_DOWNWARD or FE_TOWARDZERO.

For TC13 or when TC13 compatibility mode (COMPAT) is enabled the rounding mode is restored on a ret instruction.

TriCore: Additional hardware debug support for AURIX derivatives

With this release, hardware debug support is added for the following AURIX hardware:

TriCore: Support EABI v3.0

In the new EABI v3.0 two extensions are defined. At the moment of writing this release note, this EABI version is in still in draft. However, on request of Infineon, these extensions are implemented already. In case they are removed from the official EABI, it will not harm your code by any means when used. It is advised not yet to use them until the EABI is officially released by Infineon. Contact Infineon in case you need additional information.

Extended alignment:

  1. The alignment attributes __align(n) and attribute((__align(n))), the pragma #pragma align n and option --align=n are now supported for functions too.
  2. The alignment attributes, pragma and option now support value 2 too. Alignment values supported are: 2, 4, 8, 16, 32, 64.

Error message change

With this extension the compiler error "E 408: symbol alignment cannot be decreased" is replaced by warning "W770: symbol "name" alignment cannot be decreased from x-bytes to y-bytes -- ignored".


For compatibility with the EABI v3.0 the warning W770 should be disabled with option --no-warnings=770. For compatibility with TriCore compilers prior to this release, the warning W770 should be treated as error with option --warnings-as-errors=770.

TriCore: Updated SFR Files

The following derivatives have updated SFR files:

TriCore: New LLVM C++11 libraries

In the previous version C++11 support was added to the C++ compiler. In this version we have added specific LLVM C++11 libraries (exception handling variants only).

Now the TASKING C++ compiler supports the STLport C++ libraries and the LLVM C++11 libraries. The STLport library supports standard templates and I/O streams as defined by the C++03 standard. The LLVM library supports standard templates, STL features and I/O streams as defined by the C++11 standard (built with C++ compiler option --c++11). The include files for the LLVM C++11 libraries are present in directory ctc\include.cxx relative to the product installation directory.

The naming convention we use for these libraries is libcxx[s]x[_fpu].a. The libraries are available for all supported TriCore architectures.

TriCore: New wide-character C libraries

The new LLVM C++11 libraries require wide character support. Therefore we have added wide character variants of the libc for all TriCore architectures. The libraries are automatically used by the linker when the the control program is invoked with option --io-streams=cpp11.

The naming convention for these libraries is libc[s]w[_fpu].a.

TriCore: Integrated TASKING Safety Checker Enhancements

With the introduction of the Stand-alone TASKING Safety Checker utility, the Integrity Check utility ichk (part of the product) has been renamed to Integrated TASKING Safety Checker. The filename stays the same, ichk. The following improvements and updates have been made.

Improved tracebility: additional I-message

When applicable, additional informational messages are emitted pointing to the source of a violation, like:

    ichk I896: ["safety.c" 7] the address of "z" is returned by function "f1" to function "f2"

See the TASKING VX-toolset for TriCore User Guide, paragraph 8.10.4 Output of the Integrated Safety Checker, for an example.

Improved tracebility: variable with local lifetime as parameter to a function

Passing (the address of) a variable with local lifetime as parameter to a function is now also traced.


    void g(int *ptr)
      *ptr = 1;    // Check for access violation

    void f(void)
      int my_local; // local lifetime

The safety class of the variable with local lifetime is assumed to be the same as the safety class of the containing function, in this case function f().

See the TASKING VX-toolset for TriCore User Guide, paragraph 8.10.2. Memory Access Checks, for more information.

New option --output-format, to control the output

With the new option --output-format you can control which parts of the output are generated. Sub-options are available to control output being generated for:

and new in the output

The new Access table lists for all global symbols by which function they are accessed and what kind of action takes place. For example:

    | Address  | Name | Acting function | Address  | Access |
    | 80000448 | f1   | f2              | 8000044e | --CA   |
    |          |      | f3              | 80000462 | --CA   |
    | 8000044e | f2   | f3              | 80000462 | --CA   |
    | 80000462 | f3   | main            | 8000047c | --CA   |
    | 90000000 | x    | f2              | 8000044e | RW-A   |
    |          |      | main            | 8000047c | ---A   |
    | 90000004 | y    | f2              | 8000044e | R---   |
    |          |      | f3              | 80000462 | ---A   |
    | 90000008 | z    | f1              | 80000448 | ---A   |
    |          |      | f2              | 8000044e | RW--   |

See TASKING VX-toolset for TriCore User Guide, paragraph 10.13 Integrated TASKING Safety Checker Options, for more information.

Access violation on memory address

Direct memory access, for example an SFR or via a constant value, is covered.

For example:

    #define SFR  0xaaaaaaaa
    #define BIOS 0xcaaaaaaa
    void case_1_5(void)
      *((int *) SFR) = 1;            // Checked
      ((void (*)(void)) BIOS)();     // Checked

See the TASKING VX-toolset for TriCore User Guide, paragraph 8.10.2. Memory Access Checks, for more examples.

Warning when unable to check safety violation

The Integrated Safety Checker now emits a warning for cases where the Integrated Safety Checker is unable to check safety violations due to code complexity or other restrictions.

For example:

    int    u;
    int  * v = &u;
    int ** w = &v;
    int ** f(void)
      return w;

Emitted diagnostics, on 'return w;':

    ichk W799: ["safety.c" 6] unable to check safety violation
    ichk I882: ["safety.c" 6] function "f" returns the address of an unknown entity
    ichk I881: ["safety.c" 6] access to an unknown entity by dereferencing "w"

See the TASKING VX-toolset for TriCore User Guide, paragraph 8.10.5. Integrated Safety Checker Remarks, for more information about restrictions.

TriCore: New ELF patch utility features

The ELF patch utility has been extended with the following new features/improvements:

ELF symbol renaming

With the new option --symbol-renaming-file you can specify an ELF symbol renaming command file that contains commands to specify a replacement for an existing ELF symbol name in an object file or library. The command syntax is:


Function renaming

In an ELF patch data reference modification (DRM) file you can specify a replacement for any access to a specified global variable or function.

Global scope replacement

Instead of a function name or global struct variable name, you can use a wildcard character (*) to specify global renaming scope.

TriCore: New script debugger example

A new script debugger example has been added, download_multiple. This example may help you to create scripts for running automated tests. The examples are: <installpath>\examples\dbgtc\download_multiple. The example shows how to download more than one file.

PCP: PCP debugging

Versions prior to this release used the debugger Mode menu to select between debugging on a TriCore core or on a PCP. The Mode menu has been removed. When you use the simulator, the Debug view shows the TriCore core and PCP as separate threads. When you select a thread this changes the context in the Disassembly view.

MCS: C Compiler extensions

The MCS C compiler is fully ISO-C99 compliant. Several language extensions have been built into the compiler to support the specific features of the MCS hardware architecture. Numerous code size and execution speed optimizations have been implemented since the previous release v3.1r1 in TriCore v6.0r1.

Intrinsic Functions

A set of intrinsic functions is provided to give access to those features of the MCS that cannot be addressed efficiently via ISO-C language features. The set covers ARU transfer operations, bus master addressing, and suspending wait instructions. The intrinsic functions and their protypes have changed between versions v3.1r1 and v6.1r1.

Refer to the User Guide for more information.

MCS Channel Concept

The compiler supports the channel concept of the MCS architecture. By assigning the __attribute__((channel( ))) to a function it becomes the entry point for the specified channel. ISO-C requires a main() function, by default main() is the entry point of channel 0, but main() can also be assigned to another channel.

Extended Register Set

The compiler can emit code for the default register set (called OREG) as well as for the extended register set (called XOREG). Code that uses the extended register set may execute faster.

Data Types

All C data types such as _Bool, char, short, int, long, long long, float, double and complex are supported.

A 32-bit data type __aei_t is available to improve the efficiency of data transfers over the bus master interface. Due to the 24-bit architecture of the MCS this data type should not be used for arithmetic operations.

Special Function Registers

The compiler provides access to special function registers STA, ACB, CTRG, STRG, TBU_TS0, TBU_TS1, TBU_TS2, GMI0, GMI1, DSTA, DSTAX. SFR functionality has been augmented in the v6.1r1 release.

Refer to MCSVX-182.

Inline Assembly

Assembly instructions can be used within the C source code, however the available set of intrinsic functions should make the use of inline assembly superfluous.

MISRA C:2012 Static Analysis

The compiler can check source code against the rules defined in the MISRA C:2012 standard. Individual rules can be enabled and disabled on the compiler's command line as well as in the Eclipse IDE.

CERT Static Analysis

The compiler can check code against the rules defined in the CERT C Programming Language Secure Coding standard.

MCS: EABI and Object File Compatibility between v3.1r1 and v6.1r1

The EABI has been modified, therefore object files created with version v3.1r1 (in TriCore v6.0r1) are not compatible with v6.1r1. 

Refer to MCSVX-648.

MCS: Interoperability with Third Party Toolsets

Interoperability with third party toolsets for programming the CPU has been realized by providing a "C array" output format.

The linker can emit the generated machine code in the form of C code. This is useful for the integration of MCS code in applications where the CPU is programmed with a non-TASKING compiler. Note that no symbolic debugging is possible unless you use the debug information from the ELF file.

The C array output format consists of a C source file with data encoded in a C array initializer combined with a C header file that contains necessary declarations and optionally provides access to the exported symbols of the program. You can use the C array format only for chip output files where, as with normal hex files, each memory gets its own output file that contains data for that memory only. The intended target for output files in C array format is a programmable peripheral where an application compiled for the peripheral is imported into a host application as C code. This "host application" must initialize the programmable peripheral's memory using the data in the C array(s).

Refer to MCSVX-545.

ARM/HSM: New LLVM C++11 libraries

In the previous version C++11 support was added to the C++ compiler. In this version we have added specific LLVM C++11 libraries (exception handling variants only).

Now the TASKING C++ compiler supports the STLport C++ libraries and the LLVM C++11 libraries. The STLport library supports standard templates and I/O streams as defined by the C++03 standard. The LLVM library supports standard templates, STL features and I/O streams as defined by the C++11 standard (built with C++ compiler option --c++11). The include files for the LLVM C++11 libraries are present in directory carm\include.cxx relative to the product installation directory.

The naming convention we use for these libraries is cxxthumb[s]x.lib.

Fixed issues for v6.1r1


New Feature


The list of open issues for v6.1r1 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.