This website uses cookies so that we can provide you with the best user experience. To read more about the cookies we use and to change your settings see our Cookies Policy.
This article provides information regarding the TriCore v6.3r1 cross-linking in addition to the existing Chapter 7.5 Cross-Linking in the TriCore user guide . It explains the changes introduced in the v6.3r1-based patches due to EABI compliance reasons. Moreover, this article includes deta...
This article is for the TriCore toolset. According to the ISO C standard, global variables need to be initialized. If a variable is not initialized as shown below, it will be initialized with zeroes. int var_1; The initialization is conducted during the execution of the startup code. For i...
This article is for the TriCore toolset. A similar approach applies to our other toolchains as they use the same linker script language. When a variable is initialized as shown below, the initialization value for this variable needs to be placed in flash memory : int var_1 = 10; The linker...
If an address of a variable or a function is not known by the application, for example, because the variable or function is part of another application that is linked separately, you can use LSL symbols to specify the address of those symbols during link time. This approach prevents a reco...
This application note explains the migration of an AURIX/TriCore software project built with GCC to the TASKING toolset. It outlines the necessary changes to the C/C++ source code to address implementation-defined behavior and support intrinsic functions, attributes, etc. Additionally, it ...
This application note provides several helpful tips and tricks to help you use Linker Script Language (LSL) effectively in a TriCore VX-toolset. The key topics include: LSL code core association and data core association Using the overflow keyword for distributed output sections Using the ...
The available on-chip memory of an Infineon AURIX family derivative is distributed across various memory areas. You need to be aware of the extent to which the application code and data use individual memory ranges. This can indicate potential bottlenecks that may require you toadjust the ...
When you use an LSL group to select sections, for example, for a dedicated placement in memory, a section might not be assigned as expected. This may be due to the wrong space selection in the section_layout in the LSL file. Possible solution Although group names are optional, consider usi...
This article is for the TriCore product. A similar approach applies to our other products as they use the same linker script language. The C compiler adds section attributes to all code and data sections it creates. The available section attributes are: r readable sections w writable sec...
The cause of these warnings after upgrading to v6.3r1 is that the heap definition was moved from tc_mc_arch.lsl to derivative .lsl to support core-specific LSL files, where each core has its own heap. The tc_mc_arch.lsl file is now included in derivative .lsl . Possible solutions When the ...
Possible solution In TriCore v6.3r1, the entry_points keyword was introduced to specify different entry points for the stack size calculation. If those entry points are not defined, the map file will show a stack size of zero bytes in the 'Estimated stack usage' section like: * Estimated s...
Our TriCore tools feature the language extensions __share , __private0 , __private1 , __private2 , and __clone to assign a code or data section to multiple cores or a single core only. You can achieve the same goal with the following pragmas: #pragma code_core_association share | private{0...