TASKING VX-toolset for TriCore v4.1r1
Release Note


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


Important Notices

License manager update, FLEXlm License Manager v8.4ra3 (JIRA 160-38984)

When using floating licenses it may occur that a license is returned to the license manager, but tthe FLEXlm deamon 'forgets' to update the database. Meaning that a license is still in use, even after the lingertime. When running many compilers and linkers this may result over time in a rejection of a license request, even while ther should be enough free licenses. This is a bug in the FLEXlm software.

We have added a workaround for this. We have added the utility tsk_licmaint.exe which checks the used licenses against a unused time period. This tool may be run manually or can be installed as server on Windows or a cron job at Linux. The utility can be found in the the same directory as the deamon Tasking.exe. It should run from this location too.

To use the utility you need to install the FLEXlm License Manager v8.4ra3.

DAS v4.0.5 installation

When installing Infineon's DAS it may occur that the installtion is taking a very long time. This is a known issue at Infineon. The reason for this is not known. Also it has been detected that installation on Windows 7 SP1 is DAS installer will pop-up and finally the installation will not be completed. This can be checked that de-installing via Windows "Add/Remove Programs" is not possible.

Upgrade to Java Runtime Environment 7 update 9

This release comes with the new JRE 7 update 9.

Deprecated options --cpu and --tasking-sfr (JIRA 160-38504)

The --cpu option was used in compiler to define the macros __CPU_TC<xxxx>__ and __CPU__. The --tasking-sfr was using the cpu defined to include automatically the sfr file for the cpu specified. The --cpu and --tasking-sfr options have been deprecated in the compilers and assemblers.

Instead of --cpu=tc<xxxx> use:  -D__CPU_TC<xxxx>__  -D__CPU__=tc<xxxx>
Instead of --tasking-sfr use for the compilers:  -Hsfr/regtc<xxxx>.sfr
                                       and for the assemblers:  -Hsfr/regtc<xxxx>.def

The control programs still accept the --cpu and --tasking-sfr and will now use the above defines when calling the compiler and assembler.

TriCore EABI violation fix (JIRA 160-38894)

TriCore EABI Chapter Structure Return Values requires that:

EABI: "The caller must provide for a buffer of sufficient size. The buffer is typically allocated on the stack to provide re-entrancy and to avoid any race conditions where a static buffer may be overwritten. If a function result is the right-hand side of a structure assignment, the address passed may be that of the left-hand side, provided that it is not a global object that the called function might access through an alias. The called function does not buffer its writes to the return structure. (i.e. it does not write to a local temporary and perform a copy to the return structure just prior to returning)."

Tasking TriCore compiler did not meet later requirement

Example source code demonstrating the issue

struct s3int_t
   int a;
   int b;
   int c;

extern struct s3int_t s3_ret( void );
       struct s3int_t s3_glob;

void f3( void )
   s3_glob = s3_ret();

Assembler code generated by TASKING v4.0:

f3: .type func
    movh.a a4,#@his(s3_glob)
    lea    a4,[a4]@los(s3_glob)
    j      s3_ret

There is no local copy for s3_glob.

Note: the issue does not cause problem if only TASKING generated code is used, because TASKING code creates a local copy in the called function. But it does cause problem if TASKING code is linked with code generated by another compiler (which does comply to EABI, expect the caller to do the copy, and does not create local copy in called function)

New TriCore compiler option --eabi=<flags> (JIRA 160-38876)

Prior to version v4.0r1 it was possible to use -F with --eabi-compliant. Although these options are conflicting, it was perfectly working. With v4.0r1, these options are rejected when used together by the control program and compiler. 

However there is a benefit when using one or more non EABI compliancy features. But also the other way around. 

A new option is introduced: 

    --eabi=<flag>,... control EABI compliancy (default: dfhns)
                                     lowercase/+ enables, uppercase/- disables:
       d/D +/-dwarf allow an alternative DWARF version
       f/F +/-float allow treat 'double' as 'float'
       h/H +/-half-word-align allow half-word alignment
       n/N +/-no-clear allow the use of option --no-clear
       s/S +/-structure-return allow structure-return optimization

     --eabi-compliant alias for --eabi=DFHNS 

For backwards compatibility, when --eabi-complaint was used before, you should now use --eabi=DFHNs
Please refer to JIRA 160-38894 which has been fixed with this release too.

For --no-clear please refer to JIRA 160-36838 (disable clearing of non-initailized global data).

New in v4.1r1

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

HSM C compiler support

A dedicated C compiler for the HSM unit of the AURIX is available to license holders of the Professional and Premium Edition of the VX-toolset for TriCore. Initially this compiler is available through an add-on installation to the v4.1r1 release, but at a later stage the compiler will be included in the binary distribution of the TriCore package.

If you are a license holder of the Professional Edition or the Premium Edition and the C compiler for the HSM is not included in your product delivery, you can request a copy of the compiler by sending a request to iwantacompiler@tasking.com

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 enduser with Infineon. Once Infineon gives Altium permission to release the SFR installer, we will make it available through a secure FTP location.

New TriCore compiler option --no-clear

With the new option --no-clear it is possible to disable the automatic clearing of non-initialized global dat. Currently, this can only be achieved by using pragma clear/noclear in the source module.

Link Time Core Association (JIRA 160-38867)

For multi-core support a section can be made private, clone or share. The linker uses memory spaces to allocate these sections at the appropriate location. Currently the linker does this automatically, depending on the section names. The section names are generated by the compiler, depending on the usage of the qualifiers __share, __private0, __private1, __private2 or __clone.

To allow making a multi-core application without specifying the core association at compile time the linker script language (LSL) is extended with the "modify space" statement to modify the memory space of a section. With the "modify space" statement sections that have no core association can be associated with a core by placing them in the space for a core.

The "modify space" statements must be used within the section_setup:

section_setup current_space
  modify space = new_space
    select "section_name";
    select "section_name"

The section_name can contain wild-cards. The new_space can consist of multiple spaces in case a section must be cloned on multiple cores.

Example 1) Move function foo() from module 'foo' to core 0:

section_setup mpe:vtc:linear
  modify space = mpe:tc0:linear
    select ".text.foo.foo";

The linker will create a copy of the code in flash as well and it will be initialized at startup.

Example 2) Move near data sections (.zdata / .zbss) of module 'foo' to core 0:

section_setup mpe:vtc:abs18
  modify space = mpe:tc0:abs18
    select ".zdata.foo.*";
    select ".zbss.foo.*";

Example 3) To make variable 'myglobal' a clone for each core:

section_setup mpe:vtc:linear
  modify space = mpe:vtc:mpe_tc0_linear|mpe_tc1_linear|mpe_tc2_linear
    select ".data.module.myglobal";

When a variable in core local memory ('private' variable) is accessed from a section in another core's local memory an error message will be given. The user can then decide whether it is safe to make the variable shared between both cores and update the linker script file accordingly.

Example blink_aurix:

The example blink_aurix in the distrubtion can be configured to use this new mechanism. You need to set the macro __LTCA__ to enable this new feature in the example.

Automatic Base Register Assignment (JIRA 160-38834, 160-38995)

At compile time the user can choose any base register relative addressing mode A0, A1, A8 or A9. The user specifies with the group statements in the linker script file in which of the 4 for groups the section must be located. 

When the --auto-base-register option is supplied to the linker, it will automatically use the base address register that is in range of the addressed section.


An example of the grouping for A8 and A9 in the linker script file. The sections in A8 for the main application code are placed in the A8 group, while the sections from the library are placed in the A9 group.

group a8 (ordered, contiguous)
    select ".data_a8.main_application.*";
    select ".bss_a8.main_application.*";
    select ".rodata_a8.main_application.*";
"_A8_DATA_" := sizeof(group:a8) > 0 ? addressof(group:a8) + 0x8000 : 0;

group a9 (ordered, contiguous)
    select ".data_a8.library.*";
    select ".bss_a8.library.*";
    select ".rodata_a8.library.*";
"_A9_DATA_" := sizeof(group:a9) > 0 ? addressof(group:a9) + 0x8000 : 0;

If needed sections in object files or object libraries can be renamed at compile time or by using the elfpatch tool.

Default Linker Scripts (JIRA 160-38995)

The default linker scripts in the product group the sections that belong to A0, A1, A8 and A9 each in their own group. This grouping will now be placed in a separate LSL file, "base_address_groups.lsl", to make it easier for the user to overrule the grouping. This LSL file will be included in the product's LSL files where currently the address groups are defined. For modifying the group definitions the file base_address_groups.lsl shall be copied to the user's project (with a different name) and can the be modified to place the sections in the groups where desired. Using the macro __REDFINE_BASE_ADDRESS_GROUPS in the project LSL file will make sure the default base address groups are overruled. 

Example in project LSL file:

#include "tc27x.lsl" // as example

    section_layout :vtc:linear // :vtc:linear only needed for AURIX
#include "./my_base_address_groups.lsl"

Linker Option --auto-base-register (JIRA 160-38834)

When a base register addressed section comes out of range for its base register as assigned in the object file, the linker will by default issue an error message. When the --auto-base-register option is supplied the linker will automatically try to find a different base address register that is in range. The search order is A0, A1, A8, A9. If the section is not in range of any of the base address registers, the linker will still issue an error message. This behavior makes it possible to place a section in a different base addressable group than assigned at compile time. For example a .data_a8 section can be grouped with the group for the A9 base address register.

Extension in elfpatch to rename section based on symbol (JIRA 160-38929)

The elfpatch utility has the possiblity to change a section name in a ELF file (.o and .a). This is done via the command rename_section( "<sectionname OLD>", "<sectionname New>" ). However when more than one symbol reside a section with the same name, then all those sections will be renamed and thus all symbols will reside in a new section. This is not always required. Therefore the extension has been implemented to select a section for renaming based on the symbol. This will make sure that only the section in which the symbol is found gets renamed. Other sections with the same name stay untouched.

The command for this is: rename_section_by_symbol( "<symbolname>", "<sectionname New>" )

AURIX TC275 Debugger Board support (JIRA 160-38889)

With this release the AURIX TriBoard TC275 is supported. The TC27X files are required for this and are available in the distribution.

AURIX TC26X Debug simulator support

With this release there is debug simulator support for the AURIX derivative TC26X. The TC26X is a cpu with 2 TriCore cores and 3 MCS cores. Besides these cores there is also an 8-bit core, the XC800, on board. For the XC800 it is required to use the 8051 toolset available from TASKING.

Note: When a __private2 function/variable is defined or interrupt function in core 2 is defined, then this is not detected by the compiler or assembler. The linker may detect an error, or even throw away unreferenced sections, i.e. when it regards an interrupt function at core 2. Therefore when programming for TC26X you should be aware that there is no compiler checking on valid __private2 and __vector_table(2) usage. This might get solved in a later release.

The blink_aurix example is not yet supporting the TC26X, just because of the fact that the example can only be run on true hardware and this is not yet available.

AURIX TC29X Debug simulator support

With this release there is debug simulator support for the AURIX derivative TC29X. The TC29X has 6 MCS cores.

The blink_aurix example is not yet supporting the TC29X, just because of the fact that the example can only be run on true hardware and this is not yet available.

AUDO MAX TC1793 Debugger Board support

With this release the AUDO MAX TriBoard TC1793 is supported.

AUDO MAX TC1724 Debugger Board support

With this release the AUDO MAX TriBoard TC1724 is supported.

Multi-Core scope violation error (JIRA 160-38533)

For AURIX multicore it is required to disallow references from sections in certain address spaces to sections in certain other address spaces. This can now be configured in LSL using a prohibit_references_to statement in a section_setup. Matching references will cause the linker to emit an error message.


For an AURIX context, the following fragment disallows references from private0 sections to private1 and private2 sections; from private1 sections to private0 and private2 sections; and from private2 sections to private0 and private1 sections.

section_setup :tc0:linear
    prohibit_references_to :tc1:linear, :tc1:abs18, :tc2:linear, :tc2:abs18;

section_setup :tc1:linear
    prohibit_references_to :tc0:linear, :tc0:abs18, :tc2:linear, :tc2:abs18;

section_setup :tc2:linear
    prohibit_references_to :tc1:linear, :tc1:abs18, :tc0:linear, :tc0:abs18;

Improving build time, new compiler option --cache (JIRA 160-38966)

To improve build time a new feature has been added to the compiler, caching.

The feature is enabled by using the new option --cache[=<dir>]. This option enables a cache for output files in the specified directory. When the source code after pre-processing, relevant command line options, and the compiler version are the same as in a previous invocation, the previous result is copied to the output file. The cache only works when there is a single C input file and a single output file (no --mil-split).

By default the TriCore cache will be placed in a directory called ctccache, the PCP cache in pcpcache.

New tool expiretc and expirepcp to inspect/invalidate Tricore and PCP compiler cache

The new 'expire' tool can be used to limit the size of the cache by removing all files older than a few days or to remove older files until the total size of the cache until it is smaller than a specified size.

Usage: expiretc [options] cache_directory
Summary of important options:
   -a --access             use access instead of modification time
   -d --days=<n>           remove files older than <n> days
   -m --megabytes=<m>      reduce size of cache to <m> MBytes
   -n --dryrun             don't actually remove files
   -t --totals             show cache size (default without -d/-m)
   -v --verbose            verbose operation

Accessing MCS symbols (JIRA 160-38836)

To be able to access a symbol in MCS memory the __mcsram keyword could be used in the TriCore source. The TriCore compiler would prefix the variable with __lc_s (like for PCP data):

      int  __mcsram  aVaria;   // in assembly: __lc_s_aVaria

Since each MCS core is separated from other memory symbols are allowed to have the same name. It was then not possible to access the symbol on a dedicated MCS core. The linker would always take the first one it would find during resolving.

Therefore the functionality of __mcsram has been changed. The compiler will now prefix the varaibel with __lc_t. This will instruct the linker to go one step further before resolving. Namely, in C-code it is known from which MCS the variable must be accessed. Therfore the C-variable needs to be prefixed with the required MCS core name:

      int  __mcsram  mcs02_aVaria;   //  in assembly: __lc_t_mcs02_aVaria

The linker will after removing the __lc_t also remove the mcs<nn>_. By this midfix (mcs<nn>) it is aware of the MCS core in which the symbol should reside and will try to resolve it in this core's symbol table.

For the MCS assembly there is no change required.

AURIX code and romdata located in own flash (JIRA 160-38845)

AURIX derivatives (for example) have cores with separate data and code buses. Local memory is connected directly to each of those buses, but the memory map (what memory is accessible at which address) is the same for both, using a generic bus to connect the data and code bus to other memories. Access speed, however, is not equal. In such cases it is often required to locate data sections in the local data memory and code sections in the local code memory. To facilitate this, the new exec_priority attribute is introduced for LSL mappings and memories. This means code and data sections are now located according to separate priority values. The existing priority attribute sets both data and code priority, unless an exec_priority is also set in which case the priority attribute determines the data priority and the exec_priority determines the code priority. An exec_priority attribute never sets data priority. Priority values are handled for each rule, except for unrestricted rules where each section is located according to the appropriate priority value.

For example the DSPR and PSPR memory definition for core 0 in TC27X:

memory dspr0 // Data Scratch Pad Ram
   mau = 8;
   size = 112k;
   type = ram;
   map (dest=bus:tc0:fpi_bus, dest_offset=0xd0000000, size=112k, priority=8, exec_priority=0);
   map (dest=bus:sri, dest_offset=0x70000000, size=112k);

memory pspr0 // Program Scratch Pad Ram
   mau = 8;
   size = 24k;
   type = ram;
   map (dest=bus:tc0:fpi_bus, dest_offset=0xc0000000, size=24k, priority=4, exec_priority=8);
   map (dest=bus:sri, dest_offset=0x70100000, size=24k);

AURIX TriCore stacks per default in core's local DSPR (JIRA 160-38877)

LMU has some disadvantages when using stack in LMU:

With this release the LSL for the AURIX derivatives have been changed to locate the stack in the core's DSPR by default. Issue

The section_setup of each stack is now done in the core's linear space, e.g. stack for core 0:

section_setup :tc0:linear
   stack "ustack_tc0"
      min_size = (USTACK_TC0),
      align = 8

   stack "istack_tc0"
      min_size = (ISTACK_TC0),
      align = 8

Equivalent for cores 1 and 2. This has been made the default for all AURIX derivatives (see their dedicated LSL file). 

Single entry vector table for tc1.6.x (JIRA 160-38982)

The vector table can be reduced to a single entry by masking the PIPN. If the BIV masks the PIPN so that any interrupt address calculation results in the same address. 

__mtcr(BIV,(unsigned int)(interrupt handler) | 1 | 0xFF<<3);

This configures the BIV register to use a common, single entry where a function interrupt handler is located to branch to the specific interrupt routine by using an array of function pointers. If a pointer to the array is used the array could be switched quickly.

Refer to the example blink_aurix demonstrating the single entry vector table: Single Entry Vector Table (SEVT) can be enabled by defining the __SEVT__ macro. The BIV requires SEVT initialization at startup, enable the startup macro's __BIV_SINGLE_INIT, __BIV_SINGLE_TC0_INIT and __BIV_SINGLE_TC0_INIT in the startup include files.

In the c-library new files for support are added: sevt.c and sevt.h.

New PCP compiler option --atomic-divide-multiply (JIRA 160-38672)

The PCP compiler lacks generation of uninterruptable code for DSTEP, MSTEP and MSTEP64. To enable such code a new option is introduced: --atomic-divide-multiply atomic divide and multiply

With this option enabled atomic divide and multiply operations are generated. This option only has effect when the channel is interruptible. This is when option --interrupt-enable is specified. Special care must be taken when using multiply and divide sequences when a channel program is interruptible. In this case the compiler makes sure that a sequence cannot be corrupted by the execution of multiply or divide instructions executed by a higher priority channel. The compiler uses bit R7.IEN to ensure that a sequence is not interruptible.

Duplicate libraries librtd, libfp[t]d are obsolete (JIRA 160-38934)

With the introduction of multi-core support the linker supports the --new-task option, originally used for MCS linkage. This option can also be used to create a RAM copy, making teh duplicate libraries obsolete. Therefore these libraries are no longer distributed. The --new-task option extends the duplicate libraries, it will make the complete tree from entrypoint exist in RAM. 

New register file

For the TC27X A-step new .sfr and .def files are included..

Eclipse Board Configuration Selection part of New Project Wizard

When creating a new project after selecting a processor, the project was created and a debugger simulator configuration was created. With this release you must select the board configuration too. Then the project is created and a debugger board configuration is created. When a debugger simulator configuration is required then you should create this separately.

Fixed issues for v4.1r1


New Feature


The list of open issues for v4.1r1 can be found on the internet.

Quick start

For a quick start, just start the TASKING VX-toolset for TriCore 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 and/or the MCS project examples.

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

License Information

15-day Trial

This release does not support the regular 15-day trial mode.

How to obtain a license key

All TASKING products include the industry standard FLEXlm license management software. In order to be able to run this toolset, you will need a license key. You can only obtain a license key if you have purchased this product.

To obtain a license key, you can start the License Administrator from the program group of your installed TASKING toolset. In case you still need to install the toolset, you can start the License Administrator by setting a check mark at the end of the setup/installation process. The wizard of the License Administrator will guide you through the steps to obtain your license key.

Once you have received your license key from Altium, you can install it on your system by running the License Administrator again. Alternatively you can simply save the license key as the file 'license.dat' in the C:\FLEXLM folder on your PCs hard disk.

More information is available on http://www.tasking.com/support/flexlm. On this page you also find assistance to setup a floating network license, or for installation on Linux or Sun systems.


Altium's TASKING VX-toolset for TriCore is available as Standard, Professional and Premium Edition. At installation time all tools are installed, no matter what bundle you purchased or want to evaluate. However, each tool is protected with its own unique key. After your purchase you will release a license key - specific for the bundle - to unlock the appropriate tools.