H755ZI. Selected processor does not support 'isb 0xF' in ARM mode
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-11-07 5:58 AM
Hi,
I'm trying to compile the BSP example project from the H7 FW package, and I keep getting these error messages:
Scanning dependencies of target Demo_M4_Single.elf
[ 4%] Building C object CMakeFiles/Demo_M4_Single.elf.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_cortex.c.obj
[ 9%] Building C object CMakeFiles/Demo_M4_Single.elf.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_flash.c.obj
[ 13%] Building C object CMakeFiles/Demo_M4_Single.elf.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_flash_ex.c.obj
[ 18%] Building C object CMakeFiles/Demo_M4_Single.elf.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_gpio.c.obj
C:\Users\ton\AppData\Local\Temp\ccxCvotZ.s: Assembler messages:
C:\Users\ton\AppData\Local\Temp\ccxCvotZ.s:118: Error: selected processor does not support `isb 0xF' in ARM mode
C:\Users\ton\AppData\Local\Temp\ccxCvotZ.s:129: Error: selected processor does not support `dsb 0xF' in ARM mode
C:\Users\ton\AppData\Local\Temp\ccxCvotZ.s:162: Error: selected processor does not support `isb 0xF' in ARM mode
C:\Users\ton\AppData\Local\Temp\ccxCvotZ.s:173: Error: selected processor does not support `dsb 0xF' in ARM mode
C:\Users\ton\AppData\Local\Temp\ccxCvotZ.s:360: Error: selected processor does not support `isb 0xF' in ARM mode
C:\Users\ton\AppData\Local\Temp\ccxCvotZ.s:371: Error: selected processor does not support `dsb 0xF' in ARM mode
C:\Users\ton\AppData\Local\Temp\ccxCvotZ.s:404: Error: selected processor does not support `isb 0xF' in ARM mode
C:\Users\ton\AppData\Local\Temp\ccxCvotZ.s:415: Error: selected processor does not support `dsb 0xF' in ARM mode
mingw32-make.exe[3]: *** [CMakeFiles/Demo_M4_Single.elf.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_flash.c.obj] Error 1
mingw32-make.exe[3]: *** Waiting for unfinished jobs....
CMakeFiles\Demo_M4_Single.elf.dir\build.make:165: recipe for target 'CMakeFiles/Demo_M4_Single.elf.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_flash.c.obj' failed
C:\Users\ton\AppData\Local\Temp\ccFiuVRY.s: Assembler messages:
C:\Users\ton\AppData\Local\Temp\ccFiuVRY.s:211: Error: selected processor does not support `dsb 0xF' in ARM mode
C:\Users\ton\AppData\Local\Temp\ccFiuVRY.s:222: Error: selected processor does not support `isb 0xF' in ARM mode
C:\Users\ton\AppData\Local\Temp\ccFiuVRY.s:773: Error: selected processor does not support `dsb 0xF' in ARM mode
C:\Users\ton\AppData\Local\Temp\ccFiuVRY.s:793: Error: selected processor does not support `dsb 0xF' in ARM mode
C:\Users\ton\AppData\Local\Temp\ccFiuVRY.s:1134: Error: selected processor does not support `dmb 0xF' in ARM mode
C:\Users\ton\AppData\Local\Temp\ccFiuVRY.s:1204: Error: selected processor does not support `dsb 0xF' in ARM mode
C:\Users\ton\AppData\Local\Temp\ccFiuVRY.s:1215: Error: selected processor does not support `isb 0xF' in ARM mode
CMakeFiles\Demo_M4_Single.elf.dir\build.make:139: recipe for target 'CMakeFiles/Demo_M4_Single.elf.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_cortex.c.obj' failed
mingw32-make.exe[3]: *** [CMakeFiles/Demo_M4_Single.elf.dir/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_cortex.c.obj] Error 1
CMakeFiles\Makefile2:74: recipe for target 'CMakeFiles/Demo_M4_Single.elf.dir/all' failed
CMakeFiles\Makefile2:81: recipe for target 'CMakeFiles/Demo_M4_Single.elf.dir/rule' failed
mingw32-make.exe[2]: *** [CMakeFiles/Demo_M4_Single.elf.dir/all] Error 2
mingw32-make.exe[1]: *** [CMakeFiles/Demo_M4_Single.elf.dir/rule] Error 2
mingw32-make.exe: *** [Demo_M4_Single.elf] Error 2
Makefile:117: recipe for target 'Demo_M4_Single.elf' failed
I don't get these error messages when I'm using STM32CubeIDE, so there must be something off in my configuration. But I don't have any idea where to look for the answer, I know some of the commands are related to memory barriers in MPU and some are assembly commands for wait for interrupt (this one does not show above).
I have double checked the configurations etc (so I shouldn't missing any flags), but this still happens.
SET(CMAKE_SYSTEM_NAME Generic)
SET(CMAKE_SYSTEM_VERSION 1)
cmake_minimum_required(VERSION 3.15)
project(Demo_M4_Single C CXX ASM)
SET(TRUE 1)
SET(FALSE 0)
SET(LOCAL_ARM_TOOLCHAIN C:/GNU-Tools-Arm-Embedded/7-2018-q2-update)
SET(H7_FW_PATH C:/Users/ton/STM32Cube/Repository/STM32Cube_FW_H7_V1.5.0)
# Specify cross compilers and tools
SET(CMAKE_C_COMPILER_WORKS 1)
SET(CMAKE_C_COMPILER arm-none-eabi-gcc)
SET(CMAKE_CXX_COMPILER_WORKS 1)
SET(CMAKE_CXX_COMPILER arm-none-eabi-g++)
SET(CMAKE_ASM_COMPILER arm-none-eabi-gcc)
SET(CMAKE_AR arm-none-eabi-ar)
SET(CMAKE_OBJCOPY arm-none-eabi-objcopy)
SET(CMAKE_OBJDUMP arm-none-eabi-objdump)
SET(SIZE arm-none-eabi-size)
SET(linkerScript stm32h755xx_flash_CM4.ld)
SET(LINKER_SCRIPT ${CMAKE_SOURCE_DIR}/${linkerScript})
# Uncomment for hardware accelerated floating point calculation
SET(FPU_FLAGS "-mfloat-abi=hard -mfpu=fpv4-sp-d16")
add_definitions(-DARM_MATH_CM4 -DARM_MATH_MATRIX_CHECK -DARM_MATH_ROUNDING -D__FPU_PRESENT=1
-DUSE_HAL_DRIVER
-DSTM32H755xx # Defining the board
-DCORE_CM4 # Define the Core we are buiding for
-DUSE_STM32H7XX_NUCLEO_144_MB1363
)
# Uncomment for software floating point calculation
#SET(FPU_FLAGS "-mfloat-abi=soft")
SET(COMMON_FLAGS
"-mcpu=cortex-m4 ${FPU_FLAGS} -mthumb -mthumb-interwork -ffunction-sections -fdata-sections \
-g -fno-common -fmessage-length=0 ${linkerFlags}")
SET(CMAKE_CXX_FLAGS_INIT "${COMMON_FLAGS} -std=c++11")
SET(CMAKE_C_FLAGS_INIT "${COMMON_FLAGS} -std=gnu11")
SET(CMAKE_EXE_LINKER_FLAGS_INIT "-Wl,-gc-sections,--print-memory-usage -T $${LINKER_SCRIPT}")
# Add resources files to the project
file(GLOB_RECURSE SOURCES
#${PROJECT_SOURCE_DIR}/main.c
${PROJECT_SOURCE_DIR}/CM4/Src/*.*
${PROJECT_SOURCE_DIR}/Common/Src/*.*
${PROJECT_SOURCE_DIR}/Drivers/STM32H7xx_HAL_Driver/Src/*.*
${PROJECT_SOURCE_DIR}/startup/*.*
)
# Include Directories to the project
include_directories(
${LOCAL_ARM_TOOLCHAIN}/arm-none-eabi/include
${H7_FW_PATH}/Drivers/BSP/Components/Common
${H7_FW_PATH}/Drivers/BSP/Components/st7735
${H7_FW_PATH}/Drivers/BSP/STM32H7xx_Nucleo_144
${H7_FW_PATH}/Drivers/CMSIS/Device/ST/STM32H7xx/Include
${H7_FW_PATH}/Drivers/CMSIS/Include
${H7_FW_PATH}/Drivers/STM32H7xx_HAL_Driver/Inc
${PROJECT_SOURCE_DIR}/CM4/Inc
${PROJECT_SOURCE_DIR}/Drivers/BSP/Adafruit_Shield/Inc
${PROJECT_SOURCE_DIR}/Drivers/BSP/Component/Inc
${PROJECT_SOURCE_DIR}/Drivers/BSP/STM32H7xx_Nucleo/Inc
${PROJECT_SOURCE_DIR}/Drivers/CMSIS/Inc
${PROJECT_SOURCE_DIR}/Drivers/STM32H7xx_HAL_Driver/Inc
)
# Make sure everything is compiled for the application
add_executable(${PROJECT_NAME}.elf ${SOURCES} ${LINKER_SCRIPT})
set(CMAKE_EXE_LINKER_FLAGS
"${CMAKE_EXE_LINKER_FLAGS}} -Wl, -Map=${PROJECT_BINARY_DIR}/${PROJECT_NAME}.map")
SET_TARGET_PROPERTIES(${PROJECT_NAME}.elf PROPERTIES LINKER_LANGUAGE C)
set(HEX_FILE ${PROJECT_BINARY_DIR}/${PROJECT_NAME}.hex)
set(BIN_FILE ${PROJECT_BINARY_DIR}/${PROJECT_NAME}.obj)
add_custom_command(TARGET ${PROJECT_NAME}.elf POST_BUILD
COMMAND ${CMAKE_OBJCOPY} -Oihex $<TARGET_FILE:${PROJECT_NAME}.elf> ${HEX_FILE}
COMMAND ${CMAKE_OBJCOPY} -Oihex $<TARGET_FILE:${PROJECT_NAME}.elf> ${BIN_FILE}
COMMENT "Building ${HEX_FILE} Building ${BIN_FILE}"
)
Above is my CMake file if it helps. Other than that, I have just copied the exact same folder structure from the example project BSP to this one.
My system otherwise is as follows:
Windows 10
Clion 2019.2.5
MinGW 5.2 (as reported by CLion)
CMake 3.15.3 (bundled with CLion)
gcc --version outputs this: 8.2.0-3
I found a previous post that just updated their tool (SW4), but that is not really an option here.
Any ideas are appreciated.
Please and thank you,
Tero
Solved! Go to Solution.
- Labels:
-
STM32H7 Series
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-11-08 3:43 AM
Hi,
So I managed to solve the issue. The issue was in the CMakeLists.txt syntax I was using. I don't know for sure what was wrong with my variables (I defined variables for paths to keep them manageable), but when I deleted them, the rest of the file started to work correctly. I though I was doing the same as my other colleague in their projects but I guess not. Maybe I will get back to those at some other time.
The cross compilers I had to define through ENV-variables (CC, CXX, AMS), and after that, I managed to at least compile the M4 side of the example project.
Thanks everyone!
Hopefully this will be helpful for the next guy running into strange issues.
-Tero
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-11-07 7:08 AM
Something is definitely off with your config, because you write
gcc --version outputs this: 8.2.0-3
yet your CMakefile contains
SET(LOCAL_ARM_TOOLCHAIN C:/GNU-Tools-Arm-Embedded/7-2018-q2-update)
which should print something like this
/opt/gcc-arm-none-eabi-7-2018-q2-update/bin/arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 7-2018-q2-update) 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-11-08 12:51 AM
Hello Berendi,
You are right. I was using the wrong command above, if I do
arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 7-2018-q2-update) 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]
I was rechecking my Cmake logs and it seems that the tool doesn't (for some unknown reason for now) change to the arm toolchain as specified in the CMake-file, but tries to use the normal MinGW gcc and I'm guessing that is why I'm seeing the error messages as the target is now my windows 10 machine, which I assume does not have support for those commands.
Back to the drawing board, the problem must be in CLion and it's plugins that create the embedded project.
Best regards,
Tero
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-11-08 3:43 AM
Hi,
So I managed to solve the issue. The issue was in the CMakeLists.txt syntax I was using. I don't know for sure what was wrong with my variables (I defined variables for paths to keep them manageable), but when I deleted them, the rest of the file started to work correctly. I though I was doing the same as my other colleague in their projects but I guess not. Maybe I will get back to those at some other time.
The cross compilers I had to define through ENV-variables (CC, CXX, AMS), and after that, I managed to at least compile the M4 side of the example project.
Thanks everyone!
Hopefully this will be helpful for the next guy running into strange issues.
-Tero
