TriCore/AURIX

After updating Java JRE the following Eclipse error may show up:

The log file shows a line like:
Caused by: java.lang.IllegalArgumentException: Invalid version number: Version number may be negative or greater than 255

To mitigate, install a previous JRE like version 202 which can be downloaded from here and use one the following options:

• Modify the eclipse.ini file which is included in the \eclipse subfolder of the TASKING tools installation directory. Add the following two lines at the beginning of eclipse.ini:
  -vm
  C:\Program Files (x86)\Java\jre1.8.0_202\bin\javaw.exe
• Or adapt the shortcut which starts the Eclipse executable and modify the Target by adding option:
  -vm "C:\Program Files (x86)\Java\jre1.8.0_202\bin\javaw.exe"

Yes. You can use the free OpenJDK 8 with our TASKING products that use the Eclipse platform v4.5.1 (Mars 1). These are the TASKING VX-toolset for TriCore versions v6.1r1 and higher, GTM v3.2r1 and higher and TASKING Embedded Debugger v1.0r3 and higher.

Eclipse requires that you have some Java virtual machine (JVM) installed. 64-bit Eclipse requires a 64-bit JVM, and a 32-bit Eclipse requires a 32-bit JVM. You may either install a Java Runtime Environment (JRE), or a Java Development Kit (JDK). Currently we ship the free Oracle JRE with our products. Oracle JRE 1.8 (before April 2019 update) will stay for free. For newer versions Oracle charges a license fee. Instead of installing the Oracle JRE, you can use the free OpenJDK 8. For example, you can use OpenJDK 8 (LTS) from https://adoptopenjdk.net/.

If you have installed Eclipse Mars 2 yourself and use the TASKING VX-toolset for TriCore as a plugin (only possible for v6.3r1), you can also use higher versions than OpenJDK 8.

After installation of the OpenJDK, make sure that the OpenJDK is your default JVM. Otherwise you need to update the file eclipse.ini in the eclipse directory of the product to point to the correct JVM. See https://wiki.eclipse.org/Eclipse.ini#Specifying_the_JVM for more information.

Our future products will ship with a free OpenJDK.

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.

Yes, the 64-bit version of Amazon Corretto has been tested successfully with TriCore toolset v6.3r1. Also, the 32-bit version of Amazon Corretto JRE8 can be used for the 32-bit versions of the TASKING TriCore tools (versions up to v6.2r2) which are JRE8 compliant.

To force Eclipse using Corretto JRE you can update file eclipse.ini located in the sub-directory ctc\eclipse of the tools and add the following two lines at the top of the ini file:

 -vm
<path to the Amazon Corretto JRE 8 install>\bin\javaw.exe

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

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.

EXAMPLE:

#pragma optimize Y
[code]
#pragma optimize restore

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

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.

The cause of these warnings is that the heap definition was moved from tc_mc_arch.lsl to the file derivative.lsl to support core specific LSL files where each core has its own heap. The file tc_mc_arch.lsl file is included by derivative.lsl.

When the project uses a (customized) derivative.lsl from an older version you can mitigate the issue as follows:

• Either: copy the file tc_mc_arch.lsl included in the ctc\include.lsl subfolder of the older TriCore toolset version to the same folder which includes the file derivative.lsl your project uses. Then the heap definition is included again.
• Or: add the following entries to the file derivative.lsl your project uses:
  

  #ifndef HEAP
  #define HEAP  16k  /* heap size */
  #endif
  section_setup :vtc:linear
  {
      heap "heap"
      (    
          min_size = (HEAP),
          fixed,
          align = 8
      );
  }

In v6.3r1 the 'entry_points' keyword was introduced to allow the specification of different entry points for the stack size calculation. In case you are using a customized derivative.lsl from an older TriCore toolset version in your project, you need to add the default 'entry_points' entry for core 0 to that file.

// macro definition added 
#define __USTACK0_ENTRY_POINTS_ATTRIBUTE ,entry_points=["_START"]

section_setup :tc0:linear
{
    stack "ustack_tc0"
    (
        min_size = (USTACK_TC0),
        fixed,
        align = 8
        // macro added to the core 0 user stack section
        __USTACK0_ENTRY_POINTS_ATTRIBUTE
    );

The C startup code included in v6.3r1 refers to the linker label _lc_ub_ustack which indicates the start address of the user stack for core 0. You can add this label to the customized derivative.lsl as follows:

section_layout :tc0:linear
{
    //added for TriCore tools v6.3r1 compliance
    "_lc_ub_ustack" := "_lc_ub_ustack_tc0"; /* common cstart interface for first or single core */
    "_lc_ue_ustack" := "_lc_ue_ustack_tc0"; /* common cstart interface for first or single core */
    "_lc_ue_istack" := "_lc_ue_istack_tc0"; /* common cstart interface for first or single core */
}

An alternative approach is to use the C startup code of the older version instead.

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.

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

Parts of internal memory gets cleared at power-on and soft-reset automatically due to security reasons of the TriCore/AURIX microcontroller. This can be prevented by setting bitfield RAMIN from register UCB_DFLASH to “Don't init RAM after power on reset”. This requires a 3rd party flash tool like the free memtool from Infineon. After setting this bitfield, the application can be loaded and run from RAM successfully using the TASKING debugger.