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