TASKING TriCore VX-Toolset v2.0r3



This release note describes the changes and new features of all TASKING TriCore products since v2.0r2.

(The release notes of the previous TASKING TriCore VX-toolset v2.0r1 release can be found in the readme_2_0r1.html document)

(The release notes of the previous TASKING TriCore VX-toolset v2.0r2 release can be found in the readme_2_0r2.html document)

The following parts are described:

The main reasons for this release are:


As you may have noticed the letters VX are added to the name of this new TASKING TriCore toolset. VX is short for Viper eXperience, and it indicates that this toolset incorporates the new generation VIPER DSP-C compiler technology. This compiler has been developed in-house by Altium and offers true state-of-the-art code generation. Furthermore specific DSP optimizations have been added, so you will find an improved performance of the compiler in both generated code size and run-time speed.

The compiler offers full compliance with the latest ISO C 1999 standard, for instance the _Bool and long long data types are available and ready for use.

In our strive for being in accordance with the TriCore EABI (Embedded Application Binary Interface), we have introduced the ELF/DWARF 2 object format. This smoothes the integration with many third party products such as RTOS's, software libraries and debuggers. For this purpose the assembler and linker have been redesigned as well. The new linker comes with an enhanced Linker Script Language (LSL) that replaces the obsolete DEscriptive Language For Embedded Environments (DELFEE).

With the upgrade to the Viper technology it turned out to be not possible to maintain full backwards compatibility. However, we have included a migration tool to help you convert a project, originally set up for a previous TriCore toolset, to one that will build with this new toolset.


New Features

The handling of the startup code has been changed. In earlier releases of the TriCore toolset the startup code ("/lib/src/cstart.asm") was linked to the project. This had the big disadvantage that when the startup code was modified the changes affected all projects.

We have improved this by no longer linking the startup code, but copying the "/lib/src/cstart.asm" to the local project directory instead. The startup code can now be adjusted without affecting other projects.

Please notice, that EDE can generate a message box stating, while trying to add the new "cstart.asm", it was detected that a file with the same name is already part of the project. You can in this case select the recommended option "Replace the current file with the specified file in the project"

Support for a new TriCore derivative has been added to the product. Furthermore, when the output format IHEX/SREC is selected, a default overall IHEX/SREC file is generated now (instead of IHEX/SREC files for each chip). An extra option has been introduced to force the generation of IHEX/SREC files for each chip.


No new/changed features.


A1 Memory Allocation

In addition to the already existing -Z option for A0 allocation, the option -Y has been introduced for A1 allocation. With this option you can specify a threshold value for __a1 allocation. Instead of this option you can also use #pragma default_a1_size in the C source.


The memory qualifier __align has been introduced to allow adjusting of the alignment on individual symbols. Using this feature can lead to unexpected behavior and therefore usage of this feature should be limited to a minimum. You always have to obey the alignment rules for the types. For example placing a short on an odd address will cause incorrect code to be generated.


No new/changed features.


New Features

A new ".map" file sub option has been added in order to generate local module symbols within the ".map" file.

Output Sections and Filling Attribute

The linker now supports the new feature to create output sections. These output sections will be visible in the ".map" file, instead of the sections that are member of this output section. These output sections can also be filled with a pattern in order to allow checksums.


group my_group ( ordered, contiguous, run_addr = 0xA0000400 )
	section "my_group_part1" ( size=0x200, attributes=r, fill=0x0 )
		select ".text.part1.*";
	section "my_group_part2" ( size=0x400, attributes=r, fill=0x0 )
		select ".text.part2.*";

This example part of the Linker Script Language will place the group "my_group" on the absolute address 0xA0000400. This group contains two output sections, respectively "my_group_part1" and "my_group_part2".

The linker will place all sections starting with ".text.part1." within the output section "my_group_part1". The output section "my_group_part1" will be visible in the ".map" file and will have a fixed size of 0x200.

The output section "my_group_part2" will contain all section starting with ".text.part2." and will be visible in the ".map" file with a fixed size of 0x400.

Only the sections that meet the requirements set by the select statement, will be located within these output sections, other sections are not allowed to be located in these output sections, e.g. through default locating or absolute addressing.

For your information, the example above allows you to use the following labels (the usual section labels of the input sections, are also still available):



Wide char support has been disabled by default within the libraries. If you want the libraries with wide char support you will have to rebuild the libraries using the option -DWCHAR_SUPPORT_ENABLED.


Support for a new TriCore derivative has been added to the debugger.

Copyright 2004 Altium BV