This release note covers the changes between v2.0r1 and v3.0r3 of the TASKING VX-toolset for ARM.
Before you start using this toolset, please read the Getting Started with the TASKING VX-toolset for ARM documentation to become familiar with Eclipse and the debugger
The ARMv7-M architecture profile implements the Thumb-2 instruction set. Besides some new 16-bit Thumb instructions it introduces 32-bit Thumb instructions and an IT instruction for conditional execution. This makes the Thumb-2 instruction set almost as powerful as the 32-bit ARM instruction set. The 32-bit Thumb-2 instructions can be executed in Thumb state and need only be half-word aligned in memory. The IT instruction (If/Then) sets the conditions for up to four instructions following the IT instruction. For a number of Thumb-2 instructions both 16-bit encoding as well as 32-bit encoding exist. The assembler selects the proper encoding for such an instruction, although in some situations you can force the selection of a specific encoding.
With the Thumb-2 instruction set ARM Ltd introduced the Unified Assembly Language (UAL) which provides a canonical form for all ARM and Thumb instructions. The UAL allows you to write assembly code which can be assembled using 32-bit ARM instructions or using 16-bit and 32-bit Thumb-2 instructions. This means that you can use IT instructions followed by a block of up to four conditional instructions in both ARM and Thumb-2 code. The assembler checks for consistency between the two, and assembles the appropriate code depending on the current instruction set.
With version v2.0r1 the C compiler generates UAL code for all architectures.
With version v2.0r2 the C++ compiler option --instantiate=none became obsolete. This lacks the need of a Prelinker, so this utility is no longer part of the tools.
The compiler has been extended with new intrinsic functions to support the Cortex Micro-controller Software Interface Standard (CMSIS). CMSIS V1.20 and higher include support for the TASKING VX-toolset for ARM. The following functions defined in the CMSIS are supported by the compiler as intrinsic functions and do therefore not have any implementation in the CMIS header files core_cm0.h and core_cm3.h:
| Intrinsic Function Name | Description |
|---|---|
| void volatile __enable_irq(void); | Global Interrupt enable (using the instruction CPSIE i) |
| void volatile __disable_irq(void); | Global Interrupt disable (using the instruction CPSID i) |
| void volatile __set_PRIMASK(unsigned int value); | Assign value to Priority Mask Register (using the instruction MSR) |
| unsigned int __get_PRIMASK(void); | Return Priority Mask Register (using the instruction MRS) |
| void volatile __enable_fault_irq(void); | Global Fault exception and Interrupt enable (using the instruction CPSIE f) |
| void volatile __disable_fault_irq(void); | Global Fault exception and Interrupt disable (using the instruction CPSID f) |
| void volatile __set_FAULTMASK(unsigned int value); | Assign value to Fault Mask Register (using the instruction MSR) |
| unsigned int __get_FAULTMASK(void); | Return Fault Mask Register (using the instruction MRS) |
| void volatile __set_BASEPRI(unsigned int value); | Set Base Priority (using the instruction MSR) |
| unsigned int __get_BASEPRI(void); | Return Base Priority (using the instruction MRS) |
| void volatile __set_CONTROL(unsigned int value); | Set CONTROL register value (using the instruction MSR) |
| unsigned int __get_CONTROL(void); | Return Control Register Value (using the instruction MRS) |
| void volatile __set_PSP(unsigned int value); | Set Process Stack Pointer value (using the instruction MSR) |
| unsigned int __get_PSP(void); | Return Process Stack Pointer (using the instruction MRS) |
| void volatile __set_MSP(unsigned int value); | Set Main Stack Pointer (using the instruction MSR) |
| unsigned int __get_MSP(void); | Return Main Stack Pointer (using the instruction MRS) |
| void volatile __WFI(void); | Wait for Interrupt |
| void volatile __WFE(void); | Wait for Event |
| void volatile __SEV(void); | Set Event |
| void volatile __ISB(void); | Instruction Synchronization Barrier |
| void volatile __DSB(void); | Data Synchronization Barrier |
| void volatile __DMB(void); | Data Memory Barrier |
| unsigned int __REV(unsigned int value); | Reverse byte order in integer value |
| unsigned int __REV16(unsigned short value); | Reverse byte order in unsigned short value |
| signed int __REVSH(signed int value); | Reverse byte order in signed short value with sign extension to integer |
| unsigned int __RBIT(unsigned int value); | Reverse bit order of value |
| unsigned volatile char __LDREXB(unsigned char *addr); | Load exclusive byte |
| unsigned volatile short __LDREXH(unsigned short *addr); | Load exclusive half-word |
| unsigned int volatile __LDREXW(unsigned int *addr); | Load exclusive word |
| unsigned int volatile __STREXB(unsigned char value, unsigned char *addr); | Store exclusive byte |
| unsigned int volatile __STREXH(unsigned short value, unsigned short *addr); | Store exclusive half-word |
| unsigned int volatile __STREXW(unsigned int value, unsigned int *addr); | Store exclusive word |
| void volatile __CLREX(void); | Remove the exclusive lock created by __LDREXB, __LDREXH, or __LDREXW |
New linker script (LSL) files are added to the product's include.lsl directory for support of the interrupt vectors as defined by CMSIS:
For building a project using CMSIS, use header files and C modules from the standard CMSIS zip file. For using the standard CMSIS interrupt vectors you must include the appropriate LSL file in your project's LSL file.
The C and C++ compiler now support the following pragmas:
| Pragma | Description |
|---|---|
| section_code_init | Copy code sections from ROM to RAM at application startup. |
| section_no_code_init | Don't copy code sections from ROM to RAM. |
| section_const_init | Copy read-only data sections from ROM to RAM at application startup. |
| section_no_const_init | Don't copy read-only-data sections from ROM to RAM. |
| Pragma | Description |
|---|---|
| smart_switch | The C compiler supports two ways of code
generation for a switch statement: a jump chain (linear switch) or a jump
table. By default, the compiler tries to use the switch method which uses the least space in ROM (i.e. table size in ROMDATA plus code to do the indexing). For a switch with a long type argument, only linear code is used. For an int type argument, a jump table switch is only used when the table of cases is not too sparse. It is obvious that, especially for large switch statements, the jump table approach executes faster than the binary search table approach. Also the jump table has a predictable behavior in execution speed. No matter the switch argument, every case is reached in the same execution time. With a small number of cases, the jump chain method can be faster in execution and shorter in size. For ARMv7M a switch using the tbh instruction gets priority over a normal switch table implementation. |
| jump_switch | A jump table is a table filled with jump labels for each possible switch value. The switch argument is used as an index to jump using labels within this table. |
| linear_switch | A jump chain is comparable with an if/else-if/else-if/else construction. |
| binary_switch | A binary search table is a table filled with a value to compare the switch argument with and a target address to jump to. This is currently not supported. |
| tbb_switch | Force usage of tbb instruction. Uses a table of 8-bit jump offsets. |
| tbh_switch | Force usage of tbh instruction. Uses a table of 16-bit jump offsets. |
| no_tbh_switch | As smart_switch, but don't use tbh instruction. |
The assembler supports the pseudo-instructions defined by ARM RVCT v3.0 tools (except the ADRL pseudo-instruction for Thumb-2), and the canonical forms for POP, PUSH, LSL, LSR, ASR, ROR and RRX instructions, .
For Thumb-2 the assembler only accepts the condition code as the last element of any mnemonic. For ARM the assembler accepts infix condition code, but only if --old-syntax option or .code32 directive is used.
The assembler only supports the UAL syntax for VFP instructions.
With the option --relaxed the assembler accepts 2-operand versions of 3-operand instructions when the first and second operand are a destination and a source register and the same register is used for both. E.g. 'add r1,r1,r3' may be written as 'add r1,r3' and 'add r1,r1,#4' may be written as 'add r1,#4'.
You should not add 1 to Thumb label expressions in literal pools or data sections. This will be taken care of automatically by the assembler and the linker.
The linker automatically generates ARM-Thumb interworking veneers when needed. This release always creates a long veneer, i.e. short veneers and inline veneers are not used. Veneer symbol names do not follow the convention proposed by the EABI (not mandatory).
The linker does not generate long-branch veneers for out-of-range function calls by default. You can enable this feature with option --long-branch-veneers, but use it with care. The option slows down the linking process considerably and it can lead to larger code size even when veneers are not needed after all. It is better to prevent long branches and only use this option when long branches are out of range.
The ARMv6-M architecture profile has no support for veneers. Use compiler option --call to force far 32-bit indirect calls or near 26-bit PC-relative calls.
The vector statement in the linker LSL file has a new attribute: optional. When using this attribute when the value is a symbol, no error will be reported when the symbol is not found. Instead a standard symbol specified by vector_prefix is looked up, and if that is not found either, a default value will be used, if specified. For other values the new attribute is ignored.
This feature allows standard vectors to be defined even when they are not used, like required for CMSIS.
Since version 3.0r1, the Eclipse Ganymede platform is used as Integrated Development Environment (IDE)
All product libraries are suitable for ARM-Thumb interworking. None of the libraries are optimized for VFP.
The startup code for ARM and Thumb included in the C library (carm.lib & cthumb.lib) provides basic functionality: it initializes the separate stack pointers for each processor mode, copies global data from ROM to RAM, calls the application's main function and calls the exit function upon return from main. It does not do any hardware initialization. You may contact Altium Support for assistance on hardware-specific issues pertaining to the use of the TASKING VX-toolset.
The new TASKING Debugger is integrated in the Eclipse environment.
The list of open issues for v3.0r3 can be found on the internet.
The list of open issues for v3.0r2 can be found on the internet.
The list of open issues for v3.0r1 can be found on the internet.
The list of open issues for v2.0r3 can be found on the internet.
The list of open issues for v2.0r2 can be found on the internet.
The CMSIS integration as described above is not yet documented in the User Guide.
When you use the product without a valid license, the tools will first run in trial mode.
This means that you can use the toolset for 15 days with full functionality. After the trial
period has expired, parts of the toolset may switch to evaluation mode. The evaluation
mode has the following restrictions:
| Part | Evaluation Restrictions |
|---|---|
| C++ Compiler | Not part of the evaluation version |
| C Compiler | Maximum of 700 statements within the function bodies Limited number of symbols |
| Assembler | Maximum of 2000 assembly instructions Limited number of symbols Code size limited to 5k bytes |
| Linker | Code size limited to 10k bytes |
| Debugger | Not part of the evaluation version |
When you use a license that does not cover the full toolset, only the tools which are not covered by the license will run in trial/evaluation mode.
Tools running in trial/evaluation mode emit an informational message. If, after installing a valid license file, the tools which are covered by the license still emit this message, then there is a license error. Use command line option -V to get the actual FLEXlm license error message. You may also force termination of trial or evaluation mode by setting the environment variable FORCE_NO_TRIAL to "yes".
All TASKING products include the industry standard FLEXlm license management software. In order to be able to run this toolset, you will need a license key, although you can use the full functionality during the 15 day trial period as described above. You can only obtain a license key if you have purchased this product.
To obtain a license key, you can start the License Administrator from the program group of your installed
TASKING toolset. In case you still need to install the toolset, you can start the License Administrator by
setting a check mark at the end of the setup/installation process. The wizard of the License Administrator
will guide you through the steps to obtain your license key.
Once you have received your license key from Altium, you can install it on your system by running the License
Administrator again. Alternatively you can simply save the license key as the file 'license.dat' in the
C:\FLEXLM folder on your PCs hard disk.
More information is available on http://www.tasking.com/support/flexlm. On this page you also find assistance to setup a floating network license, or for installation on Linux or Sun systems.