Developing nRF51 & nRF52 series software using Eclipse

Bluetooth® Low Energy SoC

I have been building BLE applications using Nordic’s popular nRF51822, nRF51422 & nRF52832 series ultra low power System on Chip (SoC).   It integrates the nRF51 series 2.4GHz transceiver, a 32 bits ARM® Cortex-M0 MCU, Flash memory, analog and digital I/O, supporting both Bluetooth Low Energy, ANT and proprietary protocols.  The nRF52 series sports a Cortex-M4 MCU.  It took me longer than I would have liked to get the development, debug, and build environment up and running on my Mac.  I hope this post gives you insight into the lessons I learned along the way - saving you precious time along the way.

The hardware used in my project are the IMM-NRF5x series modules and CMSIS-DAP Debug JTAG programmer for debugging.  The one in the picture bellow integrates an nRF51822 with all available I/O are routed out to the pads.  The pads are both through hole and SMT so that it can be easily prototype any application and SMD in for production.  There are 3 modules IMM-NRF51822, IMM-NRF51422 and IMM-NRF52832.  They are all pin compatible, though you can use any module interchangeably on your PCB.

Available on CrowSupply

Available at Mouser

Available on CrowSupply

IMM-NRF52832 module 23 x 17 mm with 30 I/O 
IMM-NRF52832-NANO ultra small 10 x7 x 1.6 mm

Available on

On Tindie

The software development environment with Eclipse & GCC

While there are several IDE options, I chose the Eclipse IDE because it fully free and available cross platforms Windows, OS X & Linux.

  • Follow the Eclipse page on this blog to setup the Eclipse development environment for ARM.   
  • Clone the EHAL source tree.   This can be done using git command line tools or use SourceTree from this site  github :
  • Download the Nordic Bluetooth SDK from Nordic Semiconductor.  
  • Put the SDK in the appropriate folder as indicate bellow. 
  • Download the CMSIS SDK, follow the EHAL page to download and setup the environment.
Note : New library is IOsonata.  It is the new refactored EHAL.  New drivers will be implemented in this new library.  EHAL is still being maintained for bug fixes only.  It is recommanded to use IOsonata for new projects.

The  development source tree should look like bellow :

/your_root     - Development root directory
 |-- external    - Contains downloaded SDKs from silicon vendors
 |   |-- CMSIS            - ARM CMSIS SDK for all ARM platform (download from ARM)
 |   |   |--CMSIS
 |   |   |...
 |   |-- nRF5_SDK_12    - Nordic SDK 12.3, nRF51 & nRF52 (download from
 |   |   |   |-- components
 |   |   |   |-- examples
 |   |   |   |-- external
 |   |   |   |   |--- micro-ecc
 |   |   |   |   |   |--- micro-ecc - Micro-ECC (download from
 |   |   |   |...
 |   |.... 
 |   |-- nRF5_SDK    - Latest Nordic SDK 15.3, nRF52 only (download from
 |   |   |   |-- components
 |   |   |   |-- examples
 |   |   |   |-- external
 |   |   |   |   |--- micro-ecc
 |   |   |   |   |   |--- micro-ecc - Micro-ECC (download from
 |   |   |   |...
 |   |-- BSEC - Bosch Sensortec Environmental Cluster (BSEC) Software (
 |   |....
 |-- EHAL      - Put the EHAL here
 |   |-- include     - Generic include common to all platform
 |   |-- src            - Generic source common to all platform
 |   |-- ARM
 |   |   |-- include    - Common include for all ARM platform
 |   |   |-- src           - Common source for all ARM platform
 |   |   |-- Nordic
 |   |   |   |--include - Common include for all nRF5x 
 |   |   |   |--src        - Common source for all nRF5x
 |   |   |   |-- nRF51 - Nordic nRF51x22 Target
 |   |   |   |   |-- CMSIS   - static library of CMSIS system functions for nRF51
 |   |   |   |   |-- EHAL    - Embedded Hardware Abstraction Library project for Nordic nRF51 (static lib)
 |   |   |   |   |   |-- include
 |   |   |   |   |   |-- src
 |   |   |   |   |-- exemples - exemple projects
 |   |   |   |   |   |--dfu      - SDK12 Secure DFU 
 |   |   |   |   |...
 |   |   |   |-- nRF52 - Nordic nRF52xx Target (except nRF52840)
 |   |   |   |   |-- CMSIS   - static library of CMSIS system functions for nRF52
 |   |   |   |   |-- EHAL    - Embedded Hardware Abstraction Library project for Nordic nRF52 (static lib)
 |   |   |   |   |   |-- include
 |   |   |   |   |   |-- src
 |   |   |   |   |-- exemples - example projects are in here
 |   |   |   |   |   |--dfu      - SDK13 Secure DFU 
 |   |   |   |   |...
 |   |   |   |-- nRF52840 - Nordic nRF52840 Target
 |   |   |   |   |-- CMSIS   - static library of CMSIS system functions for nRF52840
 |   |   |   |   |-- EHAL    - Embedded Hardware Abstraction project for Nordic nRF52840 (static lib)
 |   |   |   |   |   |-- include
 |   |   |   |   |   |-- src
 |   |   |   |   |-- exemples - example projects are in here
 |   |   |   |   |   |--dfu      - SDK13 Secure DFU 
 |   |   |   |   |...
 |--- private   - your own private working folder
Start Eclipse and set the Workspace to your private folder.  Select the 'import'  to import CMSIS and EHAL projects into the workspace.  Do the import project without copying files since it is already located inside the workspace.

Require change to compile the SDK with GCC in the file nrf_svc.h.  This file is located in headers folder of each Softdevice.  Nordic default cast was uint8_t.  This is wrong it needs to be casted cot uint16_t

        "bx r14" : : "I" ((uint16_t)number) : "r0" \

Cast (uint16_t) is needed if you compile C++ code.  The default startup code from the SDK does not work with C++.  Use the one from EHAL.  See example code for details.

Now you can start creating projects.  To create Eclipse projects for nRF51, follow the steps further down this page.

Migrating to SDK 12  

The new nRF5 SDK12 has changed a lot. There are many compile error for GCC with C++.  The extern "C" { was added to most .h files now but you may find compile error du to the fact that the opening was placed within a conditional define and the ending was outsite or vice versa.   The SDK also contains ridiculous conditional compilation in every source files.  By adding the source file to your project is not sufficient.  You need a also add those defines for each source.  So depending on how many sources you are using from the SDK.  You may ended up with hundreds of conditional compilation defines.  The EHAL lib is already updated to SDK12.  I am updating gradually the examples to SDK.  It will take some times to get all updated.

Compile bug in SDK14

File fstrorage.h in components/libraries/fstorage folder needs to be changed as follow :

line 115 : typedef struct nrf_fstorage_api const nrf_fstorage_api_t;
line 144 : nrf_fstorage_api_t * p_api;
line 174 : struct nrf_fstorage_api
line 188 : };

This bug is fixed in SDK15

CMSIS library

The CMSIS library project now includes build for RTX kernel in the build configurations.  Precompiled libs are available in github.  The default initialization of RTX version was modified to use RC oscillator so it can start on any nRF5x without the 32KHz Crystal.  The default RTX build from Nordic requires the 32KHz crystal to run.

Examples code :

Most of the examples code on this site are not Nordic examples.  They are written from scratch targeted to use with the IMM-NRF51822 module (see Hardware section bellow) and generic board.  To compile the examples, you need first compile the CMSIS library, few examples may need the EHAL library.  All BLE examples have accompanying iOS code as well.  iOS code is here :

The Blinky_ble exemples is not actually to make the LED blink.  It is a custom service example that uses the iPad to configure the Gpio as input or output, turn it on/off, read it state. All 30 i/o can be controlled at once or individually.  Now SDK 8.

dfu_nrf51 is now the Eclipse project for SDK 8 DFU.  It contains only project file.  Source code are not in github.  Project has virtual link to source files in nrf51_sdk folder except for main.c and incude folder which need to be copy from the sdk sample over to DFU project folder.

dfu_sdk7 is the DFU Eclipse project for SDK 7.2.  Dfu BLE is now functional with iOS nRFToolbox 1.5.  Dfu Serial does not seems to work with nRFGo.  Currently I am too busy to debug it.  Let me know if you can get it to work in serial mode.

The LMXDisplay_ble is an example demonstrate the use of long write characteristic.  It gets a text message from a mobile device and  displays it on LED matrix multi-displays.  The LedMx library is used to control display on multiple IDM-LMX3208 series LED matrix display (See my Arduino page for more details).  The display controller is the IBB-LMXBLUE, which can dive up to 16 displays boards.

Different UART over BLE example than the one from Nordic.  This example uses only one characteristic for both TX and RX.  Uses app_uart API rather than simple_uart.

To create an Eclipse based project for nRF5x, see instruction at the end of this page.

Flashing the nRF51 & nRF52 

Nordic provides utilities to flash the nRF5x but those utilities only work with the JLink.   The Nordic development kit has an on board JLink that can be used to flash other board.  It can not be used to flash commercial products due to its usage license.  For commercial use, you need to buy the full JLink which is very expensive.   This section presents several methods to flash using the much cheaper alternative without a limited usage license.

Parallel gang Flashing nRF51 & nRF52 with IDAP-Link using IDAPnRFProg on OS X and Windows

IDAPnRFProg now allows flashing just Softdevice or combines with either app firmware and/or DFU.

IDAP-Link/M Software Download now support readback protection.  Available for OS X and Windows XP and above.

PM me if you need Linux version

Flashing Softdevice + Firmware + DFU

IDAPnRFProg s110_nrf51822_7.1.0_softdevice.hex Blinky_ble.hex dfu_sdk7.hex

$ ./IDAPnRFProg s110_nrf51_8.0.0_softdevice.hex Blinky_ble.hex dfu_nrf51.hex
IDAPnRFProg version 0.2
Copyright 2015, I-SYST inc. All rights reserved

Found IDAP-Link - S/N : 0000000000001
Found IDAP-Link - S/N : 0000000000002
IDAP-Link-0030415000005 : nRF51822-QFAA R2, Rev.2, HWID = 0x003C, DEVID = 0x299C1D17BD361134
IDAP-Link-0030415000005 : Flash size = 262144, Ram size = 16384
IDAP-Link-0030415000017 : nRF51822-QFAA R1, Rev.1, HWID = 0x001D, DEVID = 0x32B4DDFECEE22394
IDAP-Link-0030415000017 : Flash size = 262144, Ram size = 16384

IDAP-Link found : 2

IDAP-Link-0030415000005 : Erase Flash
IDAP-Link-0030415000017 : Erase Flash
IDAP-Link-0030415000005 : Blank checking...
IDAP-Link-0030415000017 : Blank checking...
IDAP-Link-0030415000005 : Programming...
IDAP-Link-0030415000017 : Programming...
IDAP-Link-0030415000005 : Firmware start address 0x18000
IDAP-Link-0030415000005 : DFU start address 0x3c000
IDAP-Link-0030415000017 : Firmware start address 0x18000
IDAP-Link-0030415000017 : DFU start address 0x3c000
IDAP-Link-0030415000005 : Programmed 256 KB in 21.524 sec at rate 11.894 KB/s
IDAP-Link-0030415000005 : Verifying...
IDAP-Link-0030415000017 : Programmed 256 KB in 21.524 sec at rate 11.894 KB/s
IDAP-Link-0030415000017 : Verifying...
IDAP-Link-0030415000005 : Flashing succeeded.
IDAP-Link-0030415000017 : Flashing succeeded.

Total Flashed 2 nRF51 devices in 51.112 sec, 1024 KB R/W transfered, rate = 20.035 KB/s

Flashing nRF5x using microSD card with IDAP-Link

Prerequisite :

Prio to use this Flashing method.  The IDAP-Link must set to nRF51 target.  Use the IDAPSetTarget command line program to set it.  Executing IDAPSetTarget without any argument will show a list of available target core.  Then execute IDAPSetTarget again with the nRF51 target index number to set it.  This is needed to be done only once.  IDAPSetTarget is needed again only when target change is needed.  The IDAP firmware can only recognized predefined file name when Flashing with this method.  File naming is preset by the target definition.  For nRF51 file name must be as follow:

Softdevice.hex - for softdevice
firmware.hex - Application firmware
DFU.hex - OTA Bootloader

It is not require to have all 3 files to flash.  Copy the require files onto a microSD card.  Insert it in the IDAP-Link.  Power the IDAP-Link.  Press ISP/Program button.  The green LED will light up.  When Flashing is done, all LED are off if successful.  Blink red LED if failed.  If the IDAP-Link is still connected to PC, make sure to eject USB MSC from the PC for better Flashing performance.  Normally it should take about 26s to flash all 3 hex files.  If the USB MSC is not ejected from the PC, it may take a lot longer depending how much access the PC is performing on the microSD.  It is due to PC access has priority over the internal access.

Flashing softdevice with OpenOCD.

Using low cost alternative IDAP-Link.  You can flash the softdevice using OpenOCD command.  Version 0.9 is require.  To install latest OpenOCD on OS X using the command

brew install --HEAD openocd

Then flash Softdevice with

openocd -f interface/cmsis-dap.cfg -f target/nrf51.cfg -c "program s110.hex verify"

Unlock nRF52 protection using OpenOCD

openocd -f interface/cmsis-dap.cfg -f target/nrf52.cfg -c "program dap apreg 1 0x04 0x01"

Eclipse debugging using IDAP-Link with OpenOCD

Create an OpenOCD debug configuration.  Set the OpneOCD config option in the Debuger tab with :

-f interface/cmsis-dap.cfg
-f target/nrf51.cfg
-c "cmsis_dap_serial ###"

where ### is the serial # of IDAP-Link to use when multiple IDAP-Link are connected to the same PC (see IDAP-Link page for more details)

Debug JTag connection

The IMM-NRF51822 micro-module has exposed the SWD (Serial Wire Debug) pins SWDIO & SWCLK, see I/O layout picture above. The module can be directly connected to a Jtag tool for development by wiring the 2 SWD pins to the appropriate pins on the Jtag connector. The VIN must be wire to the VCC pin on the Jtag. GND pad is also require to be connected to GND on Jtag.  The default JTAG supported by Nordic is the Segger.  Other low cost option is using CMSIS-DAP JTAG such as the IDAP-Link.  The IDAP-Link can also be used for production flashing multi-boards in parallel.  See IDAP-Link page for details.

IMM-NRF51822 mounted on breakout board connected to the IDAP-Link.
3.3v power is provided by the IDAP-Link.

Creating Eclipse project

To create a new nRF51 project with Eclipse, select New from the File menu then select either you want C or C++ project.  In the dialog, select the project type 'Hello World ARM ..." with toolchains 'Cross ARM GCC'.  Do not use any other templates.

Once the new project is created, open project settings dialog.  Change the target processor to Cortex-M0 for nRF51 and Cortex-M4 for nRF52

Set target processor to cortex-m0

There are a few preprocessor definitions require by the SDK.  If BLE stack not needed, only NRF51 or NRF52 is required.  If BLE stack is needed, the following are required


Preprocessor settings

In case of a C++ project, those preprocessor settings are also needed to be set in C++ preprocessor section.  Next are the include path settings.  Assuming the SDK is located in nrf51_sdk as described previously.  These are the minimum require include paths for BLE project.

For SDK 6 :


For SDK 8, the way the folders are organized is the worst.


For SDK11


There are a few to set in the linker settings as well.  First thing is the linker script.

for BLE project


Non BLE project


Linker settings
Require libraries and path in linker setting.  Minimum require is the CMSIS lib.  Set the library path to

"${ProjDirPath}/../../CMSIS/Debug"  - Debug build
"${ProjDirPath}/../../CMSIS/Release" - Release build

Optionally if EHAL is used, add EHAL to the lib and path


Library & path for the linker

That's about it for project settings.  What's left to do is to add source code in the project.

Add source files

There are many files to be added to the project depending on what is require for the application.  One file must always be added to all projects is the Vector_nRF51.c.  It is located in scr folder in the nRF51 workspace.  It is the interrupt vector and the reset function.  It can be added by doing import then chose filesystem.


  1. Hi Hoan,
    Need to know what versions of softdevice and bootloader are shipped on the IMM-NRF51822 module to get back to a baseline. I purchased this module and an IDAP-LINK for project development, I successfully used IDAPSetTarget and IDAPnRFProg_1_2_170726, but after programming no BLE is discovered and "DFUTarg" is no longer discovered. I need to restore IMM-NRF51822 back to as hipped condition so I can troubleshoot.
    Thanks Roy

    1. Hi,
      The modules are shipped empty. You probably had a very old version which is no longer supported. You can use the latest Nordic SDK 12. The Softdevice is provided with the SDK. The DFU source is provided in the Nordic SDK. An Eclipse native project to compile the DFU is available via Github link at the top of the page.

    2. Hi Hoan, I got the Eclipse Mars environment setup and can compile both your sample apps and also the Nordic SDK examples and dfu. I have been unable to get anything that downloads and reports as verified using IDAPnRFProg to actually be detected by nRF Connect. The DFU start address is 0x35C00 and the App Start Address is 0x1B000. Am I missing some other step to getting things flashed properly? I am building everything with nRF_SDK version 12.3.0

    3. Hi Hoan, I am trying to debug using J-Link debugger, and not able to single step. Is the blinky project that you have on github configured expecting a 32 kHz crystal to be attached to IMM-nRF51822 or should it run without one? If it is setup to use the crystal, is it easy to switch to the internal oscillator for a quick test.

    4. You can run without the crystal. All you need to do is to change the code to use RC oscillator instead. I haven't tested Blinky_ble for a while. Try the UartBleDemo and the PTHSensorTag. Those should work. Make sure you flash the Softdevice that came with SDK12.

    5. For DFU, try compile in Release build. Debug build may not work well.

    6. Hi Hoan, The DFU Release build uses a DFU start address of 0x3a800 instead of 0x35c00 does that make sense? I am still not able to get anything to run. Also when debugging with J-Link it does not reach the breakpoint in main.c and is not giving any source in the DEBUG Perspective, perhaps I have some other build environment issue.

    7. Yes, they are not at the same address because compile result does not have the same size. For debugging, you need to first flash softdevice + dfu that you want to debug then you can debug in Eclipse. This is particular to DFU due to softdevice jumping to App if UICR is not written with dfu start address. I just recompile and tested the dfu. It showed up in nRFConnect correctly. email me, i'll send you my hex file to try.

    8. Thanks Hoan, my email is
      I am also having an issue trying to use OpenOCD, I get "undefined debug reason 7 - target needs reset" when I try to debug, perhaps this is related to not having the soft device and dfu properly loaded.
      I went back through the complete tutorial and rebuilt my Eclipse Mars folder structure carefully to match what you have in the blog, everything is compiling using nRF_SDK12.2 as recommended. I am able to build dfu.hex, and PTHSensorTag.hex I will be interested to see whether or not your hex file works, do I load just your dfu.hex or combine it with

    9. You need to load SD + DFU. DFU alone will not work.

  2. Hi there,

    thanks for the tutorial, great work.

    I have managed to setup Nordic Semi SDK 14 and the gcc-arm-none-eabi toolchain, examples compile and work with the supplied make files in the directories, which is cool.

    I also installed Eclipse C/C++ and MCU which and setup the project with all files needed, compiles and links with no errors, uploading the hex file to
    the device via nrfjprog works fine ... but the it the code does not seem to execute. Flashing the original example hex file works fine.

    Building and uploading with Keil MDK works without a problem.

    What are the common errors here ? I concatenated the ld files (common + example ld file), checked that the same compile and linker commands and options are used. The elf files are different and the lengths of the hex files as well as .o files are different. I just do not understand why this is the case if the same compiler and options are used ... I am sure there is something obvious I am missing.

    I am running out of ideas ... any nudge into the right direction would be great.


    1. Hi,
      First thing is to check whether Softdevice was flashed prior to flash your code. I have not used nrfjprog so I don't know how it manage it. Look for mergehex on the forum. Second thing to check is the linker script if you compiled with GCC. Setting in the LD about all those SECTION vars may have bugs. Compare them with mine. Usually the error was the missing of "> RAM AT > FLASH". Replace all the "> RAM" with "> RAM AT > FLASH". Third check the memory mapping in the LD file.

    2. Thanks Nguyen,

      I found the problem and I think it is somehow interesting.

      While moving around the files I came across the ld file in the example directory and saw that it had an INCLUDE directive to load the nrf5x_common.ld file. Because I thought I am brilliant I just concat both files so replacing the INCLUDE directive with the linker code of the file to be included.

      As it turned out it was not so brilliant as it seems to make some sort of a difference because readelf -S would show a slightly different mapping than the original file compiled with the SDK makefile and it would not execute on the chip.

      Then I put both files into the eclipse workspace, removed the INCLUDE directive in the original example ld file and added this file and the nrf5x_common.ld to the eclipse MCU linker configuration.

      Now it works like a charm ! It is interesting though that concating the two files does generate problems.

      On nrfjprog, pretty simple to use, it is part of the Nordic Semi command line tools and needs Segger JLink tools to be installed on the system. The syntax then looks something like this

      nrfjprog -f NRF52 --program ./BlinkyNRF52.hex --sectorerase --reset


    3. It is possible to put all in one but you'll need reorder the sections to group them up.

  3. Hello. firstly so glad i found this link as i have been trying to get going with the nRF52832. I have the dev board from Nordic. All i want to do is use this board in BT mesh mode and send the onboard temp from each board to a "home" board. Is this possible? I have looked at fruitymesh on github and been researching for about 3 weeks now. Thanks

    1. Yes, it is possible. You can use full Nordic SDK Mesh with it.

  4. Hi,

    Thank you for this blog. I have been trying to follow your tutorial for a couple of days now but I am finding it confusing. Can you please help me ? I am trying to develop a BLE application for your nrf51422 breakout board. I am using eclipse in linux. This is my current folder structure:

    root-folder: nrf-projects


    Steps I followed:
    1. Set eclipse workspace to 'nrf-projects'.
    2. Imported all the projects
    3. Built 'CMSIS' project ---SUCCESSFUL
    4. Built 'EHAL' project -- FAILED (.../EHAL/src/sensors/tphg_bme680.cpp:91:28: fatal error: bsec_interface.h: No such file or directory)
    5. Wanted to build some of your examples, but failed couldn't reach here as previous step failed

    This is where I am stuck.

    Few more questions:
    Do I have to build CMSIS and EHAL to try out your examples? What else do I have to do to try out the examples ?

    Looking forward to hearing back from you
    Thank you for your help!

    1. You need to download the BSEC library. The link is provided on the folder layout.

    2. Hi,

      Sorry for late reply. I didn't get the notification about your message. The BME680 requires a library to be download from Bosch website. I have the link for the download on the folder tree layout. CMSIS & EHAL lib are required for the examples. Yo need to compile them first.

  5. Hi Hoang, I am using NINA-B301 EVK with nRF52840 chipset. I could flash program with SEGGER Embedded Studio and nrfjprog command line tool . We are interfacing nRF52840 with i.MX6 CPU using USB hardware interface. Please let me know how can I port driver and basic test application with i.MX6 CPU build linux environment.

    1. I am not sure to understand what you want to do. Which driver are you referring to ?

  6. Hi Hoang, I’ve just gotten your IDAP-Link and I’m trying to use it on an ISP1507 module (with a nRF52832) we have mounted on a PCB. We have Vcc, Ground, SWDIO, & SWDCLK lines we run to a programing connector that is connected to the IDAP-LINK 16 (pin) connector’s 3.3(14), ground(13), SWDIO(2), and SWDCLK(4) 1:1. Using a hex file we know is working for this board I keep getting “target not found” when I try either IDAPnRFProg or the SD card method (after using “IDAPSetTarget 2”)
    We can successfully program the target board using jumpers off Nordic’s nRF52832 eval board connected to the same pins using their nrfjprog software.
    I’ve tried with and without the 8K SD card installed. The IDAP-Link’s firmware is the current latest on sorceforge 1.6.181013 which I updated in my attempts to get this working. The IDAPnRFProg is 1.6.190113
    Can you make any suggestions on what to try or look for to get this system working together? perhaps I should try failing back to a build you know will work for this chip? Thanks

    1. Hi,

      The 3.3v on the IDAP connector is an optional power source that you can use to power your board. If your board is self-powered, then it is not required. However, you need to connect your board power (VCC) to the IDAP pin 1 (TVCC) Target VCC. That pin is required so that the IDAP can translate logic level to match your board. IDAP can flash target device from 1.75V- 3.6V. In resume for SWD to work TVCC, GND, SWDCLK, SWDIO.

  7. Thank you Nguyen, after adding this jumper and improving the connections I was able program the unit with the IDAPnRFprog software.

  8. Thank Nguyen, very informative material from your blog.!!!

  9. Hello Nguyen,

    I just bought a BLYST Nano exploration kit and I am trying to setup Eclipse following your tutorial. I installed he GNU MCC plug-in via Eclipse Marketplace, I also downloaded all the libraries and placed them in the development source tree as explained above, but I got an unknown error when importing IOsonata and CMSIS projects:

    08:25:03 **** Running scanner discovery: CDT GCC Built-in Compiler Settings Cross ARM ****
    arm-none-eabi-gcc -std=c99 -mcpu=cortex-m4 -mthumb -mabi=aapcs -Wall -Werror -O3 -g3 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -ffunction-sections -fdata-sections -fno-strict-aliasing -fno-builtin --short-enums -E -P -v -dD /Users/uoc/Documents/eclipse_projects/private/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C
    Cannot run program "arm-none-eabi-gcc": Unknown reason
    Error: Program "arm-none-eabi-gcc" not found in PATH
    08:25:03 Build Failed. 1 errors, 0 warnings. (took 3ms)

    Any idea where I could find this arm-none-eabi-gcc and where I shall put it ?

    Thanks, and thanks for this great tutorial !

  10. 1) That is very strange.... In the Finder if I search for "arm-none-eabi-gcc" in my root folder there is no match but if I open the gcc-arm-none-eabi-9-2019-q4-major/arm-none-eabi/bin folder it is there !!! Why is it invisible to both Finder and Eclipse ? I read the readme file (GNU MCU Eclipse plug-in) but it is rather obscure to me... do I need to 'invoke' arm-none-eabi-gcc ? Again I tried all the commands in the Terminal but nothing works. How do I set the path correctly ?

    2) I downloaded the latest package from
    However I am not sure I unpacked it at the right place (also I simply double clicked on the bz2 file to unpack it, I couldn't do it with a Terminal command as explained in the readme file):

    | |--BSEC
    | |--CMSIS
    | |--nRF5_SDK_12
    | |--nRF5_SDK_15.3
    | |--nRF5_SDK_Mesh

    3) In all nrf_svc.h files, I replaced "bx r14" : : "I" (GCC_CAST_CPP number) : "r0" with "bx r14" : : "I" ((uint16_t)number) : "r0"
    Is that ok ?

    4) I want to make sure I didn't skip a step: In your Eclipse installation page you refer twice to GNU MCU. First at the very beginning of the paragraph, where you explain how to install the plug-in via Marketplace. Next you give a link for the GCC ARM compiler but then again you are back to GNU MCU in the paragraph starting with "The best ARM Eclipse plugins I found is from here [...]". When I click on the link and read the install instructions, it sounds like what I've just done via Marketplace in the first place. Am I missing something ?

    Thanks !

    1. Hi Matt,

      Thanks very much for supporting our products. The compiler on MAC does not install. All you need to do is to extract it and put it anywhere you like. After that, go to Eclipse/Preference/MCU/Global ARM Toolchain to set the path. Do that for OpenOCD as well. It should compiles after that. If you don't have the Invensense Lib yet, you can disable the compilation of the driver for that chip. I haven't implement the new ICM-20948 driver without the Invensense lib yet. For the moment, that is still required.


    2. 3) You don't need to do that anymore. Nordic already fixed the issue since SDK14 I think.

  11. Thanks Hoan,

    but I am still getting the same error :

    09:57:23 **** Running scanner discovery: CDT GCC Built-in Compiler Settings Cross ARM ****
    arm-none-eabi-gcc -std=c99 -mcpu=cortex-m4 -mthumb -mabi=aapcs -Wall -Werror -O3 -g3 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -ffunction-sections -fdata-sections -fno-strict-aliasing -fno-builtin --short-enums -E -P -v -dD /Users/uoc/Documents/eclipse-workspace/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C
    Cannot run program "arm-none-eabi-gcc": Unknown reason
    Error: Program "arm-none-eabi-gcc" not found in PATH
    09:57:23 Build Failed. 1 errors, 0 warnings. (took 2ms)

    In Eclipse/Preference/MCU :

    1a) I set the path for Global ARM Toolchain Paths as follow
    > didn't work

    1b) I set the path for Global ARM Toolchain Paths as follow
    > didn't work

    1c) I set the paths for Global ARM Toolchain Paths and Workspace ARM Toolchain Paths as follow
    > didn't work

    1d) I set the paths for Global ARM Toolchain Paths and Workspace ARM Toolchain Paths as follow
    > didn't work

    1e) I downloaded gcc-arm-none-eabi-9-2019-q4-major-mac.tar.bz2 again (just in case the first download was somehow corrupted) and tried again. I even re-installed Eclipse just to make sure I started really from scratch.
    > didn't work

    2) I also get this error message during the import although “Copy projects into workspace” is unticked
    Some projects cannot be imported because they already exist in the workspace or the project description file is corrupted
    then if I click on Details I have a list of messages like Ressource '/AdcDemo' already exists
    (Of course each time I try something new I delete all projects from the workspace)

    3) I couldn’t find any OpenOCD executable in any of the libraries I downloaded for this project (IOsonata, GNU MCU, etc). When I searched my Mac, I got two matches in Arduino and ModusToolbox folders but I didn’t know whether those ones would be compatible so I downloaded OpenOCD version 10 directly from but still no executable in it… I don’t know what I am supposed to put for the openOCD path or even what it is should point to.
    I tried to put IOsonata-master/ARM/DbgConfig but no change, I am stuck anyway with issue #1 and #2

    Frustrating, frustrating, frustrating…

    1. The ..../bin is the correct path for the compiler. The problem on OSX catalina is the security that block it from executing. You need to allow it in the OSX/preference/security. When you compile, it popup a message ask to cancel or delete. Do cancel, then in security preference allow it. Then recompile again, this time it will ask to open. Allow it to open. There will be a couple of executable that you need to allow one by one. After that should be ok.

    2. could you send em an email? It would be easier to send screenshot if needed.

  12. Here is a list of the libraries and components I installed:

    1) Java version 13.0.1 from
    2) Eclipse version: 2019-09 R (4.13.0) from
    3) GNU MCU Eclipse plug-in version 4.7.1 from Eclipse Marketplace
    4) CMSIS version 5.6.0 from then GitHub package
    5) GNU ARM Embedded Toolchain version 9-2019-q4 from
    6) OpenOCD version 10 from
    7) IOsonata from
    8) nRF5 SDK version 15.3.0 from
    9) nRF5 SDK for Mesh version 4.0.0 from
    10) (ICM-20948 driver from
    11) BSEC version July 3rd 2019 from
    12) Micro-ecc from

    Anything missing ?

    On GitHub I noticed the misalignment issue warning for CMSIS but I was not sure wether it was relevant to me so I DIDNT DO ANYTHING ABOUT IT, Should I ?
    Version 16.0.0 is the latest nRF5 SDK but it generated lots of errors and you seem to specifically ask for 15.3 in the tutorial so 15.3 it is
    I am still waiting for the authorisation to download the ICM-20948 driver. Sent 2 requests in 4 days…

    Then I placed the different libraries in the folders as described here:

  13. I have bought a BLE Micro. (

    1. I downloaded "nRF Connect App for Android" on the phone.
    2. I downloaded Arduino Library "" and also ""
    3. I open Arduino Blink sketch, selecting board "Generic nRF51822" or "redBearLab nRF51822".
    4. I generate .Hex file, send to the phone, and I am able to upload as "application" with the nRF connect App. It also asks for a .dat file, but it can upload th .hex file

    even if it is missing (how should I create it?)
    5. Application is downloaded, 100%.

    But nothing happens! I tried both nrf_gpio_pin_set(xx) and clear, and also digitalWrite, but no way any of the pins shows any sign of life. I tried with multimeter, they

    stay about 300mV fixed. Also with an led connected both to vcc - or gnd, and the pins. Nothing. What am I doing wrong?
    Also the pinout is not 100% clear, I looked at and tried pin 3, 30, 25,26,29, ... always no results.
    Any help would be greatly appreciated.

    1. I don't think you can upload a hex file via nRFConnect App. It requires a .zip. The .zip is generated using nrfutil. See I don't think your module comes with a bootloader compatible with nRFConnect. You'll need to connect it to a JTAG via SWD pins in order to flash it.