Loading...
 

SW4STM32 and SW4Linux fully supports the STM32MP1 asymmetric multicore Cortex/A7+M4 MPUs

   With System Workbench for Linux, Embedded Linux on the STM32MP1 family of MPUs from ST was never as simple to build and maintain, even for newcomers in the Linux world. And, if you install System Workbench for Linux in System Workbench for STM32 you can seamlessly develop and debug asymmetric applications running partly on Linux, partly on the Cortex-M4.
You can get more information from the ac6-tools website and download (registration required) various documents highlighting:

System Workbench for STM32

Forum List Topic List

[ prev topic ]  

Include files from system-wide gcc used, but not the ones shipped with sw4stm32. How to fix?

Posted by SuperFluffy on 2018-11-15 11:48

“Fixed” the problem. Question now is: how to prevent sw4stm32 from using the wrong include paths? See EDIT 2 at the bottom.

I am just starting to explore sw4stm32 2.6, which is available from the Arch Linux AUR. I have imported an Amazon FreeRTOS demo, and cannot get it to build, because of the following error: 

Description	Resource	Path	Location	Type
fatal error: stdint.h: No such file or directory	aws_demos		line 9, external location: /usr/lib/gcc/arm-none-eabi/8.2.0/include/stdint.h	C/C++ Problem


Now, this location does not actually correspond to the gcc shipped with sw4stm32, but to the one I have installed system wide. The gcc shipped with sw4stm32 is located at $ECLIPSE_HOME/plugins/fr.ac6.mcu.externaltools.arm-none.linux64_1.16.0.201807130628/tools/st-gnu-arm-gcc-7-2017-q4-major_gdb-5_4-2016q3/bin, which is also part of the $PATH defined at Properties > C/C++ Build > Environment.

As you can see in the screenshot below, sw4stm32 considers /usr/arm-none-eabi/include, /usr/lib/arm-none-eabi/8.2.0/include, and /usr/lib/arm-none-eabi/8.2.0/include-fixed as include paths, but not those at /usr/lib/sw4stm32/plugins/fr.ac6.mcu.externaltools.arm-none.linux64_1.16.0.201807130628/tools/st-gnu-arm-gcc-7-2017-q4-major_gdb-5_4-2016q3/lib/gcc/arm-none-eabi/7.2.1/include or /usr/lib/sw4stm32/plugins/fr.ac6.mcu.externaltools.arm-none.linux64_1.16.0.201807130628/tools/st-gnu-arm-gcc-7-2017-q4-major_gdb-5_4-2016q3/lib/gcc/arm-none-eabi/7.2.1/include-fixed, respectively.

Sw4stm32 Include

So how does sw4stm32 determine that it should use one path but not the other for finding include files? I did not find a setting that explicitly lists those paths that do get included. Properties > C/C++ General > Paths and Symbols only lists Include Directories related to the env var $ProjName.

Where should I specify that it should look for those include files that were distributed with sw4stm32?


EDIT: I believe I found the setting containing the incorrect includes. In Properties > C/C++ General > Proprocesser Include under Languages/GNU C, I can see the settings entry Ac6 SW4 STM32 MCU Built-in Compiler Settings, with /usr/arm-none-eabi/include, /usr/lib/arm-none-eabi/8.2.0/include, and /usr/lib/arm-none-eabi/8.2.0/include-fixed.

It further says that Settings entries for this provider are supplied by the system and are not editable. That’s very curious.

EDIT 2: I have uninstalled my system-wide versions of the ARM GCC compiler suites. When restarting sw4stm32, it now correctly displays the correct include paths distributed with sw4stm32.

Why then did it choose the wrong paths?

Reads: 4288
Link
Posted by tang on 2018-11-15 18:07

Hi,

The include entries are usually auto-detected on build from a compiler command. The compiler path is defined in Project Properties > C/C++ Build > Settings > Tools Settings > MCU Settings > Path. The default value should be ${openstm32_compiler_path} which refers to the ARM GCC shipped with SW4STM32 (That’s why they are not editable in Ac6 SW4 STM32 MCU Built-in Compiler Settings). It also prepends the system PATH variable for the project to force project using the right compiler.

If the Path value is empty, it uses the system compiler.
Verify the Path value is ${openstm32_compiler_path} on your project, then build the project. it should find the sw4stm32-wide compiler include folders.
There might be a bug if it still looks for the system compiler...

Hope it answers your question.
Regards,
Kevin.

Link