Mbed-os: Multiple Targets does not build with IAR8.2

Created on 25 Oct 2017  路  10Comments  路  Source: ARMmbed/mbed-os

Description

  • Type: Bug
  • Priority: Major

Bug

Target
NUCLEO_F429ZI,
B96B_F446VE,
DISCO_F413ZH,
DISCO_F429ZI,
DISCO_F469NI,
DISCO_F746NG,
DISCO_F769NI,
DISCO_L475VG_IOT01A,
DISCO_L476VG,
MTS_DRAGONFLY_F411RE,
MTS_MDOT_F411RE,
NUCLEO_F207ZG,
NUCLEO_F303RE,
NUCLEO_F303ZE,
NUCLEO_F401RE,
NUCLEO_F410RB,
NUCLEO_F411RE,
NUCLEO_F412ZG,
NUCLEO_F429ZI,
NUCLEO_F439ZI,
NUCLEO_F446RE,
NUCLEO_F446ZE,
NUCLEO_F746ZG,
NUCLEO_F756ZG,
NUCLEO_F767ZI,
NUCLEO_L432KC,
NUCLEO_L476RG,
NUCLEO_L486RG,
UBLOX_C030_N211,
UBLOX_C030_U201,
UBLOX_EVK_ODIN_W2,

Toolchain:
IAR

Toolchain version:
IAR ANSI C/C++ Compiler V8.20.1.57/LNX for ARM

Expected behavior
Code compiles

Actual behavior

mbed compile -t IAR -m NUCLEO_F429ZI

00:01:56.716 Compile [  1.8%]: BufferedSerial.cpp
00:01:56.716 
[Error] stm32f4xx_hal_def.h@132,30: [Pe167]: argument of type "unsigned long volatile *" is incompatible with parameter of type "unsigned int const volatile *"
00:01:56.716 [Error] stm32f4xx_hal_def.h@134,34: [Pe167]: argument of type "unsigned long volatile *" is incompatible with parameter of type "unsigned int volatile *"
00:01:56.716 [Error] stm32f4xx_hal_def.h@142,30: [Pe167]: argument of type "unsigned long volatile *" is incompatible with parameter of type "unsigned int const volatile *"
00:01:56.716 [Error] stm32f4xx_hal_def.h@144,0: [Pe167]: argument of type "unsigned long volatile *" is incompatible with parameter of type "unsigned int volatile *"
00:01:57.250 [ERROR] 
00:01:57.250        newValue = (uint32_t)__LDREXW((volatile unsigned long *)ptr) | mask;
00:01:57.250                                      ^
00:01:57.250 "app/mbed-os/targets/TARGET_STM/TARGET_STM32F4/device/stm32f4xx_hal_def.h",132  Error[Pe167]: argument of type "unsigned long volatile *" is incompatible with parameter of type "unsigned int const volatile *"
00:01:57.250 
00:01:57.250    } while (__STREXW(newValue,(volatile unsigned long*) ptr));
00:01:57.250                               ^
00:01:57.250 "app/mbed-os/targets/TARGET_STM/TARGET_STM32F4/device/stm32f4xx_hal_def.h",134  Error[Pe167]: argument of type "unsigned long volatile *" is incompatible with parameter of type "unsigned int volatile *"
00:01:57.250 
00:01:57.250        newValue = (uint32_t)__LDREXW((volatile unsigned long *)ptr) &~mask;
00:01:57.250                                      ^
00:01:57.250 "app/mbed-os/targets/TARGET_STM/TARGET_STM32F4/device/stm32f4xx_hal_def.h",142  Error[Pe167]: argument of type "unsigned long volatile *" is incompatible with parameter of type "unsigned int const volatile *"
00:01:57.250 
00:01:57.250    } while (__STREXW(newValue,(volatile unsigned long*) ptr));
00:01:57.250                               ^
00:01:57.250 "app/mbed-os/targets/TARGET_STM/TARGET_STM32F4/device/stm32f4xx_hal_def.h",144  Error[Pe167]: argument of type "unsigned long volatile *" is incompatible with parameter of type "unsigned int volatile *"
closed_in_jira mirrored bug

All 10 comments

cc @deepikabhavnani This was reported in IAR8 PR I believe, the same report, but for ODIN device.

This looks like STM32F4 problem in the hal.

cc @bcostm @adustm @LMESTM @jeromecoutant

__LDREXW, __STREXW and many other defines are update in 8.2 version "arm/inc/c/cmsis_iar.h"

FYI, Pull request for IAR8 fixes should be against branch feature-iar8, CI testing for IAR8.2 will be enabled for only feature branch.

__LDREXW, __STREXW and many other defines are update in 8.2 version "arm/inc/c/cmsis_iar.h"

Can you include those definitions here for comparision (v7 vs v8) ? The latest cmsis5 versions have this cmsis_iar already included, see here https://github.com/ARM-software/CMSIS_5/blob/develop/CMSIS/Core/Include/cmsis_iccarm.h (does this headerfile match regarding this macros update) ? Not certain which one is valid for these targets (either intrisict from iar built in or implementation provided there) ?

Is this bug in IAR header file (they should provide backward compatible macros, or have a strong reason to break this) ?

@JonatanAntoni might know more details

Definition in IAR7.8

static uint32_t __LDREXW(volatile uint32_t *addr)
{
  __ASM("ldrex r0, [r0]");
}

Replaced in IAR8.2 with builtin define
#define __LDREXW __iar_builtin_LDREX

Added fix commit d6da5ca197909445285cf392ee6b4002aa1482aa in https://github.com/ARMmbed/mbed-os/pull/5329

Hi all,

please note that there is a compiler specific version of cmsis_iar.h shipped with the IAR installation. I assume this one to be in sync with the compiler all the time. But a version shipped with 8.2 should not be assumed to be backward compatible with 7.8. I.e. it looks like new intrinsics have been added to 8.2. which are not available in 7.8. The API offered by both versions should be compatible nevertheless.

Shipping this file as part of the IAR installation turned out to be hardly maintainable. I.e. pushing an update to CMSIS to all IAR installations under maintenance needed a patch release for all of them. Thus we decided to move this header to the CMSIS pack and maintain it together at GitHub. To prevent a name clash we renamed the header to cmsis_iccarm.h. This one should provide definitions for all compilers under maintenance. In case of LDREXW/STREXW there are two definitions depending on the __ICCARM_INTRINSICS_VERSION__ the compiler offers.

Please let me know if the latest version of this header shipped with the CMSIS Pack does not work for you.

Cheers,
Jonatan

ARM Internal Ref: MBOTRIAGE-143

Closing this since IAR 8 is not currently supported.

Just a remark: IAR 8 is the latest release which is under active support. With IAR 7.8 you cannot presume to get anything fixed. Nevertheless, as stated above, please raise issues at CMSIS and we'll check what we can do to keep the compatibility as best as we can.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

cesarvandevelde picture cesarvandevelde  路  4Comments

bcostm picture bcostm  路  4Comments

0xc0170 picture 0xc0170  路  3Comments

DuyTrandeLion picture DuyTrandeLion  路  3Comments

ccchang12 picture ccchang12  路  4Comments