This release note covers the changes between v4.1r2 and v4.2r2 of the TASKING VX-toolset for TriCore.
For release notes prior to v4.2r2, please visit the TASKING TriCore support website.
It is no longer required to select a specific communication method
for the connection you are using. It is only required to select UDAS
(Universal Debug Access Server). For all boards the Debug Target
Configuration (.dtc
file) has been changed. If you are using older Eclipse projects in
which
you have selected another communication method, you will get a DAS
launch
configuration problem. To correct this you need to select UDAS and
retry your debug session.
AURIX devices have (typically four) Boot Mode Headers
(BMHs), which lie in
flash memory. An individual BMH can be either valid or invalid. If all
BMHs are
invalid, the device is normally inaccessible to the debugger. This more
or less
"bricks" the device, because reprogramming the flash to re-validate one
of the
BMHs requires the debugger, or a similar program using the now
inaccessible debug port.
Recovery is possible via e.g. CAN, but this is cumbersome.
Therefore, the debugger has special functionality to prevent all BMHs from being invalidated. The debugger only allows downloading if the target application adheres to one of the following restrictions:
Remarks:
It has been detected that the TCP/IP example may fail to import in Eclipse. This is due to some environment issues within Eclipse when starting the extractor. You can unpack the example successfully by double-clicking the executable install-tcpip-example.exe in the directory <install-path>\ctc\examples\tcpip. Afterwards you can import the example without problems.
The TASKING VX-toolset for TriCore C compiler fully supports the ISO-C standard, but some parts of the ISO-C standard are implementation-defined. Chapter 20 "C Implementation-defined Behavior" of the TriCore user guide describes how the implementation-defined areas and the locale-specific areas of the C language are implemented in the TASKING C compiler.
The internal constants can be divided into six groups. The section names generated for these kinds of data were not consistent. These have now been corrected as follows:
| Internal Constant | New section name | Changed | Old section name |
| Initializers | *.<n>.ini.* | N | *.<n>.ini.* |
| String literals | *.<n>.str.* | N | *.<n>.str.* |
| Compound literals | *.<n>.lit.* | N | *.<n>.lit.* |
| Constants | *.<n>.cnt.* | Y |
*.__const_* |
| Switch lookup tables | *.<n>.lkp.* | Y |
*.switch_lookup* |
| Switch jump tables | *.<n>.jmp.* | Y |
*.switch_jump* |
All section names of the internal constants (.ini, .str, .lit, .cnt, .lkp and .jmp sections) follow the same section naming convention as used for code and data:
.<type>[.<DCA>][.<module_name>][.<symbol_name>][.<s>]
In which:
<DCA> is the value of
the #pragma
data_core_association (or option –-data-core-association)
<symbol_name> is one of .<n>.ini /
.<n>.str / .<n>.lit / .<n>.cnt / .<n>.lkp /
.<n>.jmp
<s>
is the renaming suffix
By default, the C compiler does not overlay internal data sections
that do not have the same type, core association and suffix.
This update may have a negative effect on ROM usage, but it complies to ASIL and ISO 26262 which require that it must be possible that code and data can be grouped together. The MPU would generate a trap in case such data would be accessed from outside the ASIL group. This update makes it possible to select all ASIL sections together, because overlaying is restricted and the section names are fixed.
Refer to the new compiler option --relax-overlay-name-check.
Until this release Code Compaction was performed whenever possible. With Multi-Core (AURIX) Code Compaction was only performed when the sections would have the same core association. With this release Code Compaction is made more restrict. Code Compaction is now also taking section renaming into account, which may lead to less code compaction optimization. However this update will comply to ASIL and ISO 26262 requirements to locate sections together which are really belonging together. Code fragments will then no longer be called from other code that is not part of the ASIL section group.
Refer to the new compiler option --relax-compact-name-check.
This section gives an overview of the most important new features and improvements in v4.2r1. See the sections with fixed issues for a complete list.
With this release the toolsets for 8051 and ARM are integrated into the TriCore toolset. These are required for the AURIX derivatives. The AURIX derivatives TC27x and TC29x support the HSM module (ARM). The TC26x supports the XC800 module (8051).
Like MCS the 8051 objects (or linked .out file) are being linked and located with the TriCore objects into one absolute file. During startup of CPU0 of the chip the 8051 code is being copied into its own memory. This is done via the bus system that links the TriCore to the XC800 module.
The ARM executable is created separately from the TriCore and requires its own flashing method.
With the integration of the TASKING VX-toolset for 8051 and TASKING VX-toolset for ARM in the TriCore distribution package all the user guides have been moved into the directory <install-path>\ctc\doc.
This applies to the TC26x derivative only.
The 8051 objects need to be linked into the ELF file of the TriCore,
the 8051 code
and romdata will be allocated in TriCore flash memory. A start and
end label is available for the TriCore application. The 8051
requires its own startup code and copy table. The start address in
XC800
XRAM is always 0. Any gap between the 8051
sections will be filled with zeros.
Linking into the TriCore ELF file is done with the option --new-task,
like it is done with MCS code.
The files linked can be an OUT file (linked only) or any object
including the required 8051
libraries. The --core
option needs to be specified too. In the TC26x LSL
file the 8051 core is specified as xc800. Therefore, the option must be
--core=mpe:xc800.
A separate 8051 ELF file will be generated for debugging
purposes.Within Eclipse this file is generated in the 8051 project
Debug directory.
Flashing of the 8051 is done by CPU0 during startup. It copies the XC800 image from the TriCore flash to the XC800 XRAM through the QSPI.
To debug a 8051 project make sure you have built the TriCore project
that references the 8051 project. Make the 8051 project the active
project and start the debug session.
The 8051
application is a stand-alone application with its own copy table. The
XC800 XRAM
memory needs to be initialized from TriCore code through QSPI. The
TriCore linker ltc facilitates this. For this the new LSL memcopy
statement can be used in a section_layout.
It takes a quoted string followed by a comma-separated list of
arguments between parentheses and a semicolon. The argument list must
contain exactly one memory reference in the form:
"memory" "=" <memory_reference>
and may contain one fill definition:
"fill" "=" <fill_spec>
The result of this statement is a new section in the address space of the section_layout, with the quoted string as name. The size of the section is the minimum number of MAUs needed to hold the contents of the memory. In absolute output objects or HEX files, the section contains all data located in the given memory, with appropriate MAU size conversion applied if needed. Unused memory positions are filled in the generated section with the given fill pattern or zero if none was supplied. The generated section can be located as any other section by adding it to a LSL group.
Example as used in tc26x.lsl:
section_layout :vtc:linear
{
memcopy "xc800init" (memory = scr_xram, fill=0);
}
Restrictions
The 8-byte configuration reduces the vector table size. Each vector entry contains only a jump instruction or a call and return as 16-bit opcode instruction. The TriCore compiler supports this kind of interrupt vector table generation by keywords or functions.
Function qualifier __interrupt8() has been added to support 8-byte vectors for core TC1.6.x only. A jump instruction is generated to the interrupt function defined. An absolute jump instruction is generated to the interrupt service routine, which restricts the address range to absolute 24. Loading a 32-bit address and jumping indirectly does not fit in an 8-byte vector.
Fast interrupts are directly placed in the vector table entry. It is not likely that fast interrupts fit in an 8-byte vector, but fast interrupts may span more than one vector table entry when successive entries are free. Fast interrupts do not need a code generation change for 8-byte vectors, because they are directly placed at the vector address. A function qualifier __interrupt8_fast() has been added to support locating fast interrupts at 8-byte spacing.
A section naming convention is used for vector table allocation. This naming convention has been extended for 8-byte vector table spacing. The section name syntax is: .text.inttab<nr>.intvec8.<offset>. These sections are only generated with the qualifiers __interrupt8() and __interrupt8_fast().
8-byte and 32-byte spacing is available at the same time, no LSL configuration is required. However mixing 8-byte and 32-byte spacing on the same core is not possible, but different cores can use different spacings. You have to define the required spacing at compile time.
The vector spacing is configured at startup per core in BIV with startup macro __BIV_8BYTE_INIT. You are responsible that this is conform the spacing required by the interrupt functions, because it is not possible to check if usage of interrupt functions qualifiers corresponds with the BIV configuration.
The previous version of TriCore, version v4.1r2, was based on Eclipse Indigo (SR1). The TriCore v4.2r1 release contains Eclipse Juno (service release 1) plugins: Eclipse version 3.8.1 and CDT version 8.1.1. Within the Eclipsedevelopment community there is a parallel development ongoing, so there is a version 3.8 and 4.2 available. We have chosen for 3.8 since, according to the development community discussions, Eclipse 3.8 is more stable and performs better.
A new compiler option is available to make data overlaying relaxed: --relax-overlay-name-check. This option relaxes the overlaying of romdata for internal constants, string literals and compound literals. Romdata for internals are overlaid when equal. By default, the compiler only performs overlaying on equal romdata for internals that have the same memory space, core association and section rename suffix. With this option the compiler does not perform this overlay name check, but performs overlaying whenever possible. This equals the 'old behavior'.
A new compiler option is available to make code compaction relaxed: --relax-compact-name-check.
With code compaction (reverse inlining), chunks of code that can occur
more than once in different functions, are transformed into another
function. By default, the compiler only performs code compaction on
sections that have the same section type prefix, core association and
name given by the section renaming pragma or option. Chunks of code
that are part of functions with a different core association or section
rename suffix are not taken into account. With this option the compiler
does not perform this section name check, but performs code compaction
whenever possible. This is the 'old behavior'.
Until now it was only possible to specify in an object file (protect attribute on section declaration in assembly) or with option -OXY to prohibit removal of all code/data sections.
Now an LSL extension is available that allows exclusion of sections from unreferenced section removal in the linker too. This extension supports wildcard section matching. This can be done by adding the attribute +p (or -p) of the modify input feature in a section_setup, which sets or clears the protect attribute on the selected sections. When this attribute is set on a section, the section is not removed/merged in unreferenced section removal or duplicate section removal.
For example, we have sections s1, s2 ... s12. To prohibit (unreferenced) sections s10, s11 and s12 from getting removed we need to set the protect attribute as follows:
section_setup ::linear
{
modify input (attributes=+p)
{
select "s1?";
}
}
With the integration of the 8051 toolset in TriCore, the option --mcs-tasks has been deprecated. This option could only be used for linking MCS code with TriCore code. The generic option --new-task is introduced as substitute. The name of this option is the same as the linker uses and thus makes it more clear where it is used for. This new option can be used for linking both MCS and 8051 objects with TriCore. Contrary to --mcs-task, --new-task is meant for one core only, where --mcs-tasks was used for all MCS cores at once.
New SFR files are integrated for TC26x (tc26x_um_SFR_v1.0) and TC27xB (UM_V1.3)
With this release linking of multi-core applications (AURIX derivatives) is done via global addresses by default. For example, the CPU0 core of a TC27x accesses its own local memory (code and data) via segment 0x7 instead of 0xC and 0xD.
There is no difference for a core (in terms of run-time speed) when accessing its own local memory via local or global addresses. For clone sections the local addresses are still used.
This change also has a positive effect on debugging and MAP file readability. For debugging the breakpoints can be set per core on the global address, and thus each core can be debugged correctly.
The call graph in the map file has been extended with:
1) stack usage per function and stack usage of the complete tree
below each function
2) indication of functions that are called recursively
This information is present in the text version as well as in the XML version of the map file.
To be able to use the AURIX derivatives in a single-core mode extra LSL files have been added to the distribution. It is only possible to use the first TriCore (CPU0) as a single core. The memories which are defined for the other cores are therefore free to use, as in the previous cores like TC1798. In the AURIX LSL files the first core is called TC0. The new dedicated LSL files support AURIX derivatives which only support the first core. These LSL files are called: <derivative>_tc0.lsl. The tc<core_number> suffix is used, because this is conform the core names used in LSL (tc0, tc1, ...)
When starting the linker with a multi-core CPU and using all cores, the core required is: --core=mpe:vtc
When starting the linker with a multi-core CPU in single-core mode, it is required to call the linker with the TC0 core: --core=mpe:tc0
By default the control program was using mpe:vtc when invoking the linker when linking for an AURIX derivative. With the option of running an AURIX derivative in single-core mode, it is required to be able to specify on the linker command line the core mpe:tc0.
The control program must be aware of the mode the AURIX derivative is going to be used in. Therefore, a new option has been added to the control program by which the core for the current task can be specified:
--lsl-core=<name> Select core name, as specified in LSL
file, for current task (default: vtc)
tc0 core 0
vtc multi-core
The LSL core names which are valid are mentioned in the file processors.xml per derivative.
The list of open issues for v4.2r2 can be found on the internet.
The list of open issues for v4.2r1 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.
This release does not support the regular 15-day trial mode.
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 PC's 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 receive a license key - specific for the bundle - to unlock the appropriate tools.