This release note covers the changes between v4.0r2 and v4.1r1 of the TASKING VX-toolset for TriCore.
When using floating licenses it may occur that a license is returned to the license manager, but tthe FLEXlm deamon 'forgets' to update the database. Meaning that a license is still in use, even after the lingertime. When running many compilers and linkers this may result over time in a rejection of a license request, even while ther should be enough free licenses. This is a bug in the FLEXlm software.
We have added a workaround for this. We have added the utility tsk_licmaint.exe which checks the used licenses against a unused time period. This tool may be run manually or can be installed as server on Windows or a cron job at Linux. The utility can be found in the the same directory as the deamon Tasking.exe. It should run from this location too.
To use the utility you need to install the FLEXlm License Manager v8.4ra3.
When installing Infineon's DAS it may occur that the installtion is taking a very long time. This is a known issue at Infineon. The reason for this is not known. Also it has been detected that installation on Windows 7 SP1 is DAS installer will pop-up and finally the installation will not be completed. This can be checked that de-installing via Windows "Add/Remove Programs" is not possible.
This release comes with the new JRE 7 update 9.
The --cpu option was used in compiler to define the macros __CPU_TC<xxxx>__ and __CPU__. The --tasking-sfr was using the cpu defined to include automatically the sfr file for the cpu specified. The --cpu and --tasking-sfr options have been deprecated in the compilers and assemblers.
Instead of
--cpu=tc<xxxx>
use:
-D__CPU_TC<xxxx>__
-D__CPU__=tc<xxxx>
Instead of
--tasking-sfr
use for the compilers: -Hsfr/regtc<xxxx>.sfr
and for the assemblers: -Hsfr/regtc<xxxx>.def
The control programs still accept the --cpu and --tasking-sfr and will now use the above defines when calling the compiler and assembler.
TriCore EABI Chapter 2.2.5.3 Structure Return Values requires that:
EABI: "The caller must provide for a buffer of sufficient size. The buffer is typically allocated on the stack to provide re-entrancy and to avoid any race conditions where a static buffer may be overwritten. If a function result is the right-hand side of a structure assignment, the address passed may be that of the left-hand side, provided that it is not a global object that the called function might access through an alias. The called function does not buffer its writes to the return structure. (i.e. it does not write to a local temporary and perform a copy to the return structure just prior to returning)."
Tasking TriCore compiler did not meet later requirement
Example source code demonstrating the issue
struct
s3int_t
{
int a;
int b;
int c;
};
extern struct s3int_t s3_ret( void );
struct s3int_t s3_glob;
void f3( void )
{
s3_glob = s3_ret();
}
Assembler code generated by TASKING v4.0:
f3: .type func
movh.a
a4,#@his(s3_glob)
lea
a4,[a4]@los(s3_glob)
j
s3_ret
There is no local copy for s3_glob.
Note: the issue does not cause problem if only TASKING generated code is used, because TASKING code creates a local copy in the called function. But it does cause problem if TASKING code is linked with code generated by another compiler (which does comply to EABI, expect the caller to do the copy, and does not create local copy in called function)
Prior to version v4.0r1 it was possible to use -F with --eabi-compliant. Although these options are conflicting, it was perfectly working. With v4.0r1, these options are rejected when used together by the control program and compiler.
However there is a benefit when using one or more non EABI compliancy features. But also the other way around.
A new option is introduced:
--eabi=<flag>,...
control EABI compliancy (default: dfhns)
lowercase/+
enables, uppercase/- disables:
d/D
+/-dwarf allow an alternative DWARF version
f/F +/-float
allow treat 'double' as 'float'
h/H
+/-half-word-align allow half-word alignment
n/N
+/-no-clear allow the use of option --no-clear
s/S
+/-structure-return allow structure-return optimization
--eabi-compliant
alias for --eabi=DFHNS
For backwards compatibility, when --eabi-complaint
was used before, you should now use --eabi=DFHNs
Please refer to JIRA 160-38894 which has been fixed with this release
too.
For --no-clear please refer to JIRA 160-36838 (disable clearing of non-initailized global data).
This section gives an overview of the most important new features and improvements in v4.1r1. See the sections with fixed issues for a complete list.
A dedicated C compiler for the HSM unit of the AURIX is available to license holders of the Professional and Premium Edition of the VX-toolset for TriCore. Initially this compiler is available through an add-on installation to the v4.1r1 release, but at a later stage the compiler will be included in the binary distribution of the TriCore package.
If you are a license holder of the Professional Edition or the Premium Edition and the C compiler for the HSM is not included in your product delivery, you can request a copy of the compiler by sending a request to iwantacompiler@tasking.com.
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 enduser with Infineon. Once Infineon gives Altium permission to release the SFR installer, we will make it available through a secure FTP location.
With the new option --no-clear it is possible to disable the automatic clearing of non-initialized global dat. Currently, this can only be achieved by using pragma clear/noclear in the source module.
For multi-core support a section can be made private, clone
or share. The linker uses memory spaces to allocate these sections at
the appropriate
location. Currently the linker does this automatically, depending on
the
section names. The section names are generated by the compiler,
depending
on the usage of the qualifiers __share, __private0, __private1,
__private2
or
__clone.
To allow making a multi-core application without specifying the core
association at compile time the linker script language (LSL) is
extended
with the "modify
space" statement to modify the memory space of a
section. With the "modify
space" statement sections that have no core
association can
be associated with a core by placing them in the space for a core.
The "modify space" statements must be used within the section_setup:
section_setup
current_space
{
modify
space = new_space
{
select "section_name";
select
"section_name"
:
:
}
}
The section_name
can contain wild-cards. The new_space
can
consist of multiple spaces in case a section must be cloned on multiple
cores.
Example 1) Move
function foo()
from module 'foo'
to core 0:
section_setup
mpe:vtc:linear
{
modify space = mpe:tc0:linear
{
select ".text.foo.foo";
}
}
The linker will create a copy of the code in flash as well
and it will be initialized at startup.
Example 2)
Move near data sections
(.zdata
/
.zbss)
of module 'foo'
to core 0:
section_setup
mpe:vtc:abs18
{
modify space = mpe:tc0:abs18
{
select ".zdata.foo.*";
select ".zbss.foo.*";
}
}
Example 3) To make variable 'myglobal' a clone for each core:
section_setup mpe:vtc:linear
{
modify space =
mpe:vtc:mpe_tc0_linear|mpe_tc1_linear|mpe_tc2_linear
{
select ".data.module.myglobal";
}
}
When a variable in core local memory ('private' variable) is accessed from a section in another core's local memory an error message will be given. The user can then decide whether it is safe to make the variable shared between both cores and update the linker script file accordingly.
Example blink_aurix:
The example blink_aurix in the distrubtion can be configured to use this new mechanism. You need to set the macro __LTCA__ to enable this new feature in the example.
At compile time the user can choose any base register relative addressing mode A0, A1, A8 or A9. The user specifies with the group statements in the linker script file in which of the 4 for groups the section must be located.
When the --auto-base-register option is supplied to the linker, it will automatically use the base address register that is in range of the addressed section.
Example
An example of the grouping for A8 and A9 in the linker script file. The sections in A8 for the main application code are placed in the A8 group, while the sections from the library are placed in the A9 group.
group
a8 (ordered, contiguous)
{
select ".data_a8.main_application.*";
select ".bss_a8.main_application.*";
select ".rodata_a8.main_application.*";
}
"_A8_DATA_" := sizeof(group:a8) > 0 ? addressof(group:a8) +
0x8000 : 0;
group a9 (ordered, contiguous)
{
select ".data_a8.library.*";
select ".bss_a8.library.*";
select ".rodata_a8.library.*";
}
"_A9_DATA_" := sizeof(group:a9) > 0 ? addressof(group:a9) +
0x8000 : 0;
If
needed sections in object files or object
libraries can
be renamed at compile time or by using the elfpatch tool.
Default Linker Scripts (JIRA 160-38995)
The default linker scripts in the product group the sections that belong to A0, A1, A8 and A9 each in their own group. This grouping will now be placed in a separate LSL file, "base_address_groups.lsl", to make it easier for the user to overrule the grouping. This LSL file will be included in the product's LSL files where currently the address groups are defined. For modifying the group definitions the file base_address_groups.lsl shall be copied to the user's project (with a different name) and can the be modified to place the sections in the groups where desired. Using the macro __REDFINE_BASE_ADDRESS_GROUPS in the project LSL file will make sure the default base address groups are overruled.
Example in project LSL file:
#define __REDEFINE_BASE_ADDRESS_GROUPS
#include "tc27x.lsl" // as example
#ifdef __REDEFINE_BASE_ADDRESS_GROUPS
section_layout :vtc:linear //
:vtc:linear only needed for AURIX
{
#include "./my_base_address_groups.lsl"
}
#endif // __REDEFINE_BASE_ADDRESS_GROUPS
Linker Option --auto-base-register
(JIRA 160-38834)
When a base register addressed section comes out of range for its base register as assigned in the object file, the linker will by default issue an error message. When the --auto-base-register option is supplied the linker will automatically try to find a different base address register that is in range. The search order is A0, A1, A8, A9. If the section is not in range of any of the base address registers, the linker will still issue an error message. This behavior makes it possible to place a section in a different base addressable group than assigned at compile time. For example a .data_a8 section can be grouped with the group for the A9 base address register.
The elfpatch utility has the possiblity to change a section name in a ELF file (.o and .a). This is done via the command rename_section( "<sectionname OLD>", "<sectionname New>" ). However when more than one symbol reside a section with the same name, then all those sections will be renamed and thus all symbols will reside in a new section. This is not always required. Therefore the extension has been implemented to select a section for renaming based on the symbol. This will make sure that only the section in which the symbol is found gets renamed. Other sections with the same name stay untouched.
The command for this is: rename_section_by_symbol( "<symbolname>", "<sectionname New>" )
With this release the AURIX TriBoard TC275 is supported. The TC27X files are required for this and are available in the distribution.
With this release there is debug simulator support for the AURIX derivative TC26X. The TC26X is a cpu with 2 TriCore cores and 3 MCS cores. Besides these cores there is also an 8-bit core, the XC800, on board. For the XC800 it is required to use the 8051 toolset available from TASKING.
Note: When a __private2 function/variable is defined or interrupt function in core 2 is defined, then this is not detected by the compiler or assembler. The linker may detect an error, or even throw away unreferenced sections, i.e. when it regards an interrupt function at core 2. Therefore when programming for TC26X you should be aware that there is no compiler checking on valid __private2 and __vector_table(2) usage. This might get solved in a later release.
The blink_aurix example is not yet supporting the TC26X, just because of the fact that the example can only be run on true hardware and this is not yet available.
With this release there is debug simulator support for the AURIX derivative TC29X. The TC29X has 6 MCS cores.
The blink_aurix example is not yet supporting the TC29X, just because of the fact that the example can only be run on true hardware and this is not yet available.
With this release the AUDO MAX TriBoard TC1793 is supported.
With this release the AUDO MAX TriBoard TC1724 is supported.
For AURIX multicore it is required to disallow references from
sections in certain address spaces to sections in certain other address
spaces. This can now be configured in LSL using a prohibit_references_to
statement in a section_setup.
Matching references will cause the linker to emit an error message.
Example
For an AURIX context, the following fragment disallows references from private0 sections to private1 and private2 sections; from private1 sections to private0 and private2 sections; and from private2 sections to private0 and private1 sections.
section_setup :tc0:linear
{
prohibit_references_to :tc1:linear,
:tc1:abs18, :tc2:linear, :tc2:abs18;
}
section_setup :tc1:linear
{
prohibit_references_to :tc0:linear,
:tc0:abs18, :tc2:linear, :tc2:abs18;
}
section_setup :tc2:linear
{
prohibit_references_to :tc1:linear,
:tc1:abs18, :tc0:linear, :tc0:abs18;
}
To improve build time a new feature has been added to the compiler, caching.
The feature is enabled by using the new option --cache[=<dir>]. This option enables a cache for output files in the specified directory. When the source code after pre-processing, relevant command line options, and the compiler version are the same as in a previous invocation, the previous result is copied to the output file. The cache only works when there is a single C input file and a single output file (no --mil-split).
By default the TriCore cache will be placed in a directory called ctccache, the PCP cache in pcpcache.
The
new 'expire' tool can be used to limit the size of the cache by
removing all files older than a few days or to remove older files until
the total size of the cache until it is smaller than a specified size.
Usage: expiretc [options] cache_directory
Summary of important options:
-a
--access use
access instead of modification time
-d
--days=<n>
remove files older than <n> days
-m
--megabytes=<m>
reduce size of cache to <m> MBytes
-n
--dryrun don't
actually remove files
-t
--totals
show cache size (default without -d/-m)
-v
--verbose verbose
operation
To be able to access a symbol in MCS memory the __mcsram keyword could be used in the TriCore source. The TriCore compiler would prefix the variable with __lc_s (like for PCP data):
int __mcsram aVaria; // in assembly: __lc_s_aVaria
Since each MCS core is separated from other memory symbols are allowed to have the same name. It was then not possible to access the symbol on a dedicated MCS core. The linker would always take the first one it would find during resolving.
Therefore the functionality of __mcsram has been changed. The compiler will now prefix the varaibel with __lc_t. This will instruct the linker to go one step further before resolving. Namely, in C-code it is known from which MCS the variable must be accessed. Therfore the C-variable needs to be prefixed with the required MCS core name:
int __mcsram mcs02_aVaria; // in assembly: __lc_t_mcs02_aVaria
The linker will after removing the __lc_t also remove the mcs<nn>_. By this midfix (mcs<nn>) it is aware of the MCS core in which the symbol should reside and will try to resolve it in this core's symbol table.
For the MCS assembly there is no change required.
AURIX derivatives (for example) have cores with separate data and code buses. Local memory is connected directly to each of those buses, but the memory map (what memory is accessible at which address) is the same for both, using a generic bus to connect the data and code bus to other memories. Access speed, however, is not equal. In such cases it is often required to locate data sections in the local data memory and code sections in the local code memory. To facilitate this, the new exec_priority attribute is introduced for LSL mappings and memories. This means code and data sections are now located according to separate priority values. The existing priority attribute sets both data and code priority, unless an exec_priority is also set in which case the priority attribute determines the data priority and the exec_priority determines the code priority. An exec_priority attribute never sets data priority. Priority values are handled for each rule, except for unrestricted rules where each section is located according to the appropriate priority value.
For example the DSPR and PSPR memory definition for core 0 in TC27X:
memory dspr0 // Data Scratch Pad Ram
{
mau = 8;
size = 112k;
type = ram;
map (dest=bus:tc0:fpi_bus,
dest_offset=0xd0000000, size=112k,
priority=8,
exec_priority=0);
map (dest=bus:sri,
dest_offset=0x70000000, size=112k);
}
memory pspr0 // Program Scratch Pad Ram
{
mau = 8;
size = 24k;
type = ram;
map (dest=bus:tc0:fpi_bus,
dest_offset=0xc0000000, size=24k,
priority=4,
exec_priority=8);
map (dest=bus:sri,
dest_offset=0x70100000, size=24k);
}
LMU has some disadvantages when using stack in LMU:
With this release the LSL for the AURIX derivatives have been changed to locate the stack in the core's DSPR by default. Issue
The section_setup of each stack is now done in the core's linear space, e.g. stack for core 0:
section_setup :tc0:linear
{
stack "ustack_tc0"
(
min_size =
(USTACK_TC0),
fixed,
align = 8
);
stack "istack_tc0"
(
min_size =
(ISTACK_TC0),
fixed,
align = 8
);
}
Equivalent for cores 1 and 2. This has been made the default for all AURIX derivatives (see their dedicated LSL file).
The vector table can be reduced to a single entry by masking the PIPN. If the BIV masks the PIPN so that any interrupt address calculation results in the same address.
__mtcr(BIV,(unsigned int)(interrupt handler) | 1 | 0xFF<<3);
This configures the BIV register to use a common, single entry where a function interrupt handler is located to branch to the specific interrupt routine by using an array of function pointers. If a pointer to the array is used the array could be switched quickly.
Refer to the example blink_aurix demonstrating the single entry vector table: Single Entry Vector Table (SEVT) can be enabled by defining the __SEVT__ macro. The BIV requires SEVT initialization at startup, enable the startup macro's __BIV_SINGLE_INIT, __BIV_SINGLE_TC0_INIT and __BIV_SINGLE_TC0_INIT in the startup include files.
In the c-library new files for support are added: sevt.c and sevt.h.
The PCP compiler lacks generation of uninterruptable code for DSTEP, MSTEP and MSTEP64. To enable such code a new option is introduced: --atomic-divide-multiply atomic divide and multiply
With this option enabled atomic divide and multiply operations are generated. This option only has effect when the channel is interruptible. This is when option --interrupt-enable is specified. Special care must be taken when using multiply and divide sequences when a channel program is interruptible. In this case the compiler makes sure that a sequence cannot be corrupted by the execution of multiply or divide instructions executed by a higher priority channel. The compiler uses bit R7.IEN to ensure that a sequence is not interruptible.
With the introduction of multi-core support the linker supports the --new-task option, originally used for MCS linkage. This option can also be used to create a RAM copy, making teh duplicate libraries obsolete. Therefore these libraries are no longer distributed. The --new-task option extends the duplicate libraries, it will make the complete tree from entrypoint exist in RAM.
For the TC27X A-step new .sfr and .def files are included..
When creating a new project after selecting a processor, the project was created and a debugger simulator configuration was created. With this release you must select the board configuration too. Then the project is created and a debugger board configuration is created. When a debugger simulator configuration is required then you should create this separately.
The list of open issues for v4.1r1 can be found on the internet.
For a quick start, just start the TASKING VX-toolset for TriCore 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 and/or the MCS project examples.
Another icon on the Welcome page, the 'First Steps' icon, links to the 'TriCore Getting Started', 'PCP Getting Started' and the 'MCS Getting Started' documents. 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 PCs 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 release a license key - specific for the bundle - to unlock the appropriate tools.