Version 4.4

Corresponding Revisions of 4.4 and 4.3 are functionally identical, except the change from FLEXlm to TASKING License Management (TLM)

Version 3.1

November 2008
File Date Size Description
Apr 2018

Linker Script Language (LSL) Tips & Tricks for TASKING TriCore Toolset

This application note provides several helpful tips and tricks to help you benefit from the opportunities that LSL provides.

Download link

AP3211020_TC1796_Cookery_Book.pdf Jan 2009 12 MB

Starter Kit TC1796 for TASKING TriCore VX-toolset v2.3r1

AP3213320_TC1766_Starter-Kit_Cookery-Book_TASKING.pdf Jan 2009 14 MB

Starter Kit TC1766 for TASKING TriCore VX-toolset v2.3r1

AP3211720_TC1130_Cookery_Book.pdf Jan 2009 18 MB

Starter Kit TC1130 for TASKING TriCore VX-toolset v2.3r1

LSL-using-Control-Program.pdf Mar 2005 200 KB

LSL Sample Cases using Control Program

Demonstration of the usage of the Linker Script Language while using the TriCore toolchain to locate your application. It contains examples that deal with the most commonly used aspects of the language.

LSL-using-EDE.pdf Mar 2005 205 KB

LSL Sample Cases using EDE

Demonstration of the usage of the EDE's Script File page while using the TriCore toolchain to locate your application. It contains examples that deal with the most commonly used locating aspects.

an060-01.pdf Apr 2002 76 KB

Application Note: Setting Locator Options (v1.4r1 & v1.5r1)

This application note shows how the locator controls influence the locating process. It is intended both for EDE and command line tools users. After reading, the user should be able to configure the locating process and resolve possible errors that may result from applied settings and controls.

an060-02.pdf Apr 2002 60 KB

Application Note: The saturate type qualifier and integral types

This application note covers all aspects of using saturation with integral types.

This page contains TriCore compiler tips & tricks from our customer support staff.

Show help on tool errors

When you encounter errors and/or warnings, they are displayed in the Problems view in Eclipse. If you want to get more details/information about errors/warnings that are encountered during the build process, right-click on an error or warning in the Problems view and select Detailed Diagnostics Info. A message box will appear with more details about the error or warning.

In a command prompt you can use the option --diag=<error number> on a specific tool. For example:

ctc --diag=207
E207: syntax error - token "<token>" deleted
The compiler detected a syntax error caused by an unexpected token. The token was removed in an attempt to recover.

Can I see the command line invocations of all executed tools during a build?

To view all tool invocations during a build in the Console view of Eclipse, open dialog Project | Properties | C/C++ Build | Settings | Global Options, enable option Verbose mode of control program and rebuild your application or file. From the command line, use control program option --verbose (or simply -v) like:

cctc --verbose test.c

How can I minimize the impact of turning off a particular optimization?

Enabling and disabling optimizations for the complete project or one of its modules can have significant consequences. With the #pragma optimize instructions you are able to selectively enable/disable specific optimizations at source level, and obtain more fine-tuned result.

#pragma optimize [flags] Controls the amount of optimization. The remainder of the source line is scanned for option characters, which are processed like the flags of the -O command line option.

#pragma optimize restore End a region that was optimized with a #pragma optimize. The pragma optimize restore restores the situation as it was before the corresponding pragma optimize. #pragma optimize/optimize restore pairs can be nested.


#pragma optimize Y
#pragma optimize restore

In this example, the peephole optimization is turned off for the code that's between the #pragma optimize instructions.

After stepping into a function while debugging, how can I return quickly?

If you (accidentally) step into a function, you can return to the higher level by selecting the Run | Return from Function menu item.

What should I do when I encounter a system error such as S900 internal consistency check failed - please report?

System errors such as S900, S903, S911, S917 indicate an internal problem of the C compiler. There is a good chance this is caused by a problem of a certain C compiler optimization. Thus disabling this optimization might be a possible mitigation. To determine whether an optimization causes the problem you can follow these steps:

1. Disable all optimizations by specifying C compiler option -O0, or by adding the following pragma at the beginning of the affected C source file:

   #pragma optimize 0

2. If the S9xx error disappears after this change, you can do further tests to determine which optimization exactly causes the problem. You can first try to enable some optimizations, by specifying -O1, or by adding the following pragma at the beginning of the affected C source file:

   #pragma optimize 1

3. If the problem still doesn't show up you can try option -O2, or add the following pragma at the beginning of the affected C source file:

   #pragma optimize 2

4. When the problem does show up you need to compare the compiler optimizations settings between the working and non working version. Then you can continue to locate the single optimization that causes the problem, by switching off individual optimizations. For example, use -OF or use

   #pragma optimize F

to disable the control flow optimization.

Hint: you can control these Compiler optimization options from Eclipse GUI as well, see section 4.6. "Compiler Optimizations" from the User Guide ctc_user_guide.pdf.

5. If switching off an optimization does not solve the problem, our TASKING support staff needs a preprocessed version of the affected C source code plus the C compiler options you are using for further investigation. You can create this by adding the option -ECp to the C compiler options. Then a preprocessed file will be created instead of a .src file for the assembler.

Note that even if you did find a mitigation, we encourage you to send this preprocessed C source file, so that we can find out if this is a known issue or a new one. Because almost all S9xx errors will be fixed in an upcoming release.

My application does not start on a target board after the Program Flash memory was erased. How can I solve this problem?

What probably happened is that during the erase memory command, the Boot Mode Header (BMHD) was also cleared. This is the case for TriCore 2xx devices where the Boot ROM is part of the Program Memory Unit. For TriCore 3xx devices, the Boot ROM is located in another part of memory and will stay untouched when you clear the Program Memory.

Normally, the Boot Mode Header on a target board is initialized by factory default to run the target stand-alone. When you flash an application using the TASKING debugger, without any Boot Mode Header configuration, you can disconnect the target board from the debug system and after a reset the application will start just as it went in the debugger. If however the Program Memory was erased, the Boot Mode Header could be unavailable and your application does not run stand-alone on the target board.

To solve this problem, you need to initialize a Boot Mode Header for your target. But be careful, you need to know what you are doing, because wrong use of the Boot Mode Headers might brick the device. Therefore, we advice you to first read chapter 4 TC29x BootROM Content of the AURIX™ TC29x B-Step User's Manual, or similar chapter in the User's Manual for other devices. Also read sections 7.9.13 Boot Mode Headers, and section 9.7.1. Boot Mode Headers in the TriCore User Guide.

To initialize the Boot Mode Header using Eclipse:

  1. From the Project menu, select Properties -> C/C++ Build -> Memory, and open the Boot Mode Headers tab.
  2. In Boot Mode Header 0, from the Boot Mode Header configuration, select Generate Boot Mode Header
  3. Leave the other default settings untouched and select OK.

This will initialize the Boot Mode Header to allow for stand-alone execution of the target.

Item File/Notes
Infineon miniWiggler

Debugger driver

The Infineon DAS driver for the miniWiggler are available from the TASKING site: 

  • DAS driver v4.6.0 recommended for TriCore toolset v6.0
  • DAS driver v5.0.0 recommended for TriCore toolset v6.1
  • DAS driver v6.0.0 recommended for TriCore toolset v6.2 and TASKING Embedded Debugger v1.0
  • DAS driver v7.0.6 required for 64-bit TASKING applications
    Note: we recommend to first execute DAS_V7.0.6_Setup_WIN32.exe to support existing 32-bit TASKING products, then execute DAS_V7.0.6_Setup_WIN64.exe to support TASKING 64-bit products.

Note that Infineon may make newer versions available on their own website. Please understand that these newer versions may not work with your toolset version though, so it is advised to keep a backup copy of your existing installation upon trying a new version.