TASKING VX-toolset for C166 v2.3r1
RELEASE NOTE
This release note covers the TASKING VX-toolset for C166 version 2.3r1. 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.2r5 and v2.3r1:
Summary of changes between v2.2r4 and v2.2r5:
- Solving of reported problem in SFR files.
Summary of changes between v2.2r3 and v2.2r4:
Summary of changes between v2.2r2 and v2.2r3:
- Added initial support for XC2287M-104F and derivatives
- Added support for XC2286M Starter Kit board
- Solving of reported problems
Summary of changes between v2.2r1 and v2.2r2:
- Added support for U Connect XE164F
- Solving of reported problems
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.3r1:
- The behavior of -C, --cpu and --core options has changed. See Dynamic Definition of Processors. This only may affect projects that are not build with Eclipse.
- cc166 now supplies FLASH size information to the LSL file. See Dynamic Definition of Processors. This only may affect projects that are not build with Eclipse.
- The
--static option is not supported by cc166 anymore, it is automatically
supplied to the C compiler when MIL linking. In case you added this
option to Eclipse to the "Additional Options" editbox on the "C/C++
Compiler" -> "Miscellaneous" properties page, it must be removed
from there to avoid build errors.
- The Board Configuration
Wizard or launch configurations must be updated before using the
debugger with an Infineon EasyKit or StarterKit board. See Combined Board Configurations for details.
- Projects that use a local (copy of the) SFR file in the project must be updated to the new SFR file format.
- The
setting of the custom optimization option for branch prediction in
Eclipse had an inverted behavior. This has now been corrected. Projects
that use custom optimization settings should be checked on the correct
setting of this option.
- Eclipse will generate syntax errors on C++ source files. Project properties must be updated as described here.
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.3r1 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.3r1 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.3r1 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
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:
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.
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:
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:
1.39