can't find core_cm0.h?

[akohlsmith]

I'm almost certain it's something I've buggered up but I can't seem to figure it out.

I've installed the SDK, I've pointed SDK_PATH over to it ( $(HOME)/Keil/ARM/Device/Nordic/nrf58122 ) and got the toolchain path set up correctly. I'm just using the blinky_example from the SDK for now.

gcc goes to build the first of the source files and explodes because the SDK headers can't find core_cm0.h. Now I do have core_cm0.h, but it's not in the SDK path. I see it in Keil/ARM/Pack/ARM/CMSIS/3.20.3/CMSIS/Include/core_cm0.h. The Readme.md suggests that if I have everything set up correctly I shouldn't have to modify the compiler search paths, so I'm wondering what I've done wrong.

Did I mis-install the SDK?

[eliotstock]

Isn't that header in your gnu arm gcc eabi path somewhere? That dir should be on your include path if it isn't already. On 8 Jun 2014 15:00, "Andrew Kohlsmith" notifications@github.com wrote:

I'm almost certain it's something I've buggered up but I can't seem to figure it out.

I've installed the SDK, I've pointed SDK_PATH over to it ( $(HOME)/Keil/ARM/Device/Nordic/nrf58122 ) and got the toolchain path set up correctly. I'm just using the blinky_example from the SDK for now.

gcc goes to build the first of the source files and explodes because the SDK headers can't find core_cm0.h. Now I do have core_cm0.h, but it's not in the SDK path. I see it in Keil/ARM/Pack/ARM/CMSIS/3.20.3/CMSIS/Include/core_cm0.h. The Readme.md suggests that if I have everything set up correctly I shouldn't have to modify the compiler search paths, so I'm wondering what I've done wrong.

Did I mis-install the SDK?

— Reply to this email directly or view it on GitHub https://github.com/hlnd/nrf51-pure-gcc-setup/issues/11.

[akohlsmith]

sadly no. I am using the "GNU Tools for ARM Embedded Processors" from https://launchpad.net/gcc-arm-embedded/ for OSX. (It seems a little funny that I've downloaded an OSX binary from launchpad.net.)

core_cm0.h is not anywhere in the directory tree that came from the tarball, and I don't see a "supplementary" archive which might include additional headers.

[eliotstock]

OK, strange. I'll find that header on my machine in a few hours and let you know where it's come from. On 8 Jun 2014 15:08, "Andrew Kohlsmith" notifications@github.com wrote:

sadly no. I am using the "GNU Tools for ARM Embedded Processors" from https://launchpad.net/gcc-arm-embedded/ for OSX. (It seems a little funny that I've downloaded an OSX binary from launchpad.net.)

core_cm0.h is not anywhere in the directory tree that came from the tarball, and I don't see a "supplementary" archive which might include additional headers.

— Reply to this email directly or view it on GitHub https://github.com/hlnd/nrf51-pure-gcc-setup/issues/11#issuecomment-45437641 .

[akohlsmith]

Thank you, I appreciate it. There is a repository on github (github.com/Sproutling/nRF51822-OSX-Sample) that includes a a codesourcery toolchain and that does have a core_cm0.h which appears to be part of the SDK (./lib/nRF51_SDK_v4.0.1.22983/Nordic/nrf51822/Include/gcc/core_cm0.h), so I think again that I may have mis-installed the thing.

[eliotstock]

Right, that header is indeed in my Nordic SDK under nrf51822/Include/gcc. If it's not there in the SDK you have under your Keil directory, I'd grab the zip again from nordicsemi.com (search nRF51-SDK-zip, there's also an .msi which you don't want for Mac of course) and put it somewhere outside Keil.

Eliot

On 8 June 2014 15:28, Andrew Kohlsmith notifications@github.com wrote:

Thank you, I appreciate it. There is a repository on github (github.com/Sproutling/nRF51822-OSX-Sample) that includes a a codesourcery toolchain and that does have a core_cm0.h which appears to be part of the SDK (./lib/nRF51_SDK_v4.0.1.22983/Nordic/nrf51822/Include/gcc/core_cm0.h), so I think again that I may have mis-installed the thing.

— Reply to this email directly or view it on GitHub.

[akohlsmith]

That was it; just taking the .zip and expanding it somewhere, then pointing the Makefile to the nrf51822 subdirectory within it worked without any issue. Thank you!

[nocko]

I update my template files from an earlier version of this repo and I had a similar problem:

arm-none-eabi-gcc --specs=nano.specs -mthumb -mcpu=cortex-m0 -march=armv6-m -L ./template/ -T gcc_nrf51_s110.ld -Wl,-Map=_build/c3beacon_s110.Map -Os -g -Wall -DBLE_STACK_SUPPORT_REQD -std=gnu99 -c -mthumb -mcpu=cortex-m0 -march=armv6-m -Wall -DNRF51 -D -I/home/nock/devel/NRF/nrf51822/Include/gcc -I. -I../ -I/home/nock/devel/NRF/nrf51822/Include/ -I/home/nock/devel/NRF/nrf51822/Include/sdk/ -I/home/nock/devel/NRF/nrf51822/Include/ble/ -I/home/nock/devel/NRF/nrf51822/Include/ble/ble_services/ -I/home/nock/devel/NRF/nrf51822/Include/ble/device_manager/ -I/home/nock/devel/NRF/nrf51822/Include/s110 -I/home/nock/devel/NRF/nrf51822/Include/app_common/ -I/home/nock/devel/NRF/nrf51822/Include/sd_common/ -MD /home/nock/devel/NRF/nrf51822/Source/templates/system_nrf51.c -o _build/system_nrf51.o
<command-line>:0:1: error: macro names must be identifiers
In file included from /home/nock/devel/NRF/nrf51822/Include/nrf51.h:119:0,
                 from /home/nock/devel/NRF/nrf51822/Include/nrf.h:37,
                 from /home/nock/devel/NRF/nrf51822/Source/templates/system_nrf51.c:36:
./core_cm0.h:127:95: fatal error: core_cmInstr.h: No such file or directory
 #include <core_cmInstr.h>                /* Core Instruction Access                         */
                                                                                               ^
compilation terminated.

The file is in $(CMSIS_INCLUDE_PATH) and that's added to the search path as seen above. How it could be path and not found was beyond me. Diffs of the makefiles show that very little has changed, and nothing to do with CMSIS_INCLUDE_PATH.... but I eventually found that the error was caused by not having BOARD defined in the makefile. The "no such file" is a red herring, the key error was: error: macro names must be identifiers .

I develop with in-house boards and removed that line ages ago... I fixed it at the time by checking if BOARD is defined. I'll submit a pull-request for the change.