• State Verified Answer
  • Locked Locked
  • Replies 12 replies
  • Subscribers 67 subscribers
  • Views 8705 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 103139
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Modern GCC and Eclipse environment for NRF51

Elena

Hi

Let's see if you can help me :-)

I've spent several days trying to compile the blinking example for NRF51822 in a more modern Eclipse environment. In fact, latest SDK versions of Nordic don't include the Eclipse project, only the Keil files. I can't understand this decision, mostly when Eclipse is one of the best dev environment in nowdays. Anyway, I've been trying to compile the included GCC example by clicking the .bat files, but with no sucess: The generated .hex file doesn't work. :-(

The NRF51 SDK v4 includes an Eclipse example, but using manual makefiles, and in the other hand, the generated .hex file doesn't work. Must be noticed that I'm using Yagarto 20121222, with GCC 4.7.2.

So, I've decided to create a more modern GCC environment using Eclipse, but I'm having problems with the startup files:

  1. When not using the -nostartfiles option, the generated .hex files has 93K, instead of 3K like the equivalent file generated by Keil. Of course, it doesn't work :-(. When trying to debug it, I lost the trace at _start call in the gcc_startup_nrf51.S. At this point, the execution jumps to crt0.o file, and I don't have the source. In fact, the crt0.o file weren't included by the latest Yagarto, but I get it from a previous version.

  2. When USING the -nostartfiles option, I get a problem in the gcc_startup_nrf51.S:

    D:\gcc\ble_app_hrs\Debug/../Platform/gcc_startup_nrf51.S:181: undefined reference to `_start'

So I think that the problem must be related to the crt0.S or crt0.o file. Using the -nostartfiles option together to the correct crt0.S should fix the problem. It is right?

What can I do? Any suggestion? I include an screenshot of the error, and the Eclipse environment. In case I finally fix the problems, I'll document and post the new Eclipse environment as alternative of Keil projects.

Thanks you in advance

Cheers,

Elena

image description ble_app_hrs.rar

  • 0

    Good luck with this; I hope you get it working [and share how you did it ;)]. You might find this thread on the mbed forums useful (some people talking about how they got the nRF51822 examples working with gcc). mbed.org/.../

    EDIT: I don't know how useful this will be to you, but here's a link to a long description of the efforts made by a guy in the thread I linked about about compiling for nRF51822 with gcc: github.com/.../337

  • 0

    Hi Jimi!

    Thanks you a lot of. I saw the link you say in your second post, but not the others. Anyway, after checking them I don't see more clues to continue. They are stuck in a point very similar to mine. So I don't know how to follow...

    Thanks you again.

    Cheers

    Elena

  • 0

    Hi,

    I started installing the GNU Toolchain yesterday from the sources, so we don't have exactly the same environment, yet I faced the same problem. For the records, so far, I've got:

    • binutils-2.24
    • newlib-1.20
    • gcc-4.9.0

    So, no IDE for now. But, obviously, the problem has nothing to do with eclipse...

    I'm nothing like a libc(newlib) internals guru, so there might be some misleading clues in the following lines. My apologies in advance. This is how I understand the startup process:

    When using the standard C runtime library startup files, the very first entry point is crt0 which performs very low-level initialization. Then comes the crt1 and the _start() function. AFAK, the goal of _start() is to call main() with its required parameters, and then _exit(), to avoid a segmentation fault on program termination and pass the main() exit code to the OS.

    In the case of the blinky_example, we have a pure bare metal project: no OS, no need to copy the code to the RAM before executing it, no parameters to main and no return value as the main is an infinite loop.The startup code is located in gcc_startup_nrf51.S which takes the role of crt0 and tries to call a _start() function which doesn't exit, because it is not needed.

    So, to make a long story short, I finally decided to replace the call to _start() by a call to main() and I got my LEDs blinking. I hope I haven't broken other projects depending on the same startup file; It would probably have been cleaner to implement a _start() function to call main().

    Anyway, I will be trying some more examples and we'll see what happen.

    I hope that helped :) Any comments appreciated

    Best regards,

    Vince

Related