This release note covers the TASKING VX-toolset for C166 version 2.1r3. It describes the changes since v2.1r1.
The following sections are included in this release note:
Importing Projects From v2.1r1 or Older
Quick Start
Licensing Issues
C++ Compiler
C Compiler
Linker
Debugger
Summary of changes between v2.1r2 and v2.1r3:
Summary of changes between v2.1r1 and v2.1r2:
Solved and known problems are listed in a separate file, delivered with the product.
IMPORTANT NOTE: Moving from version v2.1r1 or older to version v2.1r3 requires to create your project(s) again:
This way of importing a project is necessary because since v2.1r2 the option IDs as written in the project files are all changed to avoid conflicts with other toolsets that use the Eclipse CDT. Migrating from v2.1r3 to a future release will not need this kind of import.
For a quick start, just start the "TASKING VX-toolset for C166" from the start menu. This will start the Eclipse based development environment. You will be asked to select a workspace. In case you used Eclipse before it is recommended to select a new workspace. After clicking OK you will see the "Welcome" view. On this view you will see icons that link to specific information.
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 this. 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".
With version 2.1r3 the STLPort io-stream libraries are included for all data models. When you want to use the io-stream libraries when 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.
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.
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 (note that is one byte bigger than with static):
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.
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. Therefor 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"; }
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)
The LSL editor now generates reserve statements for reserved ranges. For example:
section_setup ::code { reserved 0x4000 .. 0x7fff; }
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
This version of the TASKING VX-toolset for C166 installs DAS v2.5.1. This enables the support for the new Infineon XC164CS EasyKit board's 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.