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.
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 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.
TriCore EABI v2.9 Chapter 2.1.4.3 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
New compiler intrinsics have been added to support the AURIX 2G architecture better. These intrinsics are:
| Intrinsic Function |
Description |
| 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.
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.
With this release, hardware debug support is added for the following AURIX hardware:
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:
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".
Compatibility
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.
The following derivatives have updated SFR files:
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.
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.
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.
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.
Passing (the address of) a variable with local lifetime as parameter to a function is now also traced.
Example:
void g(int *ptr)
{
*ptr = 1; // Check for access violation
}
void f(void)
{
int my_local; // local lifetime
g(&my_local);
}
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.
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.
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.
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.
The ELF patch utility has been extended with the following new features/improvements:
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:
<old_symbol_name>=<new_symbol_name>.
In an ELF patch data reference modification (DRM) file you can specify a replacement for any access to a specified global variable or function.
Instead of a function name or global struct variable name, you can use a wildcard character (*) to specify global renaming scope.
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.
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.
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.
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.
The compiler supports the channel concept
of the MCS architecture. By assigning the __attribute__((channel(
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.
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.
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.
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.
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.
The compiler can check code against the rules defined in the CERT C Programming Language Secure Coding standard.
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.
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.
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.
The list of open issues for v6.1r1 can be found on the internet.
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.