TASKING VX-toolset for C166 v2.2r5
RELEASE NOTE

SUMMARY

This release note covers the TASKING VX-toolset for C166 version 2.2r5. It describes the changes since v2.1r1.

The following sections are included in this release note:
Quick Start
15-day Trial
Device Support
Eclipse
C++ Compiler
C Compiler
Assembler
Linker
Debugger

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:

Summary of changes between v2.1r4 and v2.2r1:

Summary of changes between v2.1r3 and v2.1r4:

Summary of changes between v2.1r2 and v2.1r3:

Summary of changes between v2.1r1 and v2.1r2:

Quick Start

The Eclipse integrated development can be started with the TASKING VX-toolset for C166 shortcut from the start menu. You will be asked to select a workspace. In case you used Eclipse before it is recommended to select a new workspace directory. After clicking OK you will see the Welcome view. From this view you can easily browse to more information or import examples in your workspace. After closing the Welcome view you can also import the examples with File -> Import... -> TASKING C/C++ -> TASKING C166 Example Projects

Recommended initial reading is the Getting Started guide, which can be opened from Eclipse as follows: Help -> Help Contents; the help browser will be opened; now select Getting Started with the TASKING VX-toolset for C166.

15-day Trial

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".

Device Support

Initial Support for XC2361A-68F, XC2268M-56F, XC2286M-72F,XC2786X-104F, XC2267M-104F, XC2287M-104F, XC2365A-72F80L, XC2387A-72F, XC2765X-72F, XC2785X-72F, XE167FM-72F and XE164FM-72F

Initial support has beed added for XC2361A-68F, XC2268M-56F, XC2286M-72F,XC2786X-104F, XC2267M-104F, XC2287M-104F, XC2365A-72F80L, XC2387A-72F, XC2765X-72F, XC2785X-72F, XE167FM-72F and XE164FM-72F. The SFR files are generic and many SFR field and value descriptions are not created. Due to the large number of SFRs added in these devices, the SFR files have grown significantly. This results in more memory usage in Eclipse and compiler. Also reading such large SFR files takes up significant time and the tools may feel slower than with older devices. This will be improved in future releases.

Updated SFR names in SFR files

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 bitfields. The 'old' names will remain available as alias.
For example:

	SCU_SLC = 0xaaaa;

But also still allowed is:

	SLC = 0xaaaa;

Eclipse

The Eclipse platform has been updated to version 3.3, and the Eclipse C Development Tools (CDT) have been updated to version 4.0. This brings in some nice new features, but also some changes to the user interface. Besides these 'common' Eclipse changes also several TASKING specific changes were made. This section gives you an overview of the noteworthy changes in the user interface.

Project Properties

The project properties dialog (Project -> Properties) now has a different tree structure. The C/C++ Build page contains several sub-pages, amongst which the Settings page with the toolset option settings. The processor selection has been moved to a separate Processor page with a tree view to make it easy to select your device between the ever growing number of processors.

Noteworthy changes to the tool settings pages:

Eclipse supports two builders, which can be configured on the C/C++ Build page:

Debug configurations can now also be managed and edited using the Project -> Properties -> Run/Debug Settings page.

Updated Editors

C/C++ editor improvements:

Updates to the LSL Editor:

Updates to the map file viewer:

New and Updated Views

Miscellaneous

C++ Compiler

STLPort IO-stream Libraries

The STLPort io-stream libraries are included for all data models. When you want to use the io-stream libraries and you are using single precision float (-F option) or the user-stack model (--user-stack option) you will have to build these libraries from the sources. See the User Guide Chapter 11 for more information on building these libraries.

C Compiler

Application Wide Compilation: MIL Linking

MIL Linking

The C compiler frontend always produces an intermediate representation of the translated C file(s). This intermediate code, called MIL (Medium level Intermediate Language), is normally stored in memory and from there directly processed by the backend. With the compiler options --mil and --mil-split, the MIL code is written into a file. When this file is fed again to the compiler, only the backend will be executed to produce assembly code. When passing all MIL files of your application at once to the compiler it will link these files and produce a single assembly source file. This process is called MIL Linking.

The advantage of MIL linking is that the compiler has an application wide scope and can perform application wide checks and optimizations, such as inlining and code compaction. Because the backend now always compiles the whole application at once, the compilation process will take more time if only few modules are changed. To reduce this disadvantage to a minimum, the compiler supports the --mil-split option. When supplying this option the compiler will perform MIL linking of all input files, and then splits the linked MIL code into multiple intermediate files, one per input file. If an existing MIL file exists, the compiler will only overwrite it if the result would be different. This effectively allows a builder tool, such as make, to run the backend only on MIL files that have actually changed.

Because the linked MIL stream of the whole application is split into modules after MIL linking, it is possible that a modification in one module requires multiple MIL files to be updated. A simple example is a function that inlined by the compiler in multiple locations spread over multiple files. When modifying this function all files where it is inlined must be build again.

MIL Archives

The compiler can link libraries of MIL files, called MIL archives. The filename suffix of MIL archives is .ma. The C libraries are included as MIL archives in the same variants as the object library versions. MIL archives can be created with the archiver, ar166, included in the product.

Eclipse

In Eclipse you can enable MIL linking as follows:

  1. Open the Project -> Properties dialog.
  2. Select Global Options.
  3. Enable the option Link the MIL representation of all modules.

MIL linking can only be enabled when the external builder is used.

Build process

The build process as used by Eclipse is as follows:

  1. Pass all C files of the project to the C compiler and produce MIL files with the --mil-split option. The MIL files get the suffix .ms. The C libraries are linked as a MIL archive (.ma).
  2. Compile each MIL file (.ms) to an object file (.obj).
  3. Compile the C library MIL file to an object file.
  4. Link all object files to an absolute ELF file with the linker. The system libraries (C library, runtime library and floating point runtime library) still must be supplied to the linker.

Static Profiling

When enabling static profiling the compiler will generate profile information through various heuristics and estimates. Static profiling can give you a reasonable impression of te critical parts of the application and does not require any run-time resources, but it is less accurate than dynamic profiling.

See the User Guide, section 6.3. Profiling at Compile Time (Static Profiling) for more information on static profiling.

Changed Section Names

The default compiler section naming convention is changed to {name}_{type} to make it easier to find a section in the map file. The {name} is the name of the C level object (variable or function name) and the {type} is te memory type of the section (bit, bita, near, far, shuge, huge, code). If your project's LSL file relies on the section names as generated in previous versions, you can change the section naming with the --rename-sections={type} C compiler option. Or in Eclipse, goto Project -> Properties -> Settings -> C/C++ Compiler -> Allocation, and add an item {name} to the Rename sections list

Alignment of char Arrays Changed to Byte Aligment

Arrays of the type char are now aligned at a single byte. In previous versions the word alignment could cause problems when code relied on struct field alignment as used in the classic toolset. With this change, the alignment of struct members is now equal to the classic toolset. This change may result in a small decrease of execution speed when copying char arrays from or to the stack, because this will now be done per byte instead of per word.

Clearing of Global and Static Bit Variables

A new option is added:

--no-clear-bit
Don't clear non-initialized global/static bit variables. This option is the same as --no-clear, except that it only applies to __bit variables.

New pragmas:

#pragma clear_bit
Performs 'clearing' of non-initialized global/static bit variables.
#pragma noclear_bit
Performs no 'clearing' of non-initialized global/static bit variables.

Controlling Stack Conversion

A new option is added:

--stack-address-conversion=mode
Control how stack addresses are converted to __far and __(s)huge addresses:

New pragma:

#pragma stack_address_conversion
Control how stack addresses are converted. Same as compiler option: --stack-address-conversion.

Examples:

__far int *fp;
void foo( void )
{
	int arr[100];
	fp = &arr[10];
	.
	.
	.
}

The code generation for the three variants for the line:

	fp = &arr[10];

With static:

	movw	r11,#0x14
	addw	r11,r15
	movw	r12,#@pag(__lc_ub_user_stack+0xffff)
	movw	_fp,r11
	movw	_fp+0x2,r12

With fixed-dpp:

	movw	r11,#0x14
	addw	r11,r15
	movw	r12,@dpp(__lc_ub_user_stack+0xffff)
	movw	_fp,r11
	movw	_fp+0x2,r12

With dynamic:

	movw	r11,#0x14
	addw	r11,r15
	movw	r12,r11
	shr	r12,#0xe
	shl	r12,#0x1
	addw	r12,#0xfe00
	movw	r12,[r12]
	movw	_fp,r11
	movw	_fp+0x2,r12

With the static setting the DPP that is used for the stack can only be loaded with the page number at startup. With the fixed-dpp or dynamic setting it is possible to change the DPP contents dynamically afterwards. This can be useful in for example an RTOS that uses a separate page for each task's stack.

SFR Byte-Write Problems

In versions prior to v2.1r4 the compiler optimizes a write of an integer or integer bit-field that would only change one of the bytes in the integer to a byte-write operation. This also applies to SFR bitfield writes, but this is not allowed because this clears the complementary byte in the SFR word.

Generated Register Bank Names Get _$ Prefix

The register bank name generated for the __registerbank() qualifier now get prefixed with _$ instead of __ (two underscores).
Example:

void __interupt(-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.

float.h Split Into float.h and fpbits.h

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.

Assembler

$ Allowed in Identifiers

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

Linker

Changed system LSL files

The common derivative definition is moved from the arch_*.lsl files to the derivative lsl files. The moved defition includes the core and bus defition and the reserved memories for the SFR areas. In case you copied the derivative lsl file (e.g., xc167ci.lsl) to your project before you will get a linker error: 

E821: syntax error: base derivative common_core not found for derivative derivative

To fix this, copy the new derivative lsl file from the system directory and make apply your changes to the memories again.

This change has been made to make it easier to move all memories, including the SFR areas to the project. The LSL editor in Eclipse has a feature to copy the derivative LSL file to your project.

Paging Behavior of LSL Changed

In versions prior to v2.1r3, a section lost all page attributes as soon as it was selected with a group...select statement in LSL. It was assumed that the user respected the page restrictions with the new group attributes. In practice this was often forgotten, leading to unexpected problems in the application. Therefore the linker now keeps the section's page restrictions. This may lead to some problems in existing LSL files, where sections are located explicitly on or over a page boundary. When locating a near, far or shuge section exactly at a page start, the linker does not allow that because the first byte of each page is reserved to avoid NULL pointer problems. But in case you know that these problems won't occur with the section that you want to put there, it is possible to overrule the page attributes by adding the page_size=0 and page attributes to the group definition.

Example:

group ( ordered, load_addr = 0xC10000, page_size = 0, page )
{
	select "somesection";
}

New copy Attribute in LSL for vector_table

To make it possible to create a copy of the vector table in LSL, the vector_table statement is extended with the copy attribute. When this attribute is specified the linker makes a ROM copy of the vector table that is copied to the run-time address at startup. The linker creates entries in the copytable for this.

Example:

vector_table "vector_table" ( run_addr = mem:spe:PSRAM[0], vector_size = 4, size = 128,
				template="__vector_template", template_symbol="__lc_vector_target",
				vector_prefix=".vector.", fill=loop, copy)

Change in LSL Editor Reserved Page

The LSL editor now generates reserve statements for reserved ranges. For example:

section_setup ::code
{
    reserved 0x4000 .. 0x7fff;
}

Using __DTC_IGNORE to Avoid Update by Target Board Configuration Wizard

In Eclipse the Project -> Target Board Configuration wizard by default updates the LSL file in your project. If you don't want that to happen, just define the macro __DTC_IGNORE in the LSL file:

#define __DTC_IGNORE

Debugger

Infineon EasyKit Boards and Wigglers

This version of the TASKING VX-toolset for C166 installs DAS v2.6.2. This enables the support for the new Infineon evaluation boards and the onboard USB wiggler and the Infineon miniWiggler II. To select these wigglers in the TASKING debugger, you should use the Target Board Configuration (Project menu). First select the target board and then select the appropriate wiggler from the "Communication" list.

The DAS parallel port drivers have been updated to v2.4.0 in this version.

1.33