Windows/Linux/Mac Eclipse plugin to compile and upload arduino sketches

[vicente95650]

Thank you Jantje, you solved my problem. I am looking forward to learning to use Eclipse with Sloeber.

[tyllurius]

Hello everyone and Merry Christmas!


First I want to say thank you for this great tool, it's exactly what I was looking for!
Last couple of days I was setting up Sloeber for STM32 programming and debugging. So far I already had the chain working, means I already compiled and uploaded successfully a test sketch (BlinkWithoutDelay) to a BluePill STMF103C8. But somehow something got broken, and I don't know if it's due to sloeber, eclipse, STM32duino or me, so I'll post it here.


I create a new sketch (e.g. BlinkWithoutDelay), select blue pill as STM32 board select blue pill as STM32 board and start the build process. All files will compile, but when it comes to combining them several files cannot be found. Here's the compiler output:

Code: [Select]

'Starting combiner'
"D:\Programme\Sloeber\arduinoPlugin\packages\STM32\tools\xpack-arm-none-eabi-gcc\9.2.1-1.1/bin/arm-none-eabi-gcc" -mcpu=cortex-m3  -mthumb -Os --specs=nano.specs -u _printf_float -Wl,--defsym=LD_FLASH_OFFSET=0x2000 -Wl,--defsym=LD_MAX_SIZE=65536 -Wl,--defsym=LD_MAX_DATA_SIZE=20480 -Wl,--cref -Wl,--check-sections -Wl,--gc-sections -Wl,--entry=Reset_Handler -Wl,--unresolved-symbols=report-all -Wl,--warn-common "-Wl,--default-script=D:\Programme\Sloeber\arduinoPlugin\packages\STM32\hardware\stm32\1.9.0\variants\PILL_F103XX/ldscript.ld" "-Wl,--script=D:\Programme\Sloeber\arduinoPlugin\packages\STM32\hardware\stm32\1.9.0\system/ldscript.ld" "-Wl,-Map,E:\OneDrive\Technik\_programmierung\sloeber-workspace\BlinkTest\Release/BlinkTest.map"   "-LD:\Programme\Sloeber\arduinoPlugin\packages\STM32\tools\CMSIS\5.5.1/CMSIS/DSP/Lib/GCC/" -larm_cortexM3l_math -o "E:\OneDrive\Technik\_programmierung\sloeber-workspace\BlinkTest\Release/BlinkTest.elf" "-LE:\OneDrive\Technik\_programmierung\sloeber-workspace\BlinkTest\Release" -Wl,--start-group    .\sloeber.ino.cpp.o  .\libraries\SrcWrapper\src\stm32\PortNames.c.o .\libraries\SrcWrapper\src\stm32\analog.cpp.o .\libraries\SrcWrapper\src\stm32\bootloader.c.o .\libraries\SrcWrapper\src\stm32\clock.c.o .\libraries\SrcWrapper\src\stm32\core_callback.c.o .\libraries\SrcWrapper\src\stm32\dwt.c.o .\libraries\SrcWrapper\src\stm32\hw_config.c.o .\libraries\SrcWrapper\src\stm32\interrupt.cpp.o .\libraries\SrcWrapper\src\stm32\lock_resource.c.o .\libraries\SrcWrapper\src\stm32\low_power.c.o .\libraries\SrcWrapper\src\stm32\pinmap.c.o .\libraries\SrcWrapper\src\stm32\rtc.c.o .\libraries\SrcWrapper\src\stm32\stm32_def.c.o .\libraries\SrcWrapper\src\stm32\stm32_eeprom.c.o .\libraries\SrcWrapper\src\stm32\system_stm32yyxx.c.o .\libraries\SrcWrapper\src\stm32\timer.c.o .\libraries\SrcWrapper\src\stm32\uart.c.o  .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_adc.c.o .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_bdma.c.o  .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_sd.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_sd_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_sdadc.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_sdram.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_smartcard.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_smartcard_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_smbus.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_spdifrx.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_spi.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_spi_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_sram.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_swpmi.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_tim.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_tim_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_tsc.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_uart.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_uart_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_usart.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_usart_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_wwdg.c.o  .\libraries\SrcWrapper\src\syscalls.c.o  .\core\variant\PeripheralPins.c.o .\core\variant\variant.cpp.o     E:\OneDrive\Technik\_programmierung\sloeber-workspace\BlinkTest\Release/arduino.ar  -lc -Wl,--end-group -lm -lgcc -lstdc++
arm-none-eabi-gcc: error: .\libraries\Srcrapper\src\HAL\stm32yyxx_hal_sdram.c.o: No such file or directory
makefile:96: recipe for target 'BlinkTest.elf' failed
make: *** [BlinkTest.elf] Error 1
"D:/Programme/Sloeber/arduinoPlugin/tools/make/make -j8 all" terminated with exit code 2. Build might be incomplete.

(I needed to delete some of the compiler output lines listing libraries to shorten the message length)


This evening I noticed there's a "w" missing in the link, it says 

Code: [Select]

arm-none-eabi-gcc: error: .\libraries\Srcrapper\src
and I think this must be the cause, but how can it be resolved?

I'm using sloeber 4.3.3 (product) and STM32 1.9.0 platform.


Looking forward for any help as I'm in urge need to transfer my growing projects into Eclipse

[Jantje]

For stm32 you need the nightly.Amongst others for this bug
https://github.com/Sloeber/arduino-eclipse-plugin/issues/1143

Note the nightly needs java 11 where the latest product needs java8. So you will have to upgrade or delete the jre folder

note 2: you can also see all the fixes in sloeber by going to arduino menu->do I need to upgrade
This will show you all the fixes and links to the related github issues

[tyllurius]

Hi Jantje,
thanks for your answer. I already went throught the sloeber issues, especially the mentioned #1143, as it seemed to be the same problem as mine, but the conclusion I got from it was that the SrcWrapper issue was fixed; but there was no answer to the missing .h files the other guys had, so I didn't get the idea that it's only possible with the nightly build.

By the way, the wrong compiler output (with missing "w") disappeared when I used STM Core 1.8.0

So, I tried to get the nightly which atm is only available at the inbuilt update function, when I try to download I get following error message:

full message

Code: [Select]

Cannot complete the install because one or more required items could not be found.
  Software being installed: Sloeber 4.3.3.202012182318 (io.sloeber.product 4.3.3.202012182318)
  Missing requirement: C/C++ Development Tools Core 7.1.100.202012020953 (org.eclipse.cdt.core 7.1.100.202012020953) requires 'java.package; javax.xml.bind [2.3.3,3.0.0)' but it could not be found
  Cannot satisfy dependency:
    From: Sloeber 4.3.3.202012182318 (io.sloeber.product 4.3.3.202012182318)
    To: org.eclipse.equinox.p2.iu; org.eclipse.cdt.feature.group [10.1.0.202012020953,10.1.0.202012020953]
  Cannot satisfy dependency:
    From: C/C++ Development Tools 10.1.0.202012020953 (org.eclipse.cdt.feature.group 10.1.0.202012020953)
    To: org.eclipse.equinox.p2.iu; org.eclipse.cdt.gnu.debug.feature.group [10.1.0.202010181249,10.1.0.202010181249]
  Cannot satisfy dependency:
    From: C/C++ GNU Toolchain Debug Support 10.1.0.202010181249 (org.eclipse.cdt.gnu.debug.feature.group 10.1.0.202010181249)
    To: org.eclipse.equinox.p2.iu; org.eclipse.cdt.launch [10.1.0.202010181249,10.1.0.202010181249]
  Cannot satisfy dependency:
    From: C/C++ Development Tools Launching Support 10.1.0.202010181249 (org.eclipse.cdt.launch 10.1.0.202010181249)
    To: osgi.bundle; org.eclipse.cdt.core [7.0.0,8.0.0)
It tells something about a missing Java version, but what? As far as I understood the Sloeber product comes with its own Java. On my system I have both Java 8 or 11, and set the current version on PATH variable, and I get error with both..but I don't know if this is the reason.


SOLVED: it should be mentioned that all update sites have to be enabled, but if anyone encounters this/this 11 year old bug the "contact all update sites during install" checkbox should be unchecked. Then the update to latest nightly works.

[tyllurius]

Now that I got the nightly running, I tried to get STM32 1.9.0 running, but it fails again, same error:

Code: [Select]

arm-none-eabi-gcc: error: .\libraries\SrcWrappr\src\HAL\stm32yyxx_hal_sdram.c.o: No such file or directory
makefile:96: recipe for target 'BlinkTest.elf' failed
make: *** [BlinkTest.elf] Error


So, my few simple questions: is it somehow possible to get STM32 1.9.0 working with Sloeber? Is there anyone out there who is using this constellation, with success? What is the latest version that can be used?

I can't believe I am the only one trying to get this work. I'm about to switch back from 1.9 to 1.7 for the hundredth time, it's really time consuming to get this running...

[Jantje]

Googling

Code: [Select]

"error: .\libraries\SrcWrappr\src\HAL\stm32yyxx_hal_sdram.c.o: No such file or directory"

leads me to https://github.com/stm32duino/Arduino_Core_STM32/issues/813

Is this used?
yes. The issues fixed in the nightly have been reported by a stm32 developer using sloeber before the release of the changes.
Same goes for ESP32
Also I run tests and they involve 1000 + boards, STM32 is amongst those.

I should make a release but I'm in the middle of a big change (I'm changing the internal workings of sloeber) and I prefer taking it slow and making a stable release to fixing issues with the pressure of a broken release.

[Juraj]

I should make a release but I'm in the middle of a big change (I'm changing the internal workings of sloeber) and I prefer taking it slow and making a stable release to fixing issues with the pressure of a broken release.

Jantie, will the change include support for dot_a_linkage of libraries? (issue 1126 https://github.com/Sloeber/arduino-eclipse-plugin/issues/1126)

[Jantje]

Jantie, will the change include support for dot_a_linkage of libraries? (issue 1126 https://github.com/Sloeber/arduino-eclipse-plugin/issues/1126)

Unfortunately not. But it is a steppingstone towards it. But not the last.
This dot_a_linkage is to be implemented in what is called "managed build" in CDT. There is activity in CDT to replace the current managed build, but it is hard and as always, resources are low.
Basically what sloeber currently does (build a library and executable in one project) is already far away from the original goal.
One of the biggest problems Sloeber has with the dot_a_linkage is that libraries are added at configuration switching time. This is so because each configuration can be a different board and as such can need different libraries.
Currently Sloeber does not save library information between configuration switches. That means that the decision logic to redirect the library code to a archive (which is not supported ;-) in the CDT version ) needs to be done at "make file generation" (Which is currently under scrutiny)
If makefile generator could simply query the project (which it doesn't have in the CDT version) that would be possible. But at this time the project simply doesn't know the libraries.
So this means that for each file in the makefile there needs to be a check whether this file is part of a library (Which is not obvious because the library folder in your project only contains links to "origins" and the make file generator only sees the "origin") and if it is; find the properties file (which may be a couple of parent folders up; and non-existent) read it and decide.
Once the project will contain library information (like it contains board information) it will be far easier to map files on libraries (does the file has the library root as basis) and read the library properties (should be in the library information)
Don't hold your breath

[tyllurius]

I've read about this and other build_opt.h issues, but as far as I understood it's associated with the serial com. Also, in the mentioned post the issuer used STM core 1.7.0, and that version works for me. But I'm not yes experienced enough to deal with build options.

It seems that it happens when it comes to linking the compiled files and for any reason doesn't find them.
This is the makefile line at which it fails:

Code: [Select]

@echo 'Starting combiner'
"D:\Programme\Sloeber\arduinoPlugin\packages\STM32\tools\xpack-arm-none-eabi-gcc\9.2.1-1.1/bin/arm-none-eabi-gcc" -mcpu=cortex-m3  -mthumb -Os --specs=nano.specs -u _printf_float -Wl,--defsym=LD_FLASH_OFFSET=0 -Wl,--defsym=LD_MAX_SIZE=65536 -Wl,--defsym=LD_MAX_DATA_SIZE=20480 -Wl,--cref -Wl,--check-sections -Wl,--gc-sections -Wl,--entry=Reset_Handler -Wl,--unresolved-symbols=report-all -Wl,--warn-common "-Wl,--default-script=D:\Programme\Sloeber\arduinoPlugin\packages\STM32\hardware\stm32\1.9.0\variants\PILL_F103XX/ldscript.ld" "-Wl,--script=D:\Programme\Sloeber\arduinoPlugin\packages\STM32\hardware\stm32\1.9.0\system/ldscript.ld" "-Wl,-Map,E:\OneDrive\Technik\_programmierung\sloeber-workspace\BlinkTest\hwdebug/BlinkTest.map"   "-LD:\Programme\Sloeber\arduinoPlugin\packages\STM32\tools\CMSIS\5.5.1/CMSIS/DSP/Lib/GCC/" -larm_cortexM3l_math -o "E:\OneDrive\Technik\_programmierung\sloeber-workspace\BlinkTest\hwdebug/BlinkTest.elf" "-LE:\OneDrive\Technik\_programmierung\sloeber-workspace\BlinkTest\hwdebug" -Wl,--start-group   $(LINK_OBJ)    E:\OneDrive\Technik\_programmierung\sloeber-workspace\BlinkTest\hwdebug/arduino.ar  -lc -Wl,--end-group -lm -lgcc -lstdc++
So, is it a purely STM32 core related problem, or does it only happen in combination with Sloeber? If it's not yet known and a pure STM32 core thing I'd like to make an issue to the STM32duino project. I already tried to dig deeper into this (as I think it has to do with some cache or wrong linkage issues), but due to my restricted knowlegde of this stuff I can't get very far. Meanwhile no other chance than switching back to 1.7.

Another thing I encountered is that Clean is not working. Will this be fixed?

And a third issue, I can't get SPI to work on my blue pill, though this should be an easy task. But that seems to be another story...well, I think I've spent half of my vacation with googling problem solutions

Looking forward for any new version of Sloeber!

EDIT: @Jantje In your tests, did you have any STM32 boards with core 1.9.0 working with Sloeber? If yes, I know something's wrong with my configuration. But until now I don't know if it's possible at all.

[Jantje]

EDIT: @Jantje In your tests, did you have any STM32 boards with core 1.9.0 working with Sloeber? If yes, I know something's wrong with my configuration. But until now I don't know if it's possible at all.

The tests run with the latest available version. I assume the tests are run with a frequency that is higher than normal release frequency.
Because I can't make sense of what you are writing I assume that most of your issues are cause by user error. In other ways you are trying to do things in a way Sloeber is not meant to be used.

[Juraj]

I don't have this error with STM32 1.9.0 and Sloeber plugin version 4.3.3.202004250422
as you can see the paths on command line are right. something happens in gcc

[Juraj]

@Jantje, https://github.com/Sloeber/arduino-eclipse-plugin/issues/1126#issuecomment-573453291

Code: [Select]

} else if (primaryInputNames[curPath].toString().startsWith("libraries") && (bUseArchiver)) {
  outputNames[curPath] = Helpers.GetOutputName(primaryInputNames[curPath]).addFileExtension("o");

[tyllurius]

Thanks for the answers, now I know it must be someting in my setup; though I don't have a clue because I didn't do anyting unusual than just installing and adding STM32 boards the very normal way.