Eclipse build failed for Blinky w/ SDK 14 - Make Error 2

[Mike W]

Hello!

I experienced the same errors as here and here when following the Eclipse gcc tutorial (7), but the solutions did not solve my problem.

I suspect this is related to my using SDK 14 instead of 13, as the project Makefile was tested with, but I did copy the attached Makefile.common to the directory, and it had no effect one way or the other. As for the general Makefile for the project, the following suggestions from other answers were individually then jointly applied without success after the build initially failed:

1. CFLAGS += -O0 -g3 # was already in the Makefile
2. changed components/toolchain/gcc/*.S to *.s (lower case) and changed "/Include" in Makefile line 54 to "/include"
3. rebuilt c++ index
4. commented Line 42 of Makefile (which referenced the non-existent nrf_delay.c)

Other important information:

1. Here attached is my Makefile.
2. I'm using Windows 10 pro.
3. The Console error indicates a missing file - the I manually checked all of the includes and there is one that does not exist - there is no bsp folder in examples. I don't know if this is related, but it's all I could find
4. Here attached is the verbose error from the Console.
5. Everything in the tutorials works fine with nrfjprog.
6. Make the folder utils are added to path and work readily in CMD - i.e. "where make" and "where mkdir" both point to the properly referenced GNU ARM Eclipse build tools folder.
7. I did see something about spaces in the tools path, but there are no paths with spaces referenced in the Makefile. Should I move the build tools and toolchain to a path without spaces and tell Eclipse to look for such?
8. The following lines show up with errors in Eclipse:

Makefile

• Line 127 under all: clean: $(NO_ECHO)$(MAKE) -f $(MAKEFILE_NAME) -C $(MAKEFILE_DIR) -e cleanobj

• Line 163 under $(OBJECT_DIRECTORY)/%.o: %.c: @echo Compiling file: $(notdir $<)

main.c

• Lines 51, 52, 54: Unresolved inclusions for <stdbool.h>, <stdint.h> and "boards.h"

• Line 65, while (true): symbol "true" could not be resolved

• Line 67, for (int i = 0; i < LEDS_NUMBER; i++): symbol LEDS_NUMBER could not be resolved

Thanks for your help!

[Mike W]

Even with completely fresh Eclipse install, completely clean SDK (except for modifying the file you provide), still have the same errors:

In main.c:

1. Line 53, #include "nrf_delay.h", Unresolved inclusion (technically a warning but obviously problematic)
2. Line 54, #include "boards.h", Unresolved inclusion (warning)
3. Line 67, LEDS_NUMBER, Symbol 'LEDS_NUMBER' could not be resolved.

Not sure if it's useful, but there are also warnings for the following:

[Mike W]

`Invalid project path: Include path not found (blinky_pca10040#undef __ARM_FEATURE_FMA). blinky_pca10040 pathentry Path Entry Problem

Invalid project path: Include path not found (blinky_pca10040#undef __ARM_FP). blinky_pca10040 pathentry Path Entry Problem

Invalid project path: Include path not found (blinky_pca10040#undef ARM_NEON). blinky_pca10040 pathentry Path Entry Problem

Invalid project path: Include path not found (blinky_pca10040#undef __ARM_NEON_FP). blinky_pca10040 pathentry Path Entry Problem

Invalid project path: Include path not found (blinky_pca10040#undef __ARM_NEON). blinky_pca10040 pathentry Path Entry Problem

Missing "C:\Users\Michael\Documents\Dev\Eclipse\Packages.cache\wolfSSL.wolfSSL.3.9.0.pdsc", ignored by user request.`

[Mike W]

Aside from the Makefile workarounds in the original question OR just using Vidar's updated project, the solution was to manually create a virtual folder and import all the resources Eclipse was looking for from components in the SDK, then rebuild the indices.

Thanks Vidar for all the help!

[Nguyen Hoan Hoang]

try this blog

[Mike W]

Thanks again for the help. There are actually fewer errors, fortunately. No Makefile errors anymore and only the include errors and LEDS_NUMBER for the c++ file. The thing actually builds if I replace LEDS_NUMBER with "4", but the problem is the unresolved includes at this point.

Before, it wasn't connecting to the Nordic header files at all, seemingly related to that weird multiple Devices and Toolchains tabs behavior - it must have been using the one that didn't even give that option. I've been in touch with the MCU-Eclipse folks who have no idea what that is, either.