Before that I tried IDE Keil and she work but as IDE it's terrible.
So I'm trying to use CLion 2016.3 to build an embedded C++ project for an STM32L100RCx target on Ubuntu 16.04. But I can't undestand how to setup correctly. Reading the Jetbrain's blog doesn't help me. After compilation there is some error's that it can't find some call's from *.ld file.
Cmake flags:
SET(CMAKE_C_FLAGS "-mcpu=cortex-m3 -mthumb" "-msoft-float -mfix-cortex-m3-ldrd")
And got an errors:
/tmp/ccPo0ceQ.s:713: Error: selected processor does not support `dsb 0xF' in ARM mode
/tmp/ccPo0ceQ.s:734: Error: selected processor does not support `dsb 0xF' in ARM mode
/tmp/ccPo0ceQ.s:1100: Error: selected processor does not support `dsb 0xF' in ARM mode
/tmp/ccPo0ceQ.s:1111: Error: selected processor does not support `isb 0xF' in ARM mode
/tmp/ccPo0ceQ.s:1157: Error: selected processor does not support `dmb 0xF' in ARM mode
*** recipe for target 'CMakeFiles/Project.elf.dir/Drivers/STM32L1xx_HAL_Driver/Src/stm32l1xx_hal_cortex.c.obj' failed
Can any one help me or may be get me working CMakeLists.txt and *.cmake files?
UPD:
My Cmake file:
include(CMakeForceCompiler)
set(CMAKE_SYSTEM_NAME Generic)
CMAKE_FORCE_C_COMPILER(/opt/arm/bin/arm-none-eabi-gcc GNU)
CMAKE_FORCE_CXX_COMPILER(/opt/arm/bin/arm-none-eabi-g++ GNU)
SET(CMAKE_C_FLAGS "-mcpu=cortex-m3 -mthumb" "-msoft-float -mfix-cortex-m3-ldrd")
# fix long strings (CMake appends semicolons)
string(REGEX REPLACE ";" " " CMAKE_C_FLAGS "${CMAKE_C_FLAGS}")
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS}" CACHE STRING "")
set(BUILD_SHARED_LIBS OFF)
set(CMAKE_CXX_FLAGS "${COMMON_FLAGS} -std=c++11")
set(CMAKE_C_FLAGS "${COMMON_FLAGS} -std=gnu99")
set(LINKER_SCRIPT ${CMAKE_SOURCE_DIR}/STM32L100RCTx_FLASH.ld)
set(CMAKE_EXE_LINKER_FLAGS "-Wl,-gc-sections -T ${LINKER_SCRIPT}")
It seems I find the right way.
My wrong sequence of actions:
doing 'Reset Cache And Reload Project'
then I try to build the project
I thought that the 'Reset Cache And Reload Project' is just cleaning the Cmake cache, but in fact it looks as if it is deleting some necessary files.
The sequence was correct:
doing 'Reset Cache And Reload Project'
doing 'Reload Cmake Project'
then a successful build
In general, it was just enough to check the 'Automaticaly Reload Cmake Project on Edit' option.
Related
I have a stm32f103 project that is initialized using stm32cubemx and I'm using neovim for editing and arm-none-eabi-gcc for compilation of code (whit auto-generated makefile).
I also have installed clangd LSP and also bear to generate compile_commands.json file. Everyting works fine except that there's two errors:
stdio.h file not found
Compiler generates FPU instructions for a device without an FPU (check __FPU_PRESENT)
I looked at core_cm3.h file and __FPU_USED is disabled, which is exactly what clang says.
/** __FPU_USED indicates whether an FPU is used or not.
This core does not support an FPU at all
*/
#define __FPU_USED 0U
But I couldn't find any line in my makefile flags that enables the FPU for compilation.
# fpu
# NONE for Cortex-M0/M0+/M3
# float-abi
# mcu
MCU = $(CPU) -mthumb $(FPU) $(FLOAT-ABI)
I also commented out $(FPU) and $(FLOAT-ABI), but the error still exists.
Although I can compile the project without any problems (because gcc has no complaints), but these errors are kind of on my nerve.
Is there a way to fix these errors? Or is there any gcc-based LSPs to use instead of clangd?
There's also ccls on neovim's LSP list but I was unable to install it.
s there a way to fix these errors?
https://clangd.llvm.org/config#files You can:
create clangd configuration file
specify -sysroot command to specify the location of your buildchain (/usr/arm-none-eabi/ on my system)
and other needed options (-isysroot -nostdlib etc.) if you use them.
I would advise anyway to move CMake and generate compile_command.json anyway.
is there any gcc-based LSPs to use instead of clangd?
I am not aware of any.
I have a problem with an MCU 8051 IDE simulator. When using the C language it was outputting the message "no sdcc compiler". After I installed the SDCC compiler on my PC, this part worked.
But after I wrote a C program and compiled it, this message came:
sdcc -mmcs51 --iram-size 256 --xram-size 0 --code-size 8192 --nooverlay --compile-only --noinduction --std-sdcc89 --model-small "task1.1cpro.c"
Output:
task1.1cpro.c:6: warning 94: comparison is always true due to limited range of data type
Unable to find "task1.cdb"
|
+-- Most probably that indicates that you have disabled debugging switch, if it is not that what you want then go to
[Main Menu] --> [Configure] --> [Compiler configuration] --> [C language] --> [General] and enable "--debug" compiler switch. "
What is the matter? I can't find it. How can I solve this problem?
After installing SDCC, you can type this in the Windows prompt to check its version:
sdcc -v .
Now create a folder called src to store your C files.
Write your code and save as file code.c in the src folder.
Then open cmd.exe and navigate to the src folder. Type the following command to compile the C file.
sdcc code.c
If there aren't any errors, the code will compile and generate several files.
I have a problem when building chromium for ARM platform. Here are some details about my host server:
Linux version 4.2.0-42-generic (buildd#lgw01-55) (gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3) )
And I use Chromium version 53.0.2785.143. I tried to use gn to build the chromium, and here is my arguments in args.gn file:
target_cpu = "arm"
arm_tune = "generic-armv7-a"
arm_float_abi = "softfp"
Basically, I used these specific arguments above because of my ARM platform. And the gn command ran without errors. However, when building project with ninja, the following errors popped out:
ninja: Entering directory `out/Default_arm64'
[1/1] Regenerating ninja files
[296/46119] LINK ./minidump-2-core
FAILED: minidump-2-core
../../third_party/llvm-build/Release+Asserts/bin/clang++ -Wl,--fatal-warnings -fPIC -Wl,-z,noexecstack -Wl,-z,now -Wl,-z,relro -Wl,-z,defs -fuse-ld=gold -B../../third_party/binutils/Linux_x64/Release/bin -Wl,--icf=all -pthread --target=arm-linux-gnueabihf --sysroot=../../build/linux/debian_wheezy_arm-sysroot -L/home/miaozixiong/workspace/chromium/src/build/linux/debian_wheezy_arm-sysroot/lib/arm-linux-gnueabihf
-Wl,-rpath-link=/home/miaozixiong/workspace/chromium/src/build/linux/debian_wheezy_arm-sysroot/lib/arm-linux-gnueabihf
-L/home/miaozixiong/workspace/chromium/src/build/linux/debian_wheezy_arm-sysroot/usr/lib/arm-linux-gnueabihf
-Wl,-rpath-link=/home/miaozixiong/workspace/chromium/src/build/linux/debian_wheezy_arm-sysroot/usr/lib/arm-linux-gnueabihf
-Wl,-rpath-link=../Default_arm64 -Wl,--disable-new-dtags -o "./minidump-2-core" -Wl,--start-group #"./minidump-2-core.rsp"
-Wl,--end-group -ldl -lrt ld.gold: error: obj/breakpad/minidump-2-core/minidump-2-core.o uses VFP register
arguments, output does not
...
I am new to chromium and have no clue about what do those errors mean. So anybody knows how to work around? You are appreciated.
Note: I need my arm_float_abi attribute to be "softfp" according to my ARM platform. So please note I cannot change it to "hard". Also, when set float abi = "hard", there is no building errors.
ld.gold: error: obj/breakpad/minidump-2-core/minidump-2-core.o uses VFP register arguments, output does not
This a linking error to indicate that minidump-2-core cannot be linked, due to a mismatch in the floating point ABI: the object minidump-2-core.o is compiled for hard floats (the generated code takes advantage of the ARM VFP unit - "uses VFP register arguments"), but the target executable is requested to use soft floats (in which floating point support is emulated, rather than using specialized FP hardware instructions).
According to this bug report, Chromium should build fine with soft float.
My best guess is, try replacing softfp by just soft: arm_float_abi = "soft".
According to gcc documentation, softfp maintains the soft ABI but still 'allows the generation of code using hardware floating-point instructions', which could lead to the seen error.
If that won't work, you might want to check this tutorial on cross building Chromium for ARM:
https://unix.stackexchange.com/questions/176794/how-do-i-cross-compile-chromium-for-arm
I posted this question and finally solved it. I used my local tool chain on ARM platform and compiled it successfully with g++.
I have followed the standard procedure to get my new Nucleo-F767ZI board from STMicroelectronics up and running. The procedure is as follows:
STEP 1
I downloaded the SW4STM32 IDE from AC6. This is an Eclipse-based IDE for programming the STM32 microcontroller series from STMicroelectronics.
STEP 2
I downloaded the latest CubeMX software from STMicroelectronics. CubeMX is a java-based tool in which you can configure a few basic settings for your microcontroller: clock speed, realtime-os, peripherals, ... . After that, CubeMX spits out a folder with a bunch of c-source files in it. That's basically your project to start from.
STEP 3
I open the SW4STM32 IDE and import the project that CubeMX just generated. I do not change or add any code. I just click the build button, hoping that the project will compile to an executable .bin file (and perhaps also a .elf file). This is where things go wrong.
THE ERROR
The compiler finds (or thinks that he finds) an error in the following function in the FreeRTOS file portmacro.h:
171 /* Generic helper function. */
172 __attribute__( ( always_inline ) ) static inline uint8_t ucPortCountLeadingZeros( uint32_t ulBitmap )
173 {
174 uint8_t ucReturn;
175
176 __asm volatile ( "clz %0, %1" : "=r" ( ucReturn ) : "r" ( ulBitmap ) );
177 return ucReturn;
178 }
The error message I get from the compiler is:
line 173 : sorry, unimplemented: Thumb-1 hard-float VFP ABI
Now there are several reasons why I don't understand this particular error message:
>> Issue 1
The first issue is about the location of the error. Line 173 is the line where the opening curly brace is located. Why on earth would an error message refer to that line?
>> Issue 2
Secondly, I do not understand why the error message mentions the hardware floating point unit on my microcontroller. I cannot see any floating point instruction in the ucPortCountLeadingZeros(..) function.
>> Issue 3
I have opened the GCC compiler settings in the Eclipse project. Just to take a look at the default settings. I do not change anything. Here are two screenshots:
The first screenshot shows that the following option is selected:
Instruction set : Thumb II
The second screenshot shows that the following options are given to GCC:
-mfloat-abi=hard # Inform GCC that this micro has a hardware floating point unit
-mfpu=fpv5-d16 # The hardware floating point unit is double precision
-mthumb # ARM Thumb instruction set
So, what Thumb instruction set version is actually selected. Thumb I or Thumb II?
Please help me to find out why this generated project from CubeMX doesn't compile. I am very thankful for any tips and hints.
EDIT :
The complete set of options passed on to the GCC compiler (as visible in the second screenshot) is the following:
-mthumb
-mfloat-abi=hard
-mfpu=fpv5-d16
-D__weak="__attribute__((weak))"
-D__packed="__attribute__((__packed__))"
-DUSE_HAL_DRIVER
-DSTM32F767xx
-I../Inc
-I../Drivers/STM32F7xx_HAL_Driver/Inc
-I../Drivers/STM32F7xx_HAL_Driver/Inc/Legacy
-I../Middlewares/Third_Party/FreeRTOS/Source/portable/GCC/ARM_CM7/r0p1
-I../Middlewares/Third_Party/FreeRTOS/Source/include
-I../Middlewares/Third_Party/FreeRTOS/Source/CMSIS_RTOS
-I../Drivers/CMSIS/Include
-I../Drivers/CMSIS/Device/ST/STM32F7xx/Include
-Os
-g3
-Wall
-fmessage-length=0
-ffunction-sections
-c
-fmessage-length=0
As noted in the comments below the question, the project generated by CubeMX did not specify the -mcpu option to the compiler. So one should manually add this option to the compiler, the linker and the assembler:
-mcpu=cortex-m7
If you do that, it builds without trouble.
Adding the option to the compiler, linker and assembler is a bit tricky. I'll explain in detail how to do it.
1. Adding the option to the compiler
> Right-click on your project folder in the left window of Eclipse. Click on Properties in the pop-up window.
> In the properties window, select C/C++ Build > Settings on the left.
> Now you should see 3 options in the middle of the window: MCU GCC Compiler, MCU GCC Linker and MCU GCC Assembler. Click on the first one, and select Miscellaneous.
> You should see the other flags line. Add the following option to that line: -mcpu=cortex-m7.
2. Adding the option to the assembler
> In the same properties window, select MCU GCC Assembler > General.
> You should see the Assembler flags line. Add the option -mcpu=cortex-m7 to that line.
3. Adding the option to the linker
> Again in the properties window, select MCU GCC Linker.
> You should see the Command line pattern line, with the following text in it:
${COMMAND} ${FLAGS} ${OUTPUT_FLAG} ${OUTPUT_PREFIX}${OUTPUT} ${INPUTS}
> Add the option -mcpu=cortex-m7 to that line.
After doing all that, both the compiler, the assembler and the linker know that you want to build for the Cortex-M7 architecture. It still bothers me a bit that CubeMX didn't put that by default in the configuration file of the generated project. But at least, we know the workaround now..
Many thanks to #Notlikethat, #Jean-Louis Bonnaffe and #rjp for bringing me to this solution with the useful comments :-)
I already faced similar issue. The IDE has to be updated to support new board/chip. IAR workbench V7.50 does not support F767ZI, but V7.60 does.
SW4STM32 Update : "Help" >> "Check for updates..." then restart Eclipse;
I am trying to cross-compile an application (tvheadend) for ARM (raspberry pi 2), using a x64 machine and this toolchain.
I am using the following command line to configure the compilation:
./configure --arch=arm-linux-gnueabihf --cc=arm-linux-gnueabihf-gcc --disable-avahi --release --cflags=-DOPENSSL_USE_DEPRECATED and then I just make.
The problem happens during the compilation of the source file src/utils.c: such file includes string.h, which is correctly selected from the toolchain include directory (let's say ARMTOOLCHAIN/usr/include), but then string2.h, which is inside ARMTOOLCHAIN/usr/include/arm-linux-gnueabihf/bits, is selected from the system directory, instead of ARMTOOLCHAIN/usr/include/arm-linux-gnueabihf/bits.
In file included from /usr/include/x86_64-linux-gnu/bits/byteswap.h:35:0,
from ARMTOOLCHAIN/usr/include/endian.h:61,
from /usr/include/x86_64-linux-gnu/bits/string2.h:51,
from ARMTOOLCHAIN/usr/include/string.h:637,
from src/utils.c:21:
src/utils.c: In function ‘sbuf_put_be16’:
src/utils.c:397:9: error: invalid 'asm': invalid operand for code 'w'
u16 = htons(u16);
^
The problem is that the compiler does not search inside ARMTOOLCHAIN/usr/include/arm-linux-gnueabihf for the bits subdir. I tried to specify -IARMTOOLCHAIN/usr/include/arm-linux-gnueabihf as an option, and to create a symlink to bits inside ARMTOOLCHAIN/usr/include (so to avoid arm-linux-gnueabihf), but none of these works.
Try modifying cflags as follows in your configure invocation:
--cflags="-DOPENSSL_USE_DEPRECATED -nostdinc -nostdinc++"