This release note covers the TASKING VX-toolset for C166 version 2.3r3. It describes the changes since v2.2r1.
The following sections are included in this release note:
15-day Trial
Important Notices for Migrating from v2.2
General
Eclipse
C++ Compiler
C Compiler
Assembler
Linker
Debugger
Summary of changes between v2.3r2 and v2.3r3:
Summary of changes between v2.3r1 and v2.3r2:
Summary of changes between v2.2r5 and v2.3r1:
Summary of changes between v2.2r4 and v2.2r5:
Summary of changes between v2.2r3 and v2.2r4:
Summary of changes between v2.2r2 and v2.2r3:
Summary of changes between v2.2r1 and v2.2r2:
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".
The following issues require attention when migrating from a v2.2 release to v2.3r2:
Support has been added for XC2267M-104F, XC2287M-104F, XC2365A-104F, XC2387A-104F, XC2765X-104F, XC2785X-104F, XE162FM-72F, XE164FM-72F and XE167FM-72F. SFR files and LSL files are added for these devices. These processors can also be selected for the Infineon EasyKit boards.
Due to the large size of the SFR files for the new devices, the compile time increased significantly. The following measures have been taken to compensate for this:
To obtain faster compilations with large SFR files, the SFR file format has been overhauled completely. The default .sfr files still define the same SFR and SFR bit-field names as in v2.2, but the macros are defined in such a way that processing by the compiler is faster.
Additionally an alternative SFR file format has been introduced. This format is comparable to what is used in for example the TASKING VX-toolset for TriCore. In this alternative SFR file format each SFR is now defined using a union of a struct with bits, a singed integer and an unsigned integer. This alternative SFR file format has as advantages over the standard SFR file format that it is compiled significantly faster and that there is less name space used because it is unnecessary to define a macro for each bit-field.
Examples of the use of the alternative SFR definitions:
WDTREL.U = 0x300; // Initialize SFR as unsigned integer U0C0_IN00.I = -12; // Initialize SFR as signed integer PSW.B.IEN = 1; // Set a bit-field
The alternative SFR file format can be selected with the --alternative-sfr-file option of the compiler. In Eclipse it can be enabled in the project properties on the C/C++ Compiler -> Preprocessing page.
The new SFR files do not include additional information, such as descriptions, bit-field values and reset values, which are needed by the Eclipse cstart editor and the debugger. For that purpose XML variants of the SFR files are now included in the product.
The SFR file readers in the assembler and simulator engine have been adapted to the new format. Therefore it is not possible to use SFR files from versions older than v2.3 with the tools. In case you copied old SFR files to your project and modified the contents, you can keep using them for the compiler. But the assembler must use the new style SFR files.
See the desciption of the SFR files in the manual (1.3.5. Accessing Hardware from C) for more information.
SFR files for Infineon XC16x, XC2xxx and XE16x have been updated use the naming
convention peripheral_sfr-name for SFRs and
peripheral_sfr-name_field-name for bit-fields. The 'old' names will remain
available as alias.
For example:
SCU_SLC = 0xaaaa;
But also still allowed is:
SLC = 0xaaaa;
For devices that have an alternative address range for MultiCAN and USIC the alternative range can be selected by defining the macros USE_ALTERNATIVE_MULTICAN_ADDRESSES and USE_ALTERNATIVE_USIC_ADDRESSES. These macros are used in the SFR files to select the desired addresses.
Near addressing for MultiCAN and USIC for these devices is now selected by defining the macros USIC_REGISTERS_NEAR and/or MULTICAN_REGISTERS_NEAR. Of course you should set a DPP to point to the page(s) of these peripherals. If for both USIC and MultiCAN the alternative address ranges are used, only a single DPP is needed.
To speed up compilation the control program (cc166) invokes the assembler
with the --core option and not with the -C option, but only when processing compiler generated file. This way the assembler only reads the core SFR file and only knows the core SFRs. When using in-line assembly in C using __asm(), the assembly should not contain other SFRs than the core SFRs. If you do want to use other SFRs, you must supply the -Wa-Ccpu option to the control program. In Eclipse you can specify this option on the C/C++ Compiler > Miscellaneous > Additional options page.
Be aware that by doing so the compile time will increase. To avoid that you can set the -Wa-Ccpu option only for the modules that use in-line assembly with SFRs that are not core SFRs.
The module cstart.c in the product's lib/src directory has been updated to
match the new SFR file format. Also the cstart.h in the product's include directory has been updated. When using the compiler option --alternative-sfr-file, you must update the cstart.c and cstart.h in your project. In case you made custom changes to the cstart.c you may need to apply these changes again to the new
cstart.c.
From Eclipse you can update the cstart.c and cstart.h with File > New... > New cstart.c/cstart.h files. The settings in cstart.h will be applied automatically to the new cstart.h by Eclipse. When not using Eclipse, you will have to update the cstart.h manually.
The list of supported processors is now entirely defined with XML files. The product's etc directory contains a processors.xml file, which defines the standard set of processors. The file defines for each processor its full name (e.g. XC2287-72F), the base cpu name (e.g., xc2287), the core setting (e.g., xc16x), the on-chip flash settings, the list of silicon bugs for that processor. Each processor also defines a flag to supply to the linker for preprocessing the LSL file for the applicable on-chip memory definitions. The flag is for example -DXC2287_72M).
The processors.xml file is read by Eclipse to show the list of processors and to derive the settings for the selected processor. It is also read by the control program, cc166, to derive the settings for the underlaying tools. The processor to be used is supplied with the -C/--cpu option to cc166. With v2.3r2 the behavior of the -C/--cpu option has changed. In previous releases this option defined the base CPU, like for example -Cxc2287. Now the preferred use is to specify the full processor name, like for example -CXC2287-72F. This processor name will be looked up in the processors.xml, and attributes for that core will be passed to unerlaying tools, for example -Cxc2287 --core=xc16x to the C compiler, or -D__CPU__=xc2287 -DXC2287_72F to the linker.
Additionally, cc166 still supports the base CPU as argument of -C/--cpu, for example -Cxc2287. It will then lookup the first processor in processors.xml that has this base CPU as an attribute and select that processor. If multiple processors exist with the same base CPU, a warning will be issued and the first will be selected:
cc166 W752: the name 'xc2287' specified with -C or --cpu is not a full processor name and is not a unique base CPU name, selected 'XC2287-56F'
In practice the differences between processors with the same base CPU is a difference in on-chip memories.
The implementation of the -C/--cpu and --core options in the C++ compiler, C compiler and assembler have changed. In previous releases the tools had a complete list of all known CPUs to derive the core setting. With v2.3r2 this has changed to allow dynamic extension of the list. The tools now know all CPUs with core c16x, st10, st10mac and super10. If the -C or --cpu option specifies a CPU that is not in that list, it is assumed to be an xc16x. Of course this can be overruled with the --core option. If no -C/--cpu and no --core are used, the default core is the same as before: c16x
The dynamic definition of processors through an XML file makes it possible to define additional processors by either updating the processors.xml file in the product's etc directory or by supplying additional processors.xml file(s) to Eclipse or the control program. In Eclipse you can specify additional processors.xml files on the preference page: Window -> Preferences -> TASKING C166 Preferences. Eclipse will generate for each XML file a --processors option in the makefiles. The --processors=file option is in v2.3r2 a new option for cc166. The specified file will be read after the processors.xml in the products' etc directory. Additional XML files can override processor definitions made in XML files that are read before.
The Eclipse platform and C/C++ Development Tooling have been updated to the latest Eclipse release called Ganymede. An overview of noteworthy changes:
See the Eclipse website for a detailed overview of what's New in CDT 5.0 and Platform 3.4
.Due to a change in the Eclipse CDT the indexer will generate syntax errors on existing C++ source files. To fix this, act as follows:
The C166 VX-toolset can now import Keil C166 projects. Importing a Keil project can be done using the File > Import... dialog in Eclipse. In this dialog you can select TASKING C/C++ > Keil C166 Projects to start the Keil import wizard. The VX-toolset for C166 tool options will be set analogous to the Keil project options. The LSL file will be updated as good as possible. C, C++ and assembler source files will be imported and converted using the source code converter, keil2vx.
With the DAvE import wizard DAvE 2 projects can be imported into the workspace. It is possible to copy the project to the workspace, or to create the Eclipse project into the directory of the DAvE project. To import a DAvE project, use the File > Import... dialog and select TASKING C/C++ > Infineon DAvE C166 Projects. A DAvE project in Eclipse can be refreshed by clicking with the right mouse button on the project name and selecting "Refress DAvE Settings".
The Sections page in the LSL editor has changed significantly. It is now possible to make virtually any layout allowed with the LSL syntax.
The contents of the Reserved page in the LSL editor has been moved to the Memory page. This gives you an overview of all memory settings at a glance.
The LSL language has been extended to support tags. A tag is an arbitrary text that can be added to a statement. The Target Board Configuration wizard and the Flash properties page now use tags to recognize the parts they added to your LSL file. In previous releases this was done using the macros __DTC_START, __DTC_END, __FLASH_START and __FLASH_END. Now the Target Board Configuration wizard applies the tag "dtc" to the added LSL statements and the Flash properties page uses the tag "flash=flash-id".
A new make utility has been added to the product: amk. This make supports parallel builds, which means that it can invoke multiple actions (i.e., compiler invocation) in parallel. On a multi-core computer this will reduce the overall project build time. Currently the functionality of amk is limited to functionality needed by the makefile generator of Eclipse. The 'external builder' of Eclipse now uses amk. You can select the builder to be used on the properties page: Project > Properties > C/C++ Build. On the Behavior page you can configure the parallel build. By default the external builder will be used.
The option for MIL linking on the "Global Options" page of the tool settings in Eclipse has been renamed to Build for application wide optimizations (MIL linking). Note that the optimizations to be performed are controlled with the optimization settings. See also Build for Application Wide Code Compaction
New export and import wizards have been added to Eclipse to export or import the C/C++ project properties. When exporting, all properties of the dialog page Project > Properties > C/C++ Build > Settings are written to an XML file. With the import wizard such XML file can be read and the settings are applied.
For exporting properties use: File > Export... > TASKING C/C++ > TASKING C/C++ Project Properties. Only one of the available build configurations can be exported to a file.
For importing properties use: File > Import... > TASKING C/C++ > TASKING C/C++ Project Properties. You must select in which project and which build configuration you want to import the properties
In the Flash properties (Project > Properties > C/C++ Build > Flash) the Address field can now contain a comma separated list of addresses. Each additional address in the list is considered as a mirror of the Flash memory.
The C++ pre-linker prelk166 and symbol dumper sd166 have been removed from the product. The functionality of these tools is incorporated in the linker.
When using the far, segmented huge or huge memory model you can now let the compiler allocate a set of objects in the near memory automatically. This feature allows you to use near memory when you don't want or cannot modify your code to add memory qualifiers.
To do automatic near allocation, the compiler needs an overview of the whole application. Therefore building for application wide optimizations (MIL linking) is mandatory. With the MIL linking phase, the option --automatic-near must be supplied to the compiler. In Eclipse the following options are involved:
With automatic near allocation the compiler locates the objects into near memory working from the highest access frequency to the lowest access frequency.
Because the compiler must allocate objects in the near memory space, it needs to know how much near memory is available, which parts of it are ROM and RAM, etc. To obtain this information, the compiler reads the LSL-file. This must be the same LSL-file as the linker uses. The compiler only considers the near memory space and expects it to be free. This will be verified using the LSL-file. It is possible to define heap, stack, vector table and reserved areas, select them and locate them at an absolute address. It is not possible to select other sections, and try to locate them in the address range of the near memory space.
Pointers that are changed from __far, __shuge or __huge to __near will keep a storage of 32 bit. The __near pointer will be stored in the low word of this 32 bit. This is required because otherwise constructs like sizeof( int *) would be ambiguous. Pointers that are changed into __near will be shown as __near32 by the debugger.
To make an object near, the compiler must try to track all assignments to that object and must decide to make the assigned objects also near. Because not all assignments can be tracked, the result will be suboptimal, but always better than without automatic near allocation. The following restrictions apply:
Note that also pointers related to the pointers in the cases above will not be rewritten.
It is now possible to use MIL linking without MIL-split. This has as advantage that the code compaction optimization can be performed application wide. Building for application wide optimizations (MIL linking) can be configured from the Eclipse properties page: Project > Properties > C/C++ Build > Settings > Global Options.
The compiler and linker now support global type checking. When using the --global-type-checking option on the compiler, the compiler will emit debug information necessary to perform type checking at link time. When supplying the --global-type-checking to the linker, the linker will report type mismatches on global/extern pairs. Global type checking is enabled by default in Eclipse. You can disable it from the properties page: Project > Properties > C/C++ Build > Settings > C/C++ Compiler > Diagnostics.
Some remakrs on global type checking:
__CONTIGUOUS_NEAR is defined.When global type checking is enabled, declarations will be present in the debug information of the absolute file. Third party debuggers may not accept this.
TASKING Type Qualifiers Extension Encoding in the DWARF 3.0 debug information has changed to allow generation of complete information on type qualifiers for the debugger. The TASKING debugger in v2.3 also uses this changed encoding, but other debuggers will need to be updated. In case an updated debugger is not available, you can use the compiler option --dwarf-encoding=1. From Eclipse you can add this option to the Additional options edit-box on the properties page: Project > Properties > C/C++ Build > Settings > C/C++ Compiler > Miscellaneous.
The compiler now also generates debug information for variables with the __unaligned qualifier. This is represented in the DWARF debug information as TAG_packed_type.
Previous versions of the compiler did not generate information of qualifiers like volatile for struct members. This has been fixed in this release.
The register bank name generated for the __registerbank() qualifier now gets prefixed with _$ instead of __ (two
underscores).
Example:
void __interrupt(-1) __registerbank(mybank) myinterrupt(void)
{
...
}
Results in a register bank name _$mybank at assembly level. This change requires changing the LSL file when it selects the register bank section. Also assembly files that interface on the register bank name must be updated.
The part in float.h that contains definitions for the internals of the run-time floating point library implementation has been removed from float.h and is placed in a separate header file fpbits.h.
Normally the compiler will not accept a memory type other then __near for automatic/parameter variables and will issue an error. The reason for this is that the user stack is always in near memory.
When the new option --ignore-memory-type-for-automatics is used any memory type will be accepted, however the compiler will ignore it and use __near instead.
The new compiler option --ramdata and the #pragma ramdata can be used to force allocate static and global const variables in RAM. The initialization is done by copying the data from ROM to RAM, using the copy table, just like with any not const global or static initialized variable. The #pragma noramdata turns back to the normal behavior of putting const global and static variables only in ROM
The option and pragmas allow you to put const variables into fast on-chip RAM
An identifier (label, section name, macro names, etc) can now contain a $. The $ character cannot be used
as first character of a label.
Example:
my$label: JMPS my$label
The system LSL files, located in the product's include.lsl directory have been updated:
reserved statement.reserved statement.In case you copied system LSL files, such as the CPU's LSL file (for example xc2287.lsl), from a previous version to be part of your project you may consider copying the new LSL file(s) again and re-applying the updates you have made.
The linker map file has been extended with a table listing all sections removed by the linker's unreferenced section removal and duplicate section removal optimizations. By default the generation of this table is enabled.
The page range specification on the memory space definition is now exclusive the end address specified. This is now in line with all other range specifications in LSL. The affected page range specification is usually only used in the arch_c166.lsl system LSL file. This LSL file in the product has been updated. In case you copied this LSL file or parts of this LSL file to your project, you must update the LSL file(s) in your project.
To make it easier to configure for the Infineon EasyKit and StarterKit boards the board definitions have been combined. The Target Board Configuration wizard now shows only three base entries:
Each board shows a list of processors to select the actual processor on your board. Existing projects that are configured using one of these boards require some attention:
A new stand-alone debugger program is introduced, additionally to the debugger that is integrated in the Eclipse environment. This script debugger is not a complete debugger; facilities such as a register or a memory window are not available. Instead, its primary purpose is to run scripts created by the user for testing purposes.
More information can be found in the TASKING Script Debugger
User Guide.