This release note covers the release of version v6.3r1 of the TASKING VX-toolset for TriCore. In addition to new features it includes some other changes as well, such as bug fixes. These other changes are not described in this release note. They may lead to differences in behavior from v6.2r2.
For release notes prior to v6.3r1, please visit the TASKING TriCore support website.
Release v6.3r1 is a 64-bit product. It shall be installed on 64-bit versions of the Windows operating system. The release was tested on Windows 7 64-bit and on Windows 10 64-bit.
Release v6.3r1 no longer supports the integrated version of the TASKING Safety Checker (ichk utility). The improved TASKING Safety Checker is available as a separate product. It can be purchased and installed separately. It can be used to check any set of C source files, also files from v6.3r1 projects.
Release v6.3r1 no longer performs a license check when the Eclipse IDE is started. This means that the IDE can be used for non-tool related activities without claiming a license seat. For example to do a code review or to look at a linker map file. It also means that if there is no valid license this will no longer be reported at IDE start-up but only when a tool is started which requires a valid license.
This release supports C11 language and library features as defined by the ISO C standard. With the C compiler option --iso you select the ISO C standard. C90 (option value '90') is also referred to as the "ANSI C standard". C99 (option value '99') refers to the ISO/IEC 9899:1999 (E) standard. C11 (option value '11') refers to the ISO/IEC 9899:2011 (E) standard. C11 is the new default. All unconditional (mandatory) C11 features are supported. Of the conditional features which are introduced by C11 the Atomic feature is supported. Support can be checked by means of the conditional feature macros as defined by the C standard (section 6.10.8.3).
The TASKING TriCore C compiler now supports atomic types (by means of the _Atomic type qualifier) and the features defined by the
You can now use __uncached__ or __attribute__((uncached)) on variables to instruct the linker to allocate the corresponding variable in a non-cached memory segment. Extensions were made to the system LSL files to identify cached memory segments (new LSL keyword 'cached'). If a variable is declared with the 'uncached' attribute, its corresponding section name contains the substring ".uncached", for example .zbss.uncached.my_module.my_atomic_var. Atomic variables automatically imply the attribute 'uncached'.
This release fully supports C++14 language and library features as defined by the ISO C++ standard. With the C++ compiler option --c++ you select the ISO C++ standard. Option value '03' refers to ISO/IEC 14882:2003, '11' refers to ISO/IEC 14882:2011, '14' refers to ISO/IEC 14882:2014. Selecting C++11 or later also enables exceptions. The old --c++<**> options are deprecated. The new options will also automatically select the appropriate C++ libraries. C++14 is the default. Refer to the user manual for details.
The option --io-streams only affects compilation in C++03 mode and it is no longer necessary to provide a language version with it.
By default the C++ compiler now uses the built-in type wchar_t. It is no longer needed to specify option --wchar_t-keyword for this. The former default, using a type definition for wchar_t, can now be obtained by specitying the new option --no-wchar_t-keyword.
With the new linker option --long-branch-veneers the linker generates a so-called veneer (a.k.a. trampoline) if the target of a 24-bit PC-relative call instruction is out-of-range. The call instruction is replaced by an absolute call to the veneer. The veneer makes an indirect call to the original call target. Veneers will be located in the "abs24" address space. The locating process of the linker may become less efficient when this feature is used, even if no trampolines are required. Therefore it is better to first see if out-of-range calls are in the code (unlikely) before switching on this option. Out-of-range calls are reported by the linker by means of an error message.
To control the location of veneer code a new LSL syntax element is supported: veneer_layout. The specification of the address space to which a veneer_layout definition applies works in the same way as the specification of the address space for a section_layout definition.
A new run-time error checking sub-option +/-stack is added to the C compiler option --runtime. This option will instrument your application code with a stack overflow checking capability (on all cores). When stack overflow checking is enabled, the compiler adds code to the stack frame allocation in the function prolog to verify that the new stack pointer stays within the allocated stack space. When the stack overflows, a function __runtime_stack_overflow() in the C library is called to report the overflow and abort. You can overrule this function with your own version. A small margin is used to guarantee that at least 64 bytes of stack space are available for the overflow event handler.
With the new C compiler option --sfr-access-instruction you control whether certain instructions can be used by the compiler to access an SFR in segment 15. Note that intrinsic functions that are explicitly designed to generate a particular instruction will not be affected by this option.
When you use the s flag or +stt the compiler is allowed to generate the ST.T instruction on SFR addresses. By default, the compiler does not generate the ST.T instruction on SFR addresses. This is to avoid unexpected or undesired side effects or hardware exceptions when accessing specific peripheral registers. Other instructions are known to have such effects on certain peripherals, but these are currently not used by the compiler.
The option --global-type-checking (compiler plus linker) can not only be applied to check for errors caused by different definitions of user-defined types in different compilation modules, but also to check for type incompatibilities caused by the use of different compiler option settings used when compiling different modules. This also works when linking objects which were compiled with different versions of the compiler. Therefore global type checking can be used in the context of cross-linking and the mixing of options. In order to fully cover potential cross-linking problems resulting from the use of different compiler option settings, the global type checking feature has been extended with additional checks:
By default, the assembler generates a note section in the object file. The note section contains compiler version and invocation information, if supplied in the input file, and version and invocation information of the assembler. With the new assembler option --no-notes you can suppress the generation of a note section in the output object file.
The TASKING VX-toolset for TriCore supports creation of position independent modules. Such modules can be loaded at and executed from an arbitrary address, provided that the host application or run-time environment satisfies certain conditions. A position independent module consists of a code image, in which all internal function calls are by means of PC-relative call instructions; a ROM data image, which is accessed using a register-relative addressing mode; and a RAM data segment, which is accessed using a register-relative addressing mode. The current implementation supports base address registers from the set A0/A1/A8/A9. The values in those base registers are not saved and restored by the hardware nor by the compiler. The host application or run-time environment must make sure that the proper values are assigned to the base registers when code in the position independent module is running.
To build a position independent module, the option --pic must be added to the compile step and to the link step. In --pic mode, the compiler sets the default data memory qualifiers to __a8 for writable data and __a9 for read-only data. To access this data the compiler uses register-relative addressing modes with registers A8 and A9 as the base address registers. In --pic mode the compiler generates PIC specific code for switch tables and lookup tables, and for obtaining the address of a position independent function. The user can change the default registers by specifying any registers from the set A0/A1/A8/A9 with the option --pic.
In --pic mode, the linker restricts relocations for function and data objects in the application (i.e. for symbol references inside position independent code and data) to PC-relative and A0/A1/A8/A9-relative relocation types. Relocations for symbol references that do not point to position independent code or data are restricted to absolute relocation types. For successful position independent module completion some specific information must be passed to the linker by means of an LSL file. The system LSL file pic.lsl can be used for this (ltc option -d=pic.lsl). When the linker is invoked through the control program (cctc) the option --pic implies inclusion of pic.lsl by default.
The restrictions on data access mean that any C library function that uses a global variable such as errno cannot be included in a position independent module (unless such library code is re-compiled with --pic). C library functions that are available in host applications can be accessed, either directly on a fixed address or through a function pointer table.
The entry point (or one of the entry points) of the component is defined as the function _PIC_START by default. It can be changed by defining the linker (LSL) macro _ENTRY_SYMBOL to the name of a function. This entry point will be located at the lowest address of the code block. The sizes of the user-designated memory blocks for the position independent module can be set by defining the LSL macros _CODEROM_SIZE, _DATAROM_SIZE, and _DATARAM_SIZE. The linker will issue an error message if a code or data section does not fit in its corresponding memory block. The default values are defined in the pic.lsl system LSL file.
To compile two source modules a and b of a position independent module from the command line using the control program:
cctc -co --pic a.c
cctc -co --pic b.c
To subsequently link the modules from the command line and produce position independent IHEX image files:
cctc --pic -Wl-cmycomponent:IHEX a.o b.o -Wl-D_CODEROM_SIZE=60k -Wl-D_DATAROM_SIZE=8k -Wl-D_DATARAM_SIZE=16k
This will produce two image files which can be programmed into device memory, one for code and one for read-only data.
At run-time the value of the selected RAM data base address pointer (from the set A0/A1/A8/A9) must be defined as the start address of the RAM segment + 32k, so this address value will not necessarily be inside the PIC RAM segment memory image. Similarly, the value of the selected ROM data base address pointer (also from the set A0/A1/A8/A9) must be defined as the start address of the ROM segment + 32k. This is assuming that a data object got located by the linker at the lowest address of the data block as defined in the LSL file (which will be the case by default). If the user decides to locate data at specific offsets of the lowest address of the data block and as a result of this the lowest occupied address is not the lowest address of the data block, then this must be taken into account when calculating the run-time values for the A0/A1/A8/A9 pointers.
Position independent code is not guaranteed to be compatible with the TriCore EABI. This is specifically the case when the address of a function inside the position independent module is taken at run-time. TASKING specific relocation types are applied in order to generate the appropriate instruction sequence for this operation.
You can use the PIM Project Template Wizard in Eclipse to create a PIC/PID project. This PIC/PID project has preset tool options and contains a source file holding the _PIC_START() entry point. To start the wizard, select TASKING TriCore Position Independent Module from the menu: File -> New -> TASKING TriCore C/C++ Project.
Three TASKING Eclipse IDE example projects are provided to demonstrate the PIC/PID feature. To import these examples, select File -> Import ... from the menu. Select TASKING C/C++ followed by TASKING TriCore Example Projects. Click the 'Next' button. Select the projects tc_pic, tc_pic_app1 and tc_pic_app2 from the list by ticking the boxes and then click the 'Finish' button. The projects will now be visible in the C/C++ Projects navigation panel. Refer to the readme.txt files in the projects before continuing.
Packed structs are structs without alignment gaps or tail padding bytes. Although they violate the EABI, packed structs can be useful for reasons of accessing externally defined data objects or for reasons of working with source code originally developed for other targets and/or other compilers.
The TASKING Tricore C compiler now supports packed struct definition by means of the __packed__ or __attribute__((packed)) attribute and references by means of the __unaligned pointer qualifier. Accessing packed or unaligned data objects comes with a performance penalty in code speed and code size.
Struct member alignment can now be changed by the user by applying the existing __align() attribute, with the restriction that alignments can only be made larger than the minimum alignment required by the EABI. Adjusting the alignment of individual struct members can be useful for reasons of accessing externally defined data objects or for reasons of working with source code originally developed for other targets and/or other compilers.
The TriCore EABI states that a bit-field of size 0 should align to the next byte boundary: "A zero-width bit field, as specified by ANSI C, forces alignment to a storage unit boundary, which for TriCore is one byte." However, by default the compiler uses the alignment of the base type of the bit-field, which can be larger than one byte.
A new --eabi=B/-bitfield-align sub-option was added to the C and C++ compilers and the control program to force the alignment of a bit-field of size 0 to one byte, as defined by the EABI.
On some specific TriCore hardware the cycle count of a branch instruction is minimized when the hardware fetch unit can fetch from an 8-byte aligned target address. This can become relevant when a conditional branch inside a loop is almost always taken and the pipeline must be filled with instructions from the branch target address.
You can now inform the compiler about the likelihood of a branch (at the C source code level) being taken by means of a new brach prediction #pragma assume_if. You can then request the compiler to optimize branch target alignment by means of a new option --branch-target align if it encounters a branch prediction #pragma.
With the new TriCore C compiler option --no-rtlib-calls you can make sure that for operations for which the compiler has a choice between a run-time library call and localized ('in situ') code generation, the localized version is selected, regardless of the specified -t or -O option settings. This applies to the following six divide and modulo operations on 8/16/32-bit integers:
When the option --no-rtlib-calls is used, the compiler will issue a warning message for any run-time library functions which it needs to call and for which no localized code generation alternative exists. In that case you either have to accept the function call or rewrite your source code to avoid the operation (for example when applying a shift operation to a 64-bit integer or when using double precision floating point values).
Note that by default the compiler will use localized ('in situ') code generation for basic single precision floating point operations (assuming that the target device has a hardware FPU). There is no need to specify the option --no-rtlib-calls for this. Run-time calls for these operations are only inserted if you explicitly specify the option --fp-model=+soft.
Stack size estimation is computed by the linker and listed in the map file. For this purpose each root node of the call graph was treated as a potentially separate thread which can run independently from all other root node threads. For each stack the estimated stack usage was the sum of the stack usages of all such independent call graph root node threads. As a result, the stack size estimation by the linker was usually too high. This has now changed.
For each stack in the LSL file (and therefore for each core) the user can specify a list of entry points by means of the new 'entry_points' keyword. An entry point can be specified as a symbol name. By default, the system LSL files specify _START as the entry point symbol for stack usage calculation. So by default, interrupt handlers and trap handlers are not taken into account. You will have to add them to the list of entry points yourself. The 'entry_points' keyword can be combined with the 'threads' keyword as described in the next paragraph.
The map file will now show a stack usage estimate for each stack (on each core). It will also show which entry points have been used to do the calculation. The call graph will show the stack usage for all potential entry points and call graph root nodes. The call graph no longer shows a stack name with the stack usage. Whether or not a node is used in a stack size estimation is defined by the list of entry points in th LSL file and is shown in the stack usage table in the map file.
For MCS, the LSL macros GTM_MCS_STACK_<channel>, GTM_MCS_HEAP, and GTM_MCS_MAIN_CHANNEL have been replaced by macros for each MCS core: GTM_MCS<core>_STACK_<channel>, GTM_MCS<core>_HEAP, and GTM_MCS<core>_MAIN_CHANNEL.
If only a limited number of entry point threads can run on a specific stack simultaneously, the stack size estimation by the linker will be too high. You can now prevent this by specifying the 'threads' keyword on a stack definition in the LSL file and assigning a number to it. When threads is set to n, only the n highest stack usage numbers of all entry point threads for that stack are summed.
By default the TASKING linker applies LSL files which provide a holistic view of the target processor. For multi-core processors (TriCore 1.6.x 'AURIX' architecture abd TriCore 1.6.2 'AURIX 2G' architecture) this is accomplished by means of a so called virtual core ('vtc'). The linker makes sure that all code and data is located once (except when cloning to PSPR or DSPR is used) and can be accesed from all cores. Cores also share global data (A0/A1 pointers), copy table and interrupt vectors. The linker generates one overall project image file.
With this release there are also LSL files which can be used to build a separate intermediate project image file for each core. This way you can make sure that a core can only access its own code and data. But also that it does not share code with other cores. If a function is used by multiple cores, each core can have its own copy in its own core coupled PFLASH memory. This also applies to the library functions which are pulled in by the core's application code. Sharing a data object between cores is still possible by using special linker-generated symbol names.
If you want to build an application project that has program parts that only run on a specific core, you need to select that specific core in Eclipse (for example, TriCore core 0) for the core-specific project. If you build your project from the command line with the control program, you also have to specify control program option --lsl-core=tcN for core N. Your main project should always be a core 0 project that has project references to the core-specific projects. This is necessary in order to make sure that final project images do not overlap.
The old single core LSL files for core0 only, such as tc27x_tc0.lsl and tc39x_tc0.lsl are no longer included with the product. If your project was using these files you can either copy the old LSL file into your project or convert the project to the new LSL files and specify the option --lsl-core=tc0.
This release provides compiler support (device selection, LSL files, SFR header files, start-up code) for the following new AURIX device series: TC35x, TX36x and TC37x. A debug target configuration (DTC file) is provided for the new TC35x and TC37x starter kit hardware which can be obtained from Infineon: TC357 on a TC3x7 TriBoard and TC377 on a TC3x7 TriBoard.
If you are debugging a multi-core project, each TriCore core (called 'thread' in Eclipse) has its own Registers view and its own Disassembly view. To open a thread specific Registers view, select a thread in the Debug view and click the 'Open thread specific Registers View' button. To open a thread specific Disassembly view, select a stack frame in a thread in the Debug view and click the 'Open thread specific Disassembly View' button.
The Devices view shows which target boards are connected to your PC. Some target boards contain a power supply chip which needs to be initialized every time after power-on, before hardware debugging is started. This initialization is necessary before starting a debug session, otherwise communication is not possible. Target boards can be initialized manually or automatically.
The Add Global Variables dialog now provides the ability to search for variable names by using wild cards.
Data breakpoints are now also supported on hardware, by means of the MCDS driver from Infineon. Data breakpoints on simulator or hardware share the same GUI in the TASKING Eclipse IDE.
Note: Hardware data breakpoints are not triggered while single stepping through an application.
Note: An updated version of Infineon's mcdsdas.dll is required. Until this update is made publicly available by Infineon, this DLL will be made available to you by TASKING upon request.
Breakpoints on functions and data objects can now be set independently of the availability of source code in a project. File and symbol information will be obtained from the ELF object file. File information is only present if the ELF object file contains debug information. If there is no debug information available, symbol data is obtained from the symbol table.
The TASKING RTOS and the iLLD Software Platform, designated as Bonus Technology (see the EULA) in previous releases, are discontinued. The TASKING Pin Mapper for AURIX is still included with the product (a free stand-alone version also exists).
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.
TASKING products are protected with TASKING license management software.
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.
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.