This release note covers the changes between v5.0r2 and v6.0r1 of the TASKING VX-toolset for TriCore.
For release notes prior to v6.0r1, 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.
The v6.0r1 has been tested with the latest DAS version 4.6.0 of Infineon. No problems have been found. It is recommended to use DAS 4.6.0 with TriCore v6.0r1. Download here.
Refer to AURIX PLUS support and TCVX-40319.
In normal conditions you will need a TriCore application which
initializes the MCS memories (via the copy-table). However you have the
possibility to create an elf-file for MCS without TriCore though. This
gives no problems with the AURIX derivatives (tc1.6.x). When tryin
gthis for the new architecture AURIX PLUS (tc1.6.2) you will encounter
a linker problem.
There are no AURIX PLUS derivatives yet available, hence only the processors "userdef162" has been made available for preliminary projects. When you try to build an MCS project for AURIX PLUS using
processor "userdef162" you will get the linker error "lmcs F019:
unrecoverable error: caught unknown exception". This is caused by the
'copy' attribute in the vector-table entries. The attribute is
essential, because otherwise the tables are not initialized via the
copy-table. You could create your own variant of the userdef162.lsl and
the included gtm lsl file. Then remove the copy attribute defined at
the begin of the gtm lsl file. However, since an MCS without TriCore does not really make sense it is advised to wait for the next release in which this inconvenience will be resolved.
This section gives an overview of the most important new features and improvements in v6.0r1. See the sections with fixed issues for a complete list.
This new toolset release includes the first version of the AURIX Configuration Tools (ACT), provided to you in collaboration with Infineon Technologies. ACT consists of three main components:
While the Pin Mapper and the RTOS are qualified and fully released components, the iLLD Configurator is provided as the third public beta, based on iLLD files from Infineon that do have the beta status. While using ACT, you may occasionally check if there are any updates available through the update option in Eclipse.
ACT is provided as complimentary Bonus Technology and supported to a
limited level.
Nowadays many microcontrollers are equipped with a large number of on-chip peripheral modules.These microcontrollers are made available in surface mount packages with various numbers of physical pins. The number of pins usually does not allow all peripheral modules to be used simultaneously. Hardware registers on the microcontroller allow for configurable assignment of peripheral module signals to physical pins. This means that you have to select the proper device for your application and properly initialize hardware registers from software. The purpose of the TASKING Pin Mapper is to assist you in performing those tasks.
The TASKING Pin Mapper is integrated in
the AURIX Configuration tools. For more information
about using the TASKING Pin Mapper, see the "Pin Mapper user guide".
Most applications consist of tasks with both hard and soft real-time constraints. If these tasks are single purposed, you could implement them as semi-independent program segments. Still you would need to embed the processor allocation logic inside the application tasks. Implementations of this kind typically take the form of a control loop that continually checks for tasks to execute. Such techniques suffer from numerous problems and do not represent a solution for regular real-time applications. Besides, they complicate the maintenance and reusability of the software.
A Real Time Operating System (RTOS) is a dedicated operating system fully designed to overcome the time constraints of a real-time system. An RTOS, like any other operating system, provides an environment in which you can execute programs in a convenient and structured manner, but without the risk of failingthe real-time constraints.
The TASKING RTOS is integrated in the
AURIX Configuration tools. For more information
about using the TASKING RTOS, see the "TASKING RTOS user guide".
With TASKING Software Platform you can quickly configure drivers which can be used in your applications. A Software Platform is made up of iLLD Drivers from Infineon. The exact contents of a Software Platform depend on the need of your application. The Software Platform Builder is used to manage your Software Platform. It is both a graphical editor and a code generator. Collections of software modules are delivered as Software Platform repositories.The driver configuration also incorporates initialization code generated by the TASKING Pin Mapper.
The TASKING Software Platform is integrated in the AURIX Configuration tools. For more information about using the TASKING Software Platform, see the "Software Platform user guide".
The MCS toolset has been updated to support the GTM 3 which is available in the AURIX PLUS architecture. In this toolset the new and first MCS compiler is integrated.
Contact Altium for a license upgrade if you want to use the GTM/MCS compiler.
Refer to TCVX-40688.
With this release support is added for the new AURIX PLUS architecture TC1.6.2. Although there are no derivatives yet available it is already possible to design you applications 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 16MB (distributed between the TriCore cores) and DFlash to 1MB.
Refer to TCVX-40319.
The new architecture AURIX PLUS comes with an extension to the
instruction set.
| Instruction |
Description |
Compiler |
Assembler |
| CRC32B.W |
CRC32 for big
endian data |
Planned.
Via intrinsic. |
Yes |
| CRC32L.W |
CRC32 for little
endian data |
Planned. Via intrinsic. | Yes |
| CRC32.B |
CRC32 for byte data |
Planned. Via intrinsic. | Yes |
| CRCN |
Arbitrary width and polynomial CRC calculation | Planned. Via intrinsic. | Yes |
| SHUFFLE |
Reorder bytes within word | Planned. Via intrinsic. | Yes |
| POPCNT |
Count number of bits set in word | Planned. Via intrinsic. | Yes |
| FTOHP |
Floating point
(32bit) to half precision floating point (16bit) conversion |
Yes |
Yes |
| HPTOF |
Half precision floating point (16bit) to floating point (32bit) conversion | Yes |
Yes |
| LHA |
Load high bits of address value | No |
Partial |
The LHA instruction is partially implemented. Only an immediate can be used in the instruction. For the next release it is planned to support relocations too.
To support the new AURIX PLUS architecture it is required to upgrade to the latest simulator from Infineon, TSIM v1.16.62. Therefore this version is included in this release.
Also the PCP simulator has been upgraded to, TSIM v1.38. This version is also included in this release.
When running the simulator for AURIX PLUS it is required to specify the option -tc162p. This needs to be done via the new 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 creating a new project for the AURIX PLUS architecture.
With this release, updates have been made to fulfill the new EABI
v2.9.
Refer to EABI v2.9 chapter 4.5.
The DWARF version is no longer restricted
to 2.0. In the EABI compliant mode (--eabi-compliant)
the DWARF version
was forced to 2.0. With this release this is no longer valid. The EABI
DWARF version is the default, being 3.0. Nevertheless it is still
possible to use --dwarf-version=2
to force dwarf 2.0 to be generated.
However, this option has been deprecated and will be removed in a
future major/minor release.
Refer to EABI v2.9 chapter 2.2.1.4 and
4.2.3.
The section names for variables declared
with __a0
and __a1
have changed. As well as the fact that __a1 can be
declared without const.
| Register |
Example |
Before
EABI v2.9 (old) |
Since
EABI v2.9 (new) |
| A0 |
int
const __a0 var; |
.sbss |
.bss_a0 |
| A0 |
int
const __a0 var = 1; |
.sdata |
.rodata_a0
, rom |
| A0 |
int
__a0 var; |
.sbss |
.bss_a0 |
| A0 |
int
__a0 var = 1; |
.sdata |
.data_a0 |
| A1 |
int
const __a1 var; |
.ldata |
.bss_a1 |
| A1 |
int
const __a1 var
=1; |
.ldata
, rom |
.rodata_a1
, rom |
| A1 |
int
__a1 var; |
error |
.bss_a1 |
| A1 |
int
__a1 var = 1; |
error |
.data_a1 |
You should take care of extending your
LSL like:
group
{
select ".sbss.*"
select ".bss_a0.*"
}
group
{
select ".sdata.*"
seelct ".data_a0.*"
}
group
{
select ".ldata.*"
select ".rodata_a1.*"
}
Please note that mixing A0 rodata and A1
rodata may not be possible or may lead to undefined behavior.
The _Float16
type is defined in "ISO/IEC
TS 18661-3 Draft Technical Specification – December 4, 2014 WG14 N1896"
Refer to EABI v2.9 chapter 2.1.2.
Refer to TCVX-40522.
The new architecture AURIX PLUS supports an instruction to convert a 32-bit float into a 16-bit float, and one to convert it from 16-bit to 32-bit. The TriCore compiler now supports the _Float16 type ( as defined by the ISO draft specifications ). Although the EABI mentions data type __float, this may be changed when the specification is final. When required you can use "#define __float _Float16" (or via compiler command line option -D__float=_Float16) to comply to the current EABI version.
Note: The _Float16 type is only a storage type, meant to save memory space. When doing calculations a _Float16 variable will first be converted to a normal float and afterwards converted back.
In the floating point library 4 new files have been added for the run-time conversion between 16-bit and 32-bit floats:
For these sources the header libfloat.h has been added to the include directory.
In this release a new utility is being integrated, the Integrity Check utility (ichk). With this utility you can check the integrity of an application. This utility checks access restrictions on memory in light of ASIL specifications and MPU configuration.
Based on an ISO 26262 ASIL level it is required to partition code and data into different safety groups. This is especially required within multi-core automotive applications. Different safety groups have different verification and validation criteria. Subsequently, safety groups have to be isolated from each other: bugs in low-safety-level code should not effect high-safety-level data, and high-safety-level code should not depend on low-safety-level code. So, low-safety-level code is not allowed to write in high-safety-level data sections, and high-safety-level code is not allowed to call low-safety-level functions.
The integrity check utility analyzes an ELF file for possible violations of these safety restrictions. It tries to rule out possible traps by the MPU at run-time. As this is based on local static analysis, not all possible violations can be found, and false positives may occur.
The partitioning of the application is done in LSL definitions.You can define different named safety groups by selecting either sections by name or by address ranges. The linker reads and interprets the LSL file and adds an extra section to the ELF file with all memory areas and their corresponding safety level and a list of all restrictions between different safety levels.
The compiler adds extra ELF sections with verification information about a) which variable is accessed by which function and how it is accessed and b) data flow information.
The integrity check utility reads the verification sections added by
the compiler and the linker and analyzes the application for possible
violations of these safety restrictions.
Contact Altium for a license upgrade if you want to use the Integrity Check utility.
In the Eclipse IDE this utility can be enabled via the checkbox "Check software partitioning (ISO 26262-6:7.4.11)" on the Properties->C/C++ Compiler->Diagnostics tab. Refer to the TriCore user guide, chapter "8.10 Integrity Check utility".
Refer to TCVX-40687.
With this option the compiler adds information about symbol accesses to the output file in special verification sections. This information can be used by the integrity check utility.
With this option the linker adds information about section access rights to the output file in special verification sections. This information can be used by the integrity check utility.
The access rights have to be specified in
LSL using the new safety class extension description. Refer to the
TriCore user guide chapter "8.10.3 Define safety class areas and access
rights".
With this option the compiler adds control flow information to the output file. The compiler generates a .debug_control_flow section which describes the basic blocks and their relations. This information can be used for code coverage analysis on optimized code.
This release holds an updated version 4.4.1 with CDT 8.5.0 of the Eclipse IDE named Luna. For features, improvements and bug fixes please refer to the Eclipse community web-site.
The following derivatives have updated SFR files:
SFR support has been added for the AURIX derivative TC27x D-step.
Refer to TCVX-40140.
The derivatives TC11iB and TC2D5T are discontinued by Infineon and have therefore become obsolete. Hence the support for these derivatives has been removed. All dedicated TC11iB and TC2D5T files, like libraries, have been removed too.
Only the tc1130 has optional MMU support.
Therefore only for tc1130 there are special MMU libraries:
ctc/lib/p/tc1130_mmu
and ctc/lib/tc1130_mmu.
These are the original
tc13_mmu libraries.
All other MMU libraries have been removed from the distribution.
| Option | Comment
/ tool messages |
| --dwarf-version=<n> |
By default in EABI
compliant mode, the DWARF
version is 3.0. The option can still be used, but in a future
major/minor release the option will be removed. ctc: W768: --dwarf-version has been deprecated, DWARF 3.0 is default astc: W720: Dwarfversion < 3 is deprecated |
| Data
type |
Comment
/ compiler message |
| __bit | The __bit data
type (used by the deprecated __atbit() qualifier) is
being deprecated since it is the same as _Bool. Hence the _Bool data
type should be used instead. W769: for object "<xxx>", __bit has been deprecated, use _Bool instead |
| Option |
Comment |
| --cpu=tc<xxxx> | the control
program still recognizes this option and translates this to "-D__CPU_TC<xxxx>__
-D__CPU__=tc<xxxx>" for the tools |
| --tasking-sfr | the control
program still recognizes this option and translates this to "-Hsfr/regtc<type>.sfr"
for the compiler and "-Hsfr/regtc<type>.def"
for the assembler |
| --no-tasking-sfr | - |
| --no-default-section-alignment | use --code-section-alignment and --data-section-alignment |
| --section-per-data-object | - |
| --runtime-prefix=<text> | use linker --new-task |
| --symbol-prefix=<text> | use linker --new-task |
| --fpu-present | - |
| Qualifier |
Comment |
| __atbit() | use classic method of C masking and shifting, intrinsic functions __extru and __imaskldmst or bitfields. |
With the advent of C++11 the exported templates feature has been
dropped.
In the C++ compiler automatic template instantiation was enabled by default. This causes the C++ compiler to generate an extra file with the .ti file name suffix. However, for compatibility with existing code and older compilers the C++ front end does not require this in some modes.
So this .ti file can be prevented from being generated by turning
off automatic template instantiation.
This also means that the command-line options that go along with
this disabled feature have become useless too. Hence these are removed.
When being used, the C++ Compiler will throw an error.
| Option |
| --definiton-list-file |
| --export |
| --exported-template-file |
| --no-auto-instantiation |
| --no-export |
| --suppress-instantiation-flags |
| --template-directory |
| --template-info-file |
Refer to TCVX-40257.
1) In an application there is always only one entry-point. This is
masked with _START.
However in a multi-core application the _START is
only working for CORE0. The other cores have no marker. To be able to
dump the call-graph for another core a new option is introduced by
which the start-address or function can be specified:
--call-graph-root=<function>
When using this option the --copy-table
option has to be specified too.
Refer to TCVX-40289 and TCVX-40366.
2) With the introduction of the Integrity Check
utility the High Level dumper has been extended with the -Fa
sub option. This option will dump the safety groups, access rights and
the verification section contents of an application (when build with --software-partitioning-info
option).
With this release the script debugger is now also supporting multi-core debug. An example can be found in the distribution which demonstrates this feature: ctc\examples\dbgtc\multicore.
Refer to TCVX-40534.
Two examples have been added to the release which show the usage of the script debugger. These may help you to create scripts for running automated tests. The examples are: ctc\examples\dbgtc\multicore and ctc\examples\dbgtc\execution.
Refer to TCVX-40534
and TCVX-40435.
The list of open issues for v6.0r1 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.