Set up project directory structure.I prefer and will use one main PROJECT folder as a base folder and do everything within it. E.g. on my windos computer that would be c:\projects\nRF51-project\, under linux I would clone into /home/user/projects/nRF51-project/. Since we are talking GCC + Eclipse here, both are cross-platform and everything can be done relative to the base path.
- Install GNU ARM Embedded Toolchain (arm-none-eabi) from their distribution site. Nordic for some reason seems to like 4 series (specifically 4.9.3 as defined in GCC configuration), but I've been running SDK verisons 8 and 10 on toolchain version 5.4.1 just fine. I would recommend installing toolchain in a location which does not contain spaces, dots and other fancy stuff in the path, such as "C:\tools\gnu-arm\4_9_3\" to avoid path and folder name issues. Make sure that installation is added to the system path. To check that it did actually happen, try starting a new command line and then executing: this should return something similar to:
- Download latest SDK. According to release notes , version 13.0.0 dropped support for nRF51 series, so we are stuck with 12.2.0. Download that and unpack it somewhere, I'll use PROJECT\SDK\12.2.0\ folder for it.
- Once unpacked, open PROJECT\SDK\12.2.0\components\toolchain\gcc\Makefile.<your_system> file (where <your_system> refers to "Windows" in obvious case or "posix" in case of any *nix system) and change paths to your gcc installation:
Above output means that toolchain has been installed and added to the path successfully and you can compile stuff anywhere in the system without the need to use full toolchain path for each execution.
- This should make the examples compileable. All the compiling stuff for now we'll do in CLI (command line interface). So start it up and change directory to a BLE HRS (heart rate service) example gcc folder and try compiling it:
If you did everything correctly, you should see a bunch of messages:
Note that I'm using pca10028 development board, which is supposed to have nRF51422 on it. Other example options are for pca10040 (with nRF52832 on) and pca10056 (with nRF52840 on). As far as I understand, setup so far is identical for all of these platforms.
Aaaanyhow, _build folder now should contain your .hex file (mine is nrf51422_xxac.hex), which you can flash onto your device. More details about flashing in a bit.
If you did mess up somewhere along the line, then you might see an error message:
In this case verify that you have ARM toolchain installed and available in path, by executing right where you are:
If this command does indeed return correct toolchain version, then double check Makefile.<system_type>.
FlashingFor flashing firmware + softdevice Nordic has released nRF Go Studio, a nice little piece of software, which allows you to identify your chip and program different memory regions. Sadly, their software is not the most fastest nor reliable. For me it just crashes, when I try to use it. As an alternative there's also nrfjprog CLI tool, which seems to be more stable, but is somewhat limited in functionality. Luckily, it's all just a pretty shell around Segger's JLink. You can either download that directly or get latest set of nRF5x-Command-Line-Tools. I'll be sticking with JLink/JLinkExe for now. To start it up just type jlink in Windows or JLinkExe in Linux. It might ask to which device you would like to connect, if multiple are present or silently connect to the first one:
To connect to the target chip and flash it, a following series of commands has to be issued:
You can also save this as a script in flash.jlink file and avoid retyping it, by running this script:
To compile example code for any other chip than 51422_XXAC (822 or AA or what have you), you have to:
- change ble_app_hrs_gcc_nrf51.ld script memory definitions to your chip specific. I have 51822 QFAA, so my memory mappings are:
- change "device" statement in flash script
- change Makefile. Pretty much everywhere where you can find replace chip with your particular. Some places matter more than other (compiler/linker params, (-DNRF51822)), but change all, to avoid confusion. Just be consistent.
That's all for now. Maybe in the future there'll be some debugging stuff as well