Using Eclipse for nRF51 Development: Getting off Makefile and into Managed Make

Tags

Eclipse

UPDATE November, 2015

Guess what I found?  We can export the include file paths and CFLAGS and then import them into another workspace.  Wow – what a time saver!

There are two ways to get to this dialog box:

• File/Export…
• Properties->C/C++ General->Paths and Symbols->Export Settings button (keep the tab on Includes)

YIPPEE!!!

Thanks To Those That Went Before 

 

 Thanks to Chris Gammell’s Contextual Electronics course, I got to see the advantage of using the CDT’s managed make feature over using Eclipse with a standalone makefile.  Basically, as I discussed in this post, to use the nRF51 SDK with Eclipse, I modify makefiles that came with examples from the nRF51 SDK.  I was going to continue along this path.  After all, I just want to build, program the nRF51822, and debug.  Do I really need to become a Make expert?  Probably not.  But I do see an advantage in simplifying the toolchain since now Eclipse is handling these tasks.

The Goal

The goal is to build and debug the Blinky nRF51 SDK example within a Eclipse managed make project.  Note: there are a few more “things” that need to be done to use with the BLE soft device stack.  I’ll probably cover that in my next post.

Why Bother

An Eclipse project with managed make is much better integrated into the Eclipse environment.  There are many advantages.  The obvious one is I don’t have to maintain two build environments – the info Eclipse needs and then constantly updating the makefile.  Also, once I got the hang of the Nordic makefiles, I noticed many similarities that I could put into a managed make and then reuse.

It would be best if Nordic created templates that can be used to start a “Hello World nRF51, no BLE” and “Hello World nRF51, SOFTDEVICE110” (etc. on the remaining soft devices).  However, this is – unfortunately – not available.

Thanks To Those That Went Before

Thanks to Chris Gammell for including an Embedded Systems section within Contextual Electronics.  The combination of learning on my own and while going through projects with more skilled instructors is very valuable in scoping what I need to learn to successfully apply to my projects.

I am thrilled Chris Gammell’s Contextual Electronics has started modules on Embedded Systems.  Chris found excellent folks – Ronald Sousa and Eric Hankinson – to be our instructors.  Incredible to me, they were able to set up a virtual environment that transcends whether we are on a Mac, Windows, or other operating system.  We can then work together within an identical environment.  It is truly impressive how they set the environment up.  

Thanks to Doug Schaefer for co-leading the Eclipse CDT project.  Eclipse is a very rich IDE for embedded systems.  It amazes me how much care, time, and effort Doug and other folks on the Eclipse team spend to make it easier/better to develop code for SOICs like the nRF51822.

Thanks to Vidar Berg (Nordic employee) for posting a very helpful post: “Development with GCC and Eclipse“

The Steps

Without more discussion, I’m documenting the steps…heck, it only took me two days to figure out (down from a week that it took me to figure out the stuff I covered in this post 🙂 ).  I am assuming you have enough familiarity with Eclipse (or can Google to find out) to know what I am referring to within the steps. Click on the images to view a larger/more readable image.

1. Install Eclipse with the right gnu arm toolchain goo.  I covered how I did this here.  

2. Create a new C Project.

3. Choose the Hello World ARM C Project

After entering a project name and choosing next, the Basic Settings dialog box is displayed:

 I delete the Linker semi-hosting options based on what I learned about semi-hosting (see this post).

 4. Go into the project’s property page C/C++ Build->Settings->Tool Settings  (I think I cover doing this in detail in this post) and set the target processor to cortex-m0

5. In this step I started mapping what was going on in the Blinky makefile into the build property pages.  The easiest way for me was to load the Blinky makefile into a text viewing project – I used TextEdit on my Mac.   The Blinky makefile comes with the Blinky example within the PCA10028 /blank/armgcc folder.

6. Note the CFLAGS:

CFLAGS = -DNRF51
CFLAGS += -DBOARD_PCA10028
CFLAGS += -DBSP_DEFINES_ONLY

The first one identifies the chip.  The second two are used by the code interacting with the nRF51 DK, where the CFLAG BSP_DEFINES_ONLY is used when the LEDs are used.

Other CFLAGS that I have used when BLE is included:

S110
SOFTDEVICE_PRESENT
BLE_STACK_SUPPORT_REQD
SWI_DISABLE0

7. Go to same Tool Settings properties page as in the earlier step and click on the Preprocessor property under Cross ARM C Compiler.  Add these defined symbols.

 

8. Now let CDT know about the location of the include files. The makefile lists the following include paths:

INC_PATHS = -I$(abspath ../../../../../../components/toolchain/gcc)
INC_PATHS += -I$(abspath ../../../../../../components/toolchain)
INC_PATHS += -I$(abspath ../../..)
INC_PATHS += -I$(abspath ../../../../../bsp)
INC_PATHS += -I$(abspath ../../../../../../components/device)
INC_PATHS += -I$(abspath ../../../../../../components/drivers_nrf/hal)

 I added the include paths into the includes property page using the ${workspace_loc} environment variable to simplify entering the path info.

9. Checking the Optimization property page, I noted the “default” was C11, but the blinky makefile used C99, so I changed the language standard to C99.  I am not skilled enough in what issues would arise if I had left it with the default.  I did this to mimic the makefile.

10. The Linker script – blinky_gcc_nrf51.ld – needs to be incorporated into the build.  Copy the script over to the Eclipse project folder.  It will then show up in Eclipse’s Project Explorer.  Go to the Linker properties page.  Add the file to the script files list. I did this by looking at the environment variables and noting ${ProjDirPath} expands to the Eclipse Project folder:

UPDATE: instead of hard coding to the name of the script file (in this case blinky_gcc_nrf51.ld), use the ProjName build variable. So the -T entry is ${ProjDirPath}/${ProjName}.ld

Here’s the property page to enter Linker script location info:

 

Here is the contents of the bliny_gcc_nrf51.ld that I have:

/* Linker script to configure memory regions. */

SEARCH_DIR(.)
GROUP(-lgcc -lc -lnosys)

MEMORY
{
FLASH (rx) : ORIGIN = 0x0, LENGTH = 0x40000
RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 0x8000
}

INCLUDE “gcc_nrf51_common.ld”

note the script includes gcc_nrf51_common.ld.  To resolve this reference, go into the Libraries property page and add a path under the -L entries:

 11. set the map file location:

12. Add the system files. Copy the files: ..\components\toolchain\system_nrf51.c, ..\components\toolchain\system_nrf51.h, and ..\components\toolchain\gcc\gcc_startup_nrf51.s into the project folder.   Then (and this seems weird to me), I had to upper case the s on the gcc_startup_nrf51 assembly file, i.e.: rename to gcc_startup_nrf51.S .

Eclipse needs to be told to look in the project folder.  To do this, go to the property page at C/C++ General ->Paths and Symbols->Source Location and add the project location to the build path:

  

13. Go to file manager and delete main.c in the src folder of the workspace.  Copy the main.c from the blinky example.

14.  Go to Run-> Debug Configurations…   and double click the GDB SEGGER J-Link Debug configuration to create a debug instance for the project.

Run Debug.  

 

And that’s it.  It should be working. 🙂

Sometimes Debugging Doesn’t Work

 I tried repeating the above steps a few times.  Occasionally, I couldn’t get into line level debugging of main.c.  I wondered if it was similar to the problem I had earlier with Build Variables so I added step 11 above (put the full path to the map file location).  As I learn more I’ll update this post.

 

 

 

Thanks for reading this far.

Please find many things to smile about.