This release note covers the changes between v3.2r3 and v3.3r1 of the TASKING VX-toolset for TriCore and PCP.
The pipeline and the cache(s) of the TriCore architecture are implemented in such a way that there is no automatic coherency between the state as seen by the CPU itself and that seen by the debugger via OCDS. For example, if the target halts on a breakpoint, a memory value read via OCDS may not represent the "real" value as implied by the program logic if the value still has to be written back from the cache.
The debugger has a special "sync(hronize)-on-halt" facility to bring about this coherency. Every time the target halts, the debugger will execute a routine _sync_on_halt that flushes the pipeline and the caches insofar as necessary.
This routine is implemented in the file ctc/lib/src/sync_on_halt.c, which (like cstart.c) will be added to a new TriCore project unless you deselect the checkbox "Include debugger synchronization utility" in the New C/C++ Project wizard, which you may want to do if you do not intend to use the debugger. In any case, by default the code will be linked in only in the Debug configuration, not in the Release configuration (via the Exclude from build facility).
The code in sync_on_halt.c works for most supported TriCore derivatives. For the following derivatives, the file must be excluded from teh build process: TC11IB, TC1115, TC1130 and TC1798. When using a user-defined processor or certain special features such as memory protection, you may have to adapt it. When running the simulator this file may be excluded from the build also, since it is meant for debugging on the target board.
If the project involves PCP code as well, an empty loop routine _PCP_sync_on_halt will be linked in as well. Unlike for the TriCore, this is extracted from the library, not from a project file. This is controlled by the linker option "Include debugger synchronization utility".
It should be kept in mind that the execution of these routines at each halt may have unwanted side effects on the performance of the target application, particularly as a result of the cache flushing. In certain cases, you may therefore want to switch off this feature, but it should be realized that this could have a severe impact on the debugging experience. In particular, software breakpoints and File System Simulation may not work properly anymore.
The different cores use some different settings. When in Eclipse another core is selected you should copy the four (4) configuration files from the <install-dir>/ctc/etc/tsim_config/<core> directory into the project directory. This to make sure that e.g. the Watch Dog Timer address is set correctly, etc.
The system include file float.h has been split into two variants: float.h and except.h. The latter one is meant for trapping floating point. The example 'fptrap' in Eclipse shows the inclusion of the new header file. This new system include file is now available in de TriCore and PCP include directories.
An inconsistency was detected between conversion of float to int between the TC1.3.1 and TC1.3 core. The issue is registered as "160-37269 - inconsistent float to int conversion (FTOU vs FTOUZ instruction)". When building for TC1.3.1 with --fpu-present, the float to unsigned integer was performed by rounding to zero using fpu instruction FTOUZ. Due to the absence of the FTOUZ instruction in the TC1.3 core, the fpu instruction FTOU was used, resulting in a rounding to nearest. As this behavior was known to be in conflict with the ISO C99 standard, it was documented in the user manual as a deviation.
As of release v3.3r1 this inconsistency for TC1.3 based derivatives is addressed by calling the runtime library function __f_ftoui (for float to unsigned integer conversion) or __f_ftoi (for float to signed integer conversion).
You should take care of this since change when building for
TC1.3 and using the fpu instruction (--fpu-present option). The result
of the conversion might now result in a different value than it did
before using compiler releases prior to v3.3r1, which may have impact
on the result of your application.
The Eclipse IDE has been upgraded to the latest version, named Galileo. Included with this upgrade is CDT version 6.0.1. Unfortunately, due to a problem in this CDT version a program exception will occur when after the menu entry 'Properties -> C/C++ Build -> Discovery Options' has been selected any following entry (e.g. 'Settings') in this dialogue will be chosen. It is therefore advised to avoid the use of the 'Discovery Options' entry. When accidently used, the only way to recover from this is to close the dialogue by the Cancel button and then to reopen the Properties dialogue.
Is has been announced that this bug will be solved with the next CDT version 6.0.2 which will be due February 2010. Altium will include such updated CDT version then in the next release of its VX-toolset for TriCore.
This section gives an overview of the most important new features and improvements in v3.3. See the sections with fixed issues for a complete list.
With this release the latest TriCore architecture TC1.6 is supported, such as the new instructions that are introduced with this architecture level.
The new TC1.6 core enabled the implementation of the Code Compaction compiler optimization using the new FCALL and FRET instructions. This optimization gathers pieces of generated code that are equal and places the code once in a separate function, which is called from the original location of the code. This optimization (-Or) is enabled in -O2 and -O3. Code will only be replaced by a call when the total of the replaced pieces of code compared to the total of the inserted calls plus the new function is larger. A compiler generated Code Compaction function can call a compiler generated Code Compaction function. This can be infinite. The maximum length of a Code Compaction function is set to 200 bytes. However, these two properties can be influenced by option --compact-max-size=<value> (default: 200) and --max-call-depth=<value> (default: -1 = infinite).
The resulting debug information is still compliant with the DWARF standard, but extra intelligence is required in the debugger to hide the effects of this optimization from the user as much as possible. You may need to contsult your debugger vendor for an updated version of the object file reader in case you experience any limitations.
Code Compaction may reduce code size on average by about 5-10% on top of other optimizations. This Code Compaction optimization is available in the Premium Edition and will be effective on TC1.6 derivatives only.
Code Compaction results heavily depend on the source code, file sizes and structure.
In addition to the compiler's integrated MISRA C code checking Altium introduces with release v3.3r1 Static Code Analysis for the CERT C secure coding standard. CERT, the Computer Emergency Readiness Team was founded by the US government and created the coding standard as a guideline to secure coding. More information is available on the CERT website.
The CERT C secure code checking functionality is available in the Premium Edition.
The compiler can check for the following rules and recommendations:
| Category | Implemented Checks |
|---|---|
| 01. Preprocessor | PRE01, PRE02, PRE10, PRE11 |
| 02. Declarations and Initialization | DCL30, DCL31, DCL32, DCL35 |
| 03. Expressions | EXP01, EXP12, EXP30, EXP32, EXP33, EXP34, EXP37, EXP38 |
| 04. Integers | INT30, INT34, INT35 |
| 05. Floating Point | FLP30, FLP35, FLP36 |
| 06. Arrays | ARR01, ARR34, ARR35 |
| 07. Characters and Strings | STR30, STR33, STR34, STR36 |
| 08. Memory Management | MEM00, MEM08, MEM30, MEM31, MEM32, MEM33, MEM34, MEM35 |
| 10. Environment | ENV32 |
| 11. Signals | SIG30, SIG32 |
| 49. Miscellaneous | MSC32 |
The make utility, amk has been extended with several new features:
See for details the User Guide, section "9.3. Make Utility amk".
The new 'AUDO MAX' derivative TC1798 is supported. Device simulator debug support is available.
The new device is based on the TriCore 1 V1.6 architecture, which adds an expanded instruction set as compared to the TriCore 1 V1.3.1 architecture. ELF files created for the new derivative will have the E_FLAGS field set to EF_TRICORE_V1_6, indicating the new architecture.
For the TC1767 and TC1797 derivatives the PCP2 needed a silicon-bug workaround. The silicon bugs are registered as PCP_TC.034 and PCP_TC.038. For this the compiler and assembler have been updated.
For the TC1736, the silicon bug workarounds CPU_TC.105 and CPU_TC.106 have been implemented.
The map file viewer in Eclipse has been improved to make it easier to analyse the results of your build. The following improvements have been made:
See the User Guide, section "13.2. Linker Map File Format" for a detailed description of the map file viewer
Two new attributes have been added to the compiler:
| Attribute | Description |
|---|---|
| __attribute__((used)) | Prevent unreferenced objects from being removed by the compiler or linker. This replaces the #pragma protect, which becomes depricated. Refer to 160-37603 |
| __attribute__((export)) | Indicates that not all uses of a variable/function can be known to the compiler during the mil-link phase. For example when a variable is referenced in an assembly file or a (third-party) library. Refer to 160-37604 |
The automatic inlining optimization of the compiler can now be controlled with the --tradeoff (-t) option. This makes it easier to configure the optimizations for an application. The --inline-max-incr and --inline-max-size options are still available and can be used to overrule settings made by --tradeoff.
In Eclipse the default values of the --inline-max-incr and --inline-max-size options is now empty, meaning that the --tradeoff setting is used.
See the User Guide section "4.6.3. Optimize for Size or Speed" paragraph "Automatic Function Inlining" for details.
The behavior of a compiler with respect to optimization across volatile accesses is defined as implementation defined in the ISO-C '99 standard. With the new C compiler option -Av (--language=+volatile) you can control this behavior. By default the compiler has the same behavior as in previous versions and will optimize across volatile accesses. With the -Av or --language=+volatile option the compiler will make a volatile read or write access blocking for optimizations.
DAS is upgraded to version 2.9.0. With this version the following is changed:
The new UDAS Server supports:
To easily share variables between PCP and TriCore cores, two new qualifiers have been implemented: __pram and __share.
1) External PCP PRAM Data References: __pram
You can reference external PCP PRAM data from the TriCore with the keyword __pram. Only external variables can be qualified with the keyword __pram. Global PRAM variables can only be defined in the PCP application. Only types with a size of 32-bit can have the keyword __pram, because only 32-bit types are supported by the PCP in the PRAM space.
2) Shared Data between TriCore and PCP: __share
Global data can be shared between the TriCore and PCP with the keyword __share. Only global and external variables can be qualified with the keyword __share.
The Eclipse IDE has been upgraded to the global version Galileo, with CDT 6.0.1.
In addition to this, a minor change in the dialogue of the New Project wizard is introduced. When creating a new project, one can now select the derivative (processor) already.
The list of open issues for v3.3r1 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).