Raspbian, or rather Raspberry Pi OS as it is called now, is currently a 32-bit operating system, and, for compatibility with older boards reasons, will remain so for a while.
Eclipse is a 64-bit application compiled for AArch64 Linux systems.
To use Eclipse on a Raspberry Pi, install a 64-bit operating system.
At the time of writing this (Jan 2021) the 64-bit version of Raspberry Pi OS does not have an official release, but is functional and Eclipse runs, although a bit slow.
The v6.0.0 version of the Eclipse Embedded CDT plug-ins had an error in the CodeRed configuration; the error was corrected in v6.1.1.
For existing Eclipses, in case the update fails, the workaround
is to Install New Software from the updates/v6 URL.
This error during startup is caused by the Qt plug-ins not running with Java 15; for more details please see the Known Issues page.
I correctly installed the
@xpack-dev-tools/arm-none-eabi-gccxPack, but the xPack… button is still disabled and I cannot select the desired version.
This button is enabled only for the xPack GNU Arm Embedded GCC toolchain; check the toolchain name, you might have selected a toolchain which has no xPacks available, like the old GNU Tools for ARM Embedded Processors.
On Windows, binary packages are .zip archives containing .exe files; some aggressive antivirus programs may quarantine those files, or even modify the content of the archives, affecting the checksum and thus preventing the packages to be installed.
Errors may look like:
Downloading https://github.com/gnu-mcu-eclipse/qemu/releases/download/v2.8.0-4-20190211/gnu-mcu-eclipse-qemu-2.8.0-4-20190211-0633-win64.zip...
{ Error: sha256-p3CgzXJt4zi5g0kxQXlOpss3Xu5Yy+Zv8HXWXkUdg6g= integrity checksum failed when using sha256: wanted sha256-p3CgzXJt4zi5g0kxQXlOpss3Xu5Yy+Zv8HXWXkUdg6g= but got sha512-k1s9UW6Zb20llIuopUwbf3D38OP1F+Nkgf3wGWwsXPwoQfhuiR89+VF3Rrf7YF20fN3tG4/3jZSC3apiHbQ6NA== sha256-ABnfxLMtY8E5KqJkrtIlPB4ML7CSFvjizCabv7i7SbU=. (9 bytes)
...
Extracting 'gnu-mcu-eclipse-qemu-2.8.0-4-20190211-0633-win64.zip'...
error: Cannot read property 'path' of null
The solution is to configure the antivirus to be less aggressive, at
least for files in the AppData\Roaming\xPacks and
AppData\Local\Caches\xPacks folders.
If this is not possible, temporarily disable the antivirus; if this is also not possible, install the packs manually (if you can!).
When installing binary packages as xPacks, the install location is
a folder that ends in .content/bin, like:
/Users/ilg/Library/xPacks/@xpack-dev-tools/arm-none-eabi-gcc/9.3.1-1.1.1/.content/bin
Unfortunately, the Eclipse file system browser does not show file/folders
starting with a dot; thus, the .content/bin final part of the path must
be entered manually.
This is one more reason to use the xPack… button, and select the xPack version in the drop down box.
Newlib, by design, requires the user to implement several low level functions,
like _exit(), _sbrk(), _write(), _close(), etc.
Without them, the project will fail during link:
Building target: hello-arm.elf
Invoking: GNU ARM Cross C Linker
arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -O0 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -g3 -Xlinker --gc-sections -Wl,-Map,"hello-arm.map" -o "hello-arm.elf" ./src/main.o
/Users/ilg/Library/xPacks/@xpack-dev-tools/arm-none-eabi-gcc/9.3.1-1.1.1/.content/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld: /Users/ilg/Library/xPacks/@xpack-dev-tools/arm-none-eabi-gcc/9.3.1-1.1.1/.content/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7-m/nofp/libg.a(lib_a-exit.o): in function `exit':
exit.c:(.text.exit+0x16): undefined reference to `_exit'
/Users/ilg/Library/xPacks/@xpack-dev-tools/arm-none-eabi-gcc/9.3.1-1.1.1/.content/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld: /Users/ilg/Library/xPacks/@xpack-dev-tools/arm-none-eabi-gcc/9.3.1-1.1.1/.content/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7-m/nofp/libg.a(lib_a-sbrkr.o): in function `_sbrk_r':
sbrkr.c:(.text._sbrk_r+0xc): undefined reference to `_sbrk'
/Users/ilg/Library/xPacks/@xpack-dev-tools/arm-none-eabi-gcc/9.3.1-1.1.1/.content/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld: /Users/ilg/Library/xPacks/@xpack-dev-tools/arm-none-eabi-gcc/9.3.1-1.1.1/.content/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7-m/nofp/libg.a(lib_a-writer.o): in function `_write_r':
writer.c:(.text._write_r+0x12): undefined reference to `_write'
/Users/ilg/Library/xPacks/@xpack-dev-tools/arm-none-eabi-gcc/9.3.1-1.1.1/.content/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld: /Users/ilg/Library/xPacks/@xpack-dev-tools/arm-none-eabi-gcc/9.3.1-1.1.1/.content/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7-m/nofp/libg.a(lib_a-closer.o): in function `_close_r':
closer.c:(.text._close_r+0xc): undefined reference to `_close'
/Users/ilg/Library/xPacks/@xpack-dev-tools/arm-none-eabi-gcc/9.3.1-1.1.1/.content/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld: /Users/ilg/Library/xPacks/@xpack-dev-tools/arm-none-eabi-gcc/9.3.1-1.1.1/.content/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7-m/nofp/libg.a(lib_a-lseekr.o): in function `_lseek_r':
lseekr.c:(.text._lseek_r+0x12): undefined reference to `_lseek'
/Users/ilg/Library/xPacks/@xpack-dev-tools/arm-none-eabi-gcc/9.3.1-1.1.1/.content/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld: /Users/ilg/Library/xPacks/@xpack-dev-tools/arm-none-eabi-gcc/9.3.1-1.1.1/.content/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7-m/nofp/libg.a(lib_a-readr.o): in function `_read_r':
readr.c:(.text._read_r+0x12): undefined reference to `_read'
/Users/ilg/Library/xPacks/@xpack-dev-tools/arm-none-eabi-gcc/9.3.1-1.1.1/.content/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld: /Users/ilg/Library/xPacks/@xpack-dev-tools/arm-none-eabi-gcc/9.3.1-1.1.1/.content/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7-m/nofp/libg.a(lib_a-fstatr.o): in function `_fstat_r':
fstatr.c:(.text._fstat_r+0x12): undefined reference to `_fstat'
/Users/ilg/Library/xPacks/@xpack-dev-tools/arm-none-eabi-gcc/9.3.1-1.1.1/.content/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld: /Users/ilg/Library/xPacks/@xpack-dev-tools/arm-none-eabi-gcc/9.3.1-1.1.1/.content/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7-m/nofp/libg.a(lib_a-isattyr.o): in function `_isatty_r':
isattyr.c:(.text._isatty_r+0xc): undefined reference to `_isatty'
collect2: error: ld returned 1 exit status
make: *** [hello-arm.elf] Error 1
"make all" terminated with exit code 2. Build might be incomplete.
For an example how to implement these functions, check the code generated by the Blink Arm template.
For a quick workaround, pass --specs=nosys.specs to the linker, and
it’ll include dummy definitions for all those functions, but be
warned that the resulting project will not be functional, and
will definitelly not display any printf() messages.
If you try to connect via the SEGGER J-Link debug plug-in to a stock ST DISCOVERY or NUCLEO board and the JLinkGDBServer keeps refuses to connect (‘Connecting to J-Link failed. Connected correctly?’), please note that the on-board programmer firmware on the ST boards is compatible with ST-LINK, not J-Link. However, SEGGER provides an upgrade path, and most of the ST bemo boards can be converted to J-Link; please follow the SEGGER Converting ST-LINK on-board into a J-Link page.
On GNU/Linux, DO NOT install Eclipse with the system package manager, because usually it installs an older version, and CDT is not included.
Instead, go to the Eclipse download site and get the proper Eclipse IDE for Embedded C/C++ Developers.
The JLink/QEMU/OpenOCD plug-in doesn’t appear to be installing correctly, or at all, there is no JLink/QEMU/OpenOCD page in the Run/Debug group.
Starting with version 4.x, the Preferences were moved under the new MCU group:
This obscure message is issued by Eclipse when you are trying to use a 64-bit Eclipse on a 32-bit Java.
If you install Java for the first time, be sure you use the 64-bit Java on 64-bit systems, and then the 64-bit version of Eclipse.
I’m trying to start OpenOCD in a terminal and it fails to execute the
echocommand…
The syntax required by the OpenOCD echo command is a single string,
in other words both echo and the message must be in the same string.
To achieve this in a shell, the string must be quoted:
-c 'echo "Started by GNU ARM Eclipse"'
Please note that this command is used by the plug-in to detect when the GDB server is initialised and ready to receive commands; it is not necessary when starting OpenCOD manually.
Why the default state for
system/src/.../xxx.cis not enabled?
Because during project creation the wizard was configured with Exclude unused.
How to enable them?
Right click → Resource Configurations → Exclude from build → uncheck
Well, easily, with New C Project. However if the question is related to the projects generated by the templates, they always use G++ as linker.
I want to make sure the G++ compiler is not putting any object code in that I do not want.
No need to worry, if you have no C++ source files in your project, the g++ compiler is never used.
The advantage of using g++ as linker is that, even for C projects, you can link a library that has a C interface but internally uses C++ (this is perfectly possible).
If you have no C++ object files in the project, there is no difference.
My breakpoints behave erratic, the program does not stop in the desired function but in the function immediately following.
This is usually the effect of optimisations, if your function was not referred in your program, the linker removed it completely. Eclipse does not know this, and any breakpoint placed in the removed function is in fact placed at the beginning of the next function.
I’m trying to single-step a simple loop, but execution does not stop after a single iteration, the target runs continuously, with permanent interactions with the debugger.
The current GDB has a problem with placing breakpoints in simple loops, and single-stepping fails. The problem was already reported (bug 1401565). If you really need this, switch to assembly view and single-stepping is again functional.
The manual suggests to use
-Ogfor optimising programs for Debug, but when stepping loops the execution flow is sometimes quite jumpy, moving outside the loop and back.
In GCC prior 4.9, the definition of -Og needs a small adjustment,
also add the -fno-move-loop-invariants option to the Debug
configuration; this will prevent the compiler to move some constant
parts of the loop outside it and the execution flow will be more easy
to follow. The problem was already reported
(bug 1395077).
Starting with 4.9, the -fno-move-loop-invariants is added automatically
to -Og.
After usb disconnected and reconnected program do not run (the example flashing led is not blinking).
This is absolutely normal for any application build with semihosting support. The semihosting channel is using resources from the debugger. Without the debugger active, the instructions used for the communication channel generate run-time faults.
Update: M3/M4 projects generated with version 2.2.1-201404120702 or later check when not running under debugger and skip the trace call, so it is possible to run the application standalone.
You are running on Windows, and did not install the full content of
the archive described in the
Windows Build Tools page.
The echo program
is not used per se, it is only a workaround for a known CDT bug.
On macOS and GNU/Linux the echo program is always present, being part
of the standard configuration. On Windows it should be installed
separately and, for convenience, it is provided in the Windows Build Tools
package.
Due to a very complicated portability reason, Eclipse is not able
to distinguish, and thus separately process, .s and .S files.
The current CDT configuration associates assembly files only with
.asm and .S files, and ignores .s files. Although it might be
possible to change the Eclipse file associations, I would not recommend
this. Better change the assembly file extensions to .S and use the
default settings.
Please note that .S assembly files will be processed by gcc, not
by as; this also means that the file will be first preprocessed like
all C/C++ files, allowing conditional compilation and macro expansion.
If you notice something wrong in the Makefiles, like macro names not substituted, missing sections, labels, etc, the project file might be broken. To fix it, create a new project. Do not copy/paste the damaged one, be sure you create it from scratch. However, you can copy/paste the source files.
As mentioned in the Known issues, avoid changing settings for individual files/folders or changing the toolchain for a project, since these are known problems in some CDT version and might damage your project.
You enabled the Internal builder, which does not work properly. Switch back to the External builder and the build will succeed.
Most probably you are running on Windows, and forgot to add the builder tools or to add the path to them. See the Windows Build Tools page.
You most probably did not configure properly the toolchain path, and CDT cannot start the discovery process. Check the path in the project Properties → C/C++ Build → Settings → Toolchains → Path.
Although it looks like the above, it is worse, since it shows that the prefix is not prepended to the compiler command. Check the prefix in the project Properties → C/C++ Build → Settings → Toolchains → Prefix.
Building target: test1.elf
Invoking: Cross ARM C++ Linker
/usr/bin/../lib/gcc/arm-none-eabi/4.7.4/../../../../arm-none-eabi/bin/ld: error: test1.elf uses VFP register arguments
/usr/bin/../lib/gcc/arm-none-eabi/4.7.4/../../../../arm-none-eabi/lib/libg.a(lib_a-impure.o) does not
/usr/bin/../lib/gcc/arm-none-eabi/4.7.4/../../../../arm-none-eabi/bin/ld: failed to merge target specific data of file
/usr/bin/../lib/gcc/arm-none-eabi/4.7.4/../../../../arm-none-eabi/lib/libg.a(lib_a-impure.o)
...
Although on Cortex-M4 the only available FPU hardware is fpv4-sp-d16, the compiler does not have a default defined for this, and it is necessary to explicitly select FPU Type: fpv4-sp-d16 in the C/C++ Settings page.
- Standalone means a typical embedded configuration, that does not use the POSIX system calls (open, close, read, write, etc).
- Retargetting is a more elaborate embedded configuration where the application makes use of these calls, but redirects the file descriptors to local devices or files, by providing custom implementations for the system calls (like _open, _close, _read, _write, etc). This configuration allows to port POSIX programs easier.
- Semihosting is a special testing configuration, that bridges all system calls to the host operating system where the GDB server runs. This configurations is particularly interesting for running test programs that can leave the test results in a file stored on the host, for automated integration in a test suite.