This release note covers the changes between v3.4r1 and v3.5r1 of the TASKING VX-toolset for TriCore and PCP.
With the introduction of Code Compaction for the cores TC1.3 and TC1.3.1 it turned out that the FLEXlm protection on the optimization Code Compaction was giving runtime complications. Because of the fact that Code Compaction is part of the -O option, and by default enabled in -O2 (default setting of the compiler), the compiler would issue a warning for each invocation when no Premium Edition license was available. Refer to 160-38125.
The silicon bug workaround for CPU_TC.116 has been implemented for the following derivatives: TC1100, TC1115, TC1130, TC1792 and TC1796.
Please refer to 160-37993, 160-38002, 160-38056 and 160-38152.
MIL archives may differ between different compiler versions. Refer to 160-37806. This might cause the compiler to trap and generate an S900 error message. To prohibit this, the MIL archives have been given an ID (version) which is generated by the compiler. Only in case the ID corresponds to the compiler's internal ID, it accepts and parses the MIL archive. Older compilers (prior to v3.5) will give an error message on this new attribute.
With this ID in MIL archives it might be possible that with a future compiler MIL archives created with the current compilre can not be read anymore and the MIL archive needs to be regenerated with that new compiler.
When using Eclipse, the control program is used in the makefiles (generated by Eclipse) to build the objects and elf-files. When a cpu is specified, which is always the case when using Eclipse, the control program automatically knows if a FPU is available on the cpu. This is always the case except for the TC11iB. It will therefore in all those cases automatically compile and link for FPU.
However when on command line the cpu is not specified or the control program is not used (or not used with the cpu option), the compiler is compiling for fpu simulation and the default libraries are used for linking. It is adviced to use the cpu option and to use the control program.
For a future release we consider making the usage of FPU the default instead of floating point simulation.
Upto and including the previous release (v3.4r1) the compiler would automatically read the sfr definition file regtc<cpu>.sfr when a cpu was specified on command line. We realized that in the majority of the cases the sfr file was not needed. Since the processing of this file takes significant time when compiling small files, it would cause a lot of overhead in compilation speed. Therefore the automatic inclusion has been disabled. Refer to 160-38028.
With this release the default debug information is based on the DWARF3 standard. This standard is an extension on the DWARF2. The reason for doing this is that it was needed to be able to support our feature "Global Type Checking" (refer to 160-36298), to be able to debug the PCP code. Refer to 160-37321.
Objects with DWARF3 debug information can be linked with objects holding DWARF2 debug information. Our debugger can handle both formats and can sort out the appropriate debug information per C-line and assembly instruction.
According to the EABI plain int bitfields must be unsigned. The default of the TriCore compiler was signed. This has been changed to be EABI compliant and because unsigned bitfields are more efficient. Refer to 160-38007.
This section gives an overview of the most important new features and improvements in v3.5. See the sections with fixed issues for a complete list.
For the following list of new derivatives, device simulator debug support is available:
'AUDO MAX' derivative TC1184,
core TC1.3.1
'AUDO MAX' derivative TC1724, core
TC1.3.1
'AUDO MAX' derivative TC1728, core
TC1.3.1
'AUDO MAX' derivative TC1784, core
TC1.3.1
The "Global Type Checking" feature will give you extra safety in calling functions with the correct parameters. The compiler and linker have been extended with the option --global-type-checking to enable this feature. The compiler will generate extra debug information by which the linker can perform a cross-reference check on all objects that have been compiled with this feature and identify inconsistencies. Refer to 160-36298.
With this release the debug information is DWARF3 by default. This version of DWARF enhances the capabilities of the debugger. It makes it also possible to utilize the feature "Global Type Checking" (refer to 160-36298).
The EABI however specifies that DWARF2 must be generated. To become EABI compliant again, a new option is introduced in the compilers and assemblers, --dwarf-version=[2|3]. When set to 2, the old debug information DWARF2 is generated. When used, the feature "Global Type Checking" is however not possible. Refer to 160-38071.
When running in EABI compliant mode (through the option --eabi-compliant), the DWARF debug will automatically be set to DWARF2.
To improve the compilation time, the automatic inclusion of the regtc<cpu>.sfr has been disabled. When the sfr-file is needed, the new option --tasking-sfr can be used and the sfr-file is automatically included again. Refer to 160-38028.
According to the EABI plain int bitfields must be unsigned. The default of the TriCore compiler was signed. This has been changed to be EABI compliant and because unsigned bitfields are more efficient.
For backwards compatibility the option --signed-bitfields has been introduced, which makes the plain int bitfields signed again. Refer to 160-38007.
With this release the feature Code Compaction is made available for the core TC1.3 and TC1.3.1. This will improve code density with approximately 5%, but of course this depends completely on the source code and its structure. Refer to 160-37926.
For being able to get the best performance of the different memories that are available in the cpu, the LSL description has been extended with the speed attribute. The default locate order is to use low address before high address. For the TriCore, external ram is usually in a lower address range than internal ram. Currently data is located in external ram before internal ram, which is not efficient. For example ldram is located at 0xd0004000 and xram is located at 0x80400000. It is required to use internal memory first until it is occupied, then xram should be used. This requires that the priority is changed for internal and external ram. With the LSL speed attribute the performance of a specific memory can be enlarged. The default speed value is 1, which is equal to the lowest performance. All internal (non-reserved) memory is defined with speed is 2, all external and reserved memory have the default speed 1. Refer to 160-38019.
To be able to have cached memory and not cached memory at any location in the cpu, the attribute cached and not_cached has been introduced in the LSL description. Refer to 160-38025.
Changing the default from cached to not cached memory can be done by moving the reserved attribute from the not_cached memory map to the cached memory map.
The list of open issues for v3.5r1 can be found on the internet.
For a quick start, just start the 'TASKING VX-toolset for TriCore and PCP' 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 and/or the PCP project examples.
Another icon on the Welcome page, the 'First Steps' icon, links to the 'TriCore Getting Started' and the 'PCP Getting Started' documents. This is a good starting point for exploring the capabilities of the environment and the tools.
When using the product without a valid license, the tools will run in trial mode. This means you can use the toolset 15 days with full functionality. When running in trial mode, each tool will report the number of days left. When using a license that does not cover the full toolset, the tools that are not covered by the license will run in trial mode.
When after installing the license file the tools that are covered by the license still report that they are running in trial mode, this means that there is a license error. If you want to force the termination of the trial mode to get the FLEXlm error message you can set the environment variable FORCE_NO_TRIAL to "yes".
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, although you can use the full functionality during the 15 day trial period as described above. 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 and PCP 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. Any tools from a more extensive bundle than what you purchased, will continue to run as full trial version for maximum 15 days (depending on how many days you already used).