- Important information
- New features
- Known problems
- Program corrections
- User guide corrections
- Miscellaneous
- Release history
Important information
- Changed C-STAT behaviour in version 7.60
The analysis engine has been improved to increase the analysis precision for both existing and added coding rules. This can have the effect that the number of issued messages for a file or project can differ compared to previous versions of C-STAT, even if the enabled checks are exactly the same.
C-STAT settings in an old IAR Embedded Workbench IDE or Eclipse project will be updated. Some checks will be renamed (they retain their enabled or disabled settings), some checks are removed, and many new checks are added (see above).
Importing settings for C-STAT checks from a file will use the same logic as used when updating the project settings, if the settings file is created with an old version of C-STAT.
-
If you have implemented the
time()
function, you must rename it into__time32()
. For more information see the Development guide. -
The
--guard_calls
command line option is introduced. Note,--guard_calls
must always be used in applications written in EC++/C++ that need thread-safe library function calls. For more information see the Development guide.The
--no_guard_calls
command line option is removed.The
--aeabi
command line option has modified behavior: Guard calls are not used by default.
Migration instructions from IAR C/C++ Compiler for ARM 5.x and 6.10.1 to IAR C/C++ Compiler for ARM 6.10.2:
--aeabi
(without--no_guard_calls
) shall be replaced with--aeabi --guard_calls
--aeabi --no_guard_calls
shall be replaced with--aeabi
-
A special note on CMSIS integration:
If your application source code include CMSIS header files explicitly, then you should not check the Use CMSIS check-box Project>Options...>General Options>Library Configuration>Use CMSIS. Some of the Cortex-M application examples includes CMSIS source files explicitly, do not check the said check-box in these projects.
However, due to the evolution of the IAR C/C++ Compiler for ARM, older versions of CMSIS are incompatible with the current version of the compiler. One simple example of how to solve this issue is:
a) Press F4 to bring up the erroneous source (header) file in the editor - in most cases namedcore_cm3.h
.
b) Right-click on the window tab of that editor window, choose File Properties....
c) Add (or remove) any character to the file name - so the compiler won't find it any more.
d) Modify project options: Check Project>Options...>General Options>Library Configuration>Use CMSIS.
Steps a) to c) might need to be done for more than one file. Normally, the names of these files arecore_cm0.h
,core_cm3.h
,core_cm4.h
,core_cmFunc.h
andcore_cmInstr.h
.
For more information about CMSIS integration in the IAR Embedded Workbench for ARM, see the Development guide. -
The runtime library assumes that unaligned access is allowed when it is available in the architecture
For ARM core architectures where unaligned access is permitted and offers the possibility to generate more efficient code, the runtime library is built to take advantage of this. For example the library for Cortex-M3 assumes that the
UNALIGN_TRP
bit is not set by the embedded application. -
Not using interwork when compiling for ARM architecture v4 is deprecated
For now, this mode is supported like in earlier versions of the product, but new features, like C-RUN, will not have support for this mode.
Deprecated features
-
--use_old_syntax
The compiler option
--use_old_syntax
will be removed in future versions of the IAR C/C++ Compiler for ARM. -
--interwork
Future versions of the IAR C/C++ Compiler for ARM will assume
--interwork
when generating code for the ARMv4T architecture. There will be no option to generate non-interworking code for ARMv4T.
-
New features
-
Initial support for the new ARMv8-M architecture
This release supports both the ARMv8-M Baseline and Mainline implementation. The ARMv8-M architecture is focused on bringing security to applications in the embedded and IoT market.
An example project can be found in the directory<installation path>\arm\src\ARMv8M_Secure
.This is a quick reference to CMSE related extensions that are available but not otherwise documented. We refer to ARM documentation regarding the CMSE programming model, see for example the "ARMv8-M Security Extensions: Requirements on Development Tools".
The extensions below are only available when building for ARMv8-M, baseline (
--cpu 8-M.baseline
) or mainline (--cpu 8-M.mainline
).The CMSE programming model specifies that secure code and non-secure code are built as separate executable files. The level of set-up peformed by the secure code and the location of the entry point to non-secure code is however not specified in the CMSE programming model, so the two executable files must agree on these points in order to interface correctly.
The linker will automatically create a secure gateway veneer for each entry function, as determined by the attribute
__cmse_nonsecure_entry
. These veneers are generated in the sectionVeneer$$CMSE
, which should be placed in a NSC region. Consult the documentation for your ARMv8-M core to determine how to program the SAU (Security Attribute Unit).ICCARM attributes related to CMSE
ATTRIBUTE
__cmse_nonsecure_entry
DESCRIPTION
When building secure code (using--cmse
), use this attribute to declare an entry function to secure mode.
This corresponds to__attribute__((cmse_nonsecure_entry))
in the CMSE programming model.
Parameters or return values located on the stack or in VFP registers are not supported for functions with this attribute.ATTRIBUTE
__cmse_nonsecure_call
DESCRIPTION
When building secure code (using--cmse
), use this attribute for non-secure function calls. This disallows function definitions with this attribute and ensures a secure executable file only contains secure function definitions. This corresponds to__attribute__((cmse_nonsecure_call))
in the CMSE programming model.
Parameters or return values located on the stack or in VFP registers are not supported for functions with this attribute.ICCARM options related to CMSE
OPTION
--cmse
Enable CMSE secure object generation
DESCRIPTION
This option enables support for creating CMSE secure executable files, using the CMSE attributes__cmse_nonsecure_entry
and__cmse_nonsecure_call
. The option--cmse
corresponds to-mcmse
in the CMSE programming model.IASMARM options related to CMSE
OPTION
--cmse
Enable CMSE secure object generation
DESCRIPTION
This option enables the use of instructions that are only available in secure mode.ILINKARM options related to CMSE
OPTION
--import_cmse_lib_out FILE|DIRECTORY
Produce import library for building non-secure image
DESCRIPTION
Use this option when linking a secure image, to create an import library which is then used when linking a corresponding non-secure image. The import library is an object file that consists of a symbol table: each symbol specifies the address of a secure gateway for an entry function of the same name as the symbol.OPTION
--import_cmse_lib_in FILE
Read previous version of import library for building non-secure image
DESCRIPTION
Use this option when updating an import library. Entry functions that exist in the provided import library will be placed at the same address in the updated import library.
Known Problems
-
Assembler file listing containing initializers for a data object that has a type that uses
__packed
or#pragma pack
, is incorrect.
[EW23889] -
MISRA C:2004 rule 9.1 will not find all used uninitialized local variables.
[EW24720] -
The overload resolution algorithm doesn't take into account template user conversion for argument deduction when finding out what built-in operator that is the best fit.
[EW24930] -
Passing a parameter of type
va_list
to a C++ function, where the caller is defined in one object file and the callee in another, will result in a linker error if one of the two objects is built with EWARM 7.20 (or newer) and the other is built with EWARM 7.10 (or older).
[EW25660]
Program Corrections
-
On optimization level High, static variables can be optimized incorrectly, if there are no visible reads from the variable in the translation unit and the address of the variable occurs in the initializer of another variable and the address has been cast to an integer type.
[EW26045] -
Casting a signed character to an unsigned type to a pointer type can trigger an internal error.
[EW26051] -
Internal error when generating VFP code for a multiplication of a
short
by1.0f
converted back toshort
.
[EW26068] -
When compiling for an ARM core with DSP extensions (architectures ARMv7E-M, ARMv5E), an expression of the form
a - ((b * c) >> 32)
wherea
is a 32-bit value andb, c
are 64-bit values, can get the wrong result.
[EW26084] -
The assembler level optimizer could get trapped in a meta-stable state due to a sequencing issue in the flow of control analysis.
[EW26088]
User guide corrections
- None.
Miscellaneous
-
Available workarounds for device erratas:
-
ARM Cortex-M3 errata 463764
Core may freeze forSLEEPONEXIT
single instructionISR
. More information is available on infocenter.arm.com.
Workaround generated for functions with attribute__irq
withiccarm --enable_hardware_workaround=arm463764
. Supported from EWARM 5.41. -
ARM Cortex-M3 errata 602117
LDRD with base in list may result in incorrect base register when interrupted or faulted. From EWARM 5.20.3 the compiler/library avoids the LDRD instruction with the base register in list. -
ARM Cortex-M3 errata 752419
ARM Cortex-M4 errata 752770
Interrupted loads to SP can cause erroneous behaviour. From EWARM 6.21 the compiler/library does not generate LDR SP instructions with writeback to Rn. Otherwise we allow the extra reads since the stack resides in RAM where multiple reads are acceptable. -
ARM Cortex-M7 errata 833872
Flag setting instructions inside IT block might cause incorrect execution of subsequent instructions. From EWARM 7.40 the compiler will the skip the IT transformation on this particular code pattern. -
ARM Cortex-M3 errata 838469
ARM Cortex-M4 errata 838869
Store immediate overlapping exception return operation might vector to incorrect interrupt. The user should follow the guidelines in the errata and implement the workaround proposed by ARM by using __DSB(void) in applicable cases. -
Functional problem Core.1 in NXP device LPC2478: Incorrect update of the Abort Link register in Thumb state.
Workaround generated withiccarm --enable_hardware_workaround=NXP_Core.1
-
Functional problem in Stellaris devices: Non-word-aligned write to SRAM can cause incorrect value to be loaded. More information is available on the Stellaris web site at www.ti.com/stellaris.
Workaround generated withiccarm --enable_hardware_workaround=LM3S_NWA_SRAM_Write
-
Functional problem in Freescale Semiconductors MC9328MX1 (i.MX1), masks 0L44N, 1L44N, and 2L44N:
TheLDM
instruction will in some cases not load the second register correctly. Workaround generated withiccarm --enable_hardware_workaround=920t-ldm2
NOTE: The libraries in the current EWARM version are not built with this workaround. Use EWARM 6.50.6 and linker option--enable_hardware_workaround=920t-ldm2
to use libraries built with this hardware workaround.
-
-
The implementation of
va_args
functions have changed in IAR Embedded Workbench for ARM 7.20.1. It is no longer possible to compile the output of the pre-processor from an earlier version of the compiler. The original source code must be pre-processed again, using IAR Embedded Workbench for ARM 7.20.1.
Release history
-
See release history.