Clion Git

Posted : admin On 1/25/2022
Tips & Tricks

Nearly a year ago, our guest Nick Brook, founder at NRB Tech, explained how to use CLion for nRF52. Today, Nick is back with a new tutorial focused on using CMake-based nRF Connect SDK in CLion. Read this tutorial from Nick and give it a try with CLion!

IoT consultant and founder at NRB Tech
Nick founded NRB Tech in 2018 to build useful and sustainable IoT (Internet of Things) products through a combination of in-depth hardware, software, and user experience expertise.

Previously, we established how it is possible to use Nordic’s nRF5 SDK with CMake and CLion. In April 2020, Nordic released version 1.0.0 of nRF Connect SDK, the new platform for Nordic products moving forward. This SDK is based on the Zephyr RTOS, a modern, secure, open source real-time operating system from the Linux Foundation backed by Facebook, Google, Intel, Nordic, NXP, and Opticon. The new SDK allows more complex projects using cellular and WiFi with new and future Nordic modules, while also supporting nRF52 series modules.

Extends Git Integration with additional features. Git clone is used to create a copy of a target repo. The target repo can be local or remote. Git supports a few network protocols to connect to remote repos. There are many different configuration options available that change the content of the clone For further, deeper reference on git clone functionality, consult the official Git. CLion allows you to upload changes from any branch to its tracked branch or to any other remote branch. Do one of the following: To push changes from the current branch press Ctrl+Shift+K or choose Git Push from the main menu. CLion allows you to upload changes from any branch to its tracked branch or to any other remote branch. Do one of the following: To push changes from the current branch press Ctrl+Shift+K or choose Git Push from the main menu.

An unashamedly CLion-friendly cookiecutter template for C2a, TDD with Catch2 and code coverage. You can’t perform that action at this time.

Zephyr uses CMake as its build system, making it much easier to use in CLion than the nRF5 SDK. However, there is some setup that we need to do.


The nRF Connect SDK supports nRF52 series SOCs in addition to the newer nRF53 and nRF91 SOCs. All development kits and Thingy boards are supported. The nRF Connect SDK can be used on Windows, macOS, and Linux.

Setting up the toolchain and SDK

The best way to set up the SDK and toolchain on Windows and macOS is using the nRF Connect Toolchain Manager. This is the simplest way to get set up, and it also ensures that all toolchain dependencies are in one place and are the right versions for that SDK version.

Manual setup instructions are available too, which can be used for setup on Linux.

Throughout this tutorial, when paths to the SDK are needed, we will use <ncsroot> as a placeholder. If using the Toolchain Manager with version 1.5.0, on Windows this would be C:Users<user>ncsv1.5.0; on macOS this would be /opt/nordic/ncs/v1.5.0.

Creating a custom project to use in CLion

Let’s create a custom project from a sample Nordic project.

  1. Find a relevant sample from the SDK in the <ncsroot>/nrf/samples directory. Copy this to a convenient location on your system. Rename the directory if you wish. If you are very new to nRF52, the peripheral_hids_mouse example is recommended. The example simulates a regular computer mouse. For more details refer to the example’s README.rst file.
  2. Open the project in CLion. Ignore any errors for now.
  3. In CLion preferences, go to Build, Execution, Deployment Toolchains and add a new toolchain. Configure as shown:
    1. Name: “nRF Connect SDK <version>”, replacing <version> with the version of the SDK you are using
    2. CMake: <ncsroot>/bin/cmake
    3. C Compiler: <ncsroot>/bin/arm-none-eabi-gcc
    4. C++ Compiler: <ncsroot>/bin/arm-none-eabi-g++
    5. Debugger: <ncsroot>/bin/arm-none-eabi-gdb
    6. Click “Apply”
  4. In CLion preferences, go to Build, Execution, Deployment CMake and then select the existing 'Debug' profile.
    1. Set Build type to ZDebug (this is explained further towards the end of the article)
    2. Set Toolchain to the nRF Connect SDK <version> toolchain we just created
    3. In CMake options add -G Ninja. Ninja is the recommended generator for Zephyr and prevents issues on Windows.
  5. To provide Zephyr with the system and project specific configuration it needs, we must set the environment variables. We need to set the environment variables in the CLion profile because this propagates them to processes launched by CMake, so targets that use west will work. If we set the environment variables in CMakeLists.txt, they would not propagate to launched processes.
    1. If you are using the toolchain manager, click the down arrow next to the NCS version installed and:
      1. On Windows, click 'Open command prompt' and paste:
      2. On macOS, click “Open Terminal” and paste:

      The result is automatically copied to your clipboard. Paste it into the 'Environment' box in CLion’s CMake Profile configuration.

    2. If you have installed manually, paste the following in the “Environment” box and modify.
      1. Modify ZEPHYR_BASE, GIT_EXEC_PATH, and GNUARMEMB_TOOLCHAIN_PATH replacing <ncsroot>.
      2. The NCS toolchain must come before other paths in the PATH variable. CLion does not yet support variable expansion in environment variables, so you need to enter the whole path, replacing <existing path>. To obtain the path to use, enter echo $PATH in a shell (macOS and Linux) or enter echo %PATH% in the command prompt (Windows).
    3. If you want to use a board other than the nRF52 DK, you will need to modify the BOARD environment variable to the board you want to use. The boards available are defined here in the 'Build target' column. There is also a webinar and guide you can follow to create a custom board.
  6. Duplicate the 'ZDebug' profile and modify the new profile’s 'Build type' to 'ZRelease'. Click OK.
  7. Most of the project configuration is done in the prj.conf file. Rename this file to prj.common.conf. This will contain the configuration common to both ZDebug and ZRelease builds. Open the file and at the bottom add:
  8. Create a new file prj.ZDebug.conf and add:
  9. Create a new file prj.ZRelease.conf and add:
  10. Open the CMakeLists.txt file. Before the find_package(Zephyr ...) line, insert:
  11. Click Tools CMake Reset Cache and Reload Project.
  12. You can now use the zephyr_final target to build <project dir>/cmake-build-<profile>/zephyr.hex, and the flash target to build and flash to the board.
  13. You can get RTT output by following the steps in Nordic’s Testing With a Sample Application guide. Essentially, after installing the JLink software and documentation pack, run:
    • On Windows: JLinkRTTViewer.exe
    • On macOS: open /usr/local/bin/
    • On Linux: JLinkRTTViewerExe

    Then select the Nordic SOC that you are using; the other defaults should be fine.

  14. Next we will set up debugging.
    1. On the top right of the CLion window, click the configuration drop-down and “Edit Configurations”. Then add a new “Embedded GDB Server” configuration:
    2. Configure as shown:
      1. Set a name
      2. Check 'Store as project file' to share this with other CLion users of your project
      3. Select the zephyr_final target
      4. Select the zephyr_final executable
      5. Set Target remote args to tcp:localhost:2331
      6. Set GDB Server to
        • Mac: /usr/local/bin/JLinkGDBServer.
        • Windows: C:Program Files (x86)SEGGERJLinkJLinkGDBServerCL.exe.
        • Or the appropriate path for your system.
      7. Set GDB Server args to
      8. Note that you may need to adjust the -device parameter to match your device. A full list is available – select “Nordic Semi” from the drop down, and use the relevant “Device name” for this parameter.
    3. To avoid a known issue with CLion/JLink GDB Server, you can work around it. Press Shift twice, type 'registry', open the Registry, and change the 'cidr.debugger.gdb.interrupt.signal' to 'SIGTRAP'.
    4. Now you can build this target, which will build and flash, or you can debug. When debugging, if your breakpoint is not hit when the debugger starts, just click the reset button and continue:
    5. You can also view the state of peripherals on the device when debugging. Click the 'Peripherals' tab and click 'Load .svd file':
    6. Browse to <ncsroot>/modules/hal/nordic/nrfx/mdk and select the .svd file for your hardware (for nRF52832 use nrf52.svd), then select the peripherals you want to monitor. When the debugger is paused, you will then be able to inspect the values of peripheral registers:
  15. In addition to using CLion for debugging, it’s sometimes useful to use Segger Embedded Studio (SES). This is Nordic’s officially supported IDE, so it is good to test with if you are having issues. In addition, when debugging you can see RTT output directly in the IDE with no configuration. With nRF Connect SDK, you can open your project just like any sample project by following the instructions in the guide.
  16. As in Nordic’s tutorials, in this guide we used ZDebug and ZRelease build types. This avoids CMake using built-in defaults for C and C++ compiler flags, which conflict with the flags defined by Zephyr from KConfig. If you want to use the standard 'Debug' and 'Release' build types, for example if these are used by libraries you add to your project, you can. However, you must reset CMake’s default flags and disable the warning that Zephyr emits.
    1. Open the CMakeLists.txt file. After the CONF_FILE line we added earlier, insert:
    2. In CMakeLists.txt change the default build type from ZDebug to Debug.
    3. Rename prj.ZDebug.conf and prj.ZRelease.conf to prj.Debug.conf and prj.Release.conf
    4. In CLion Settings/Preferences Build, Execution, Deployment CMake change the Build type of your profiles to Debug and Release.

We’ve now finished setting up a sample project in CLion for nRF Connect SDK development! To learn more about nRF Connect SDK development, you may want to explore:

  • Other samples in the nRF connect SDK:
    • <ncsroot>/nrf/samples/bluetooth – Bluetooth samples
    • <ncsroot>/nrf/samples/sensor – Sensor samples
      • <ncsroot>/nrf/samples/sensor/bh1749 – I2C example
    • <ncsroot>/nrf/samples/bootloader – Bootloader sample
  • The Application Development guide, which walks through the files you will find in the samples that configure the project.
  • The Device tree guide, which is how you configure hardware in Zephyr.

Now you are ready to give it a try!


Git is the most commonly used version control system. With Git, you can track changes you make to files, so you have a record of what has been done, and have the ability to revert to earlier versions of the files if needed. Git also makes collaboration easier, allowing changes by multiple people to all be merged into one source.

Git can be installed on Windows AND on WSL

An important consideration: when you enable WSL and install a Linux distribution, you are installing a new file system, separated from the Windows NTFS C: drive on your machine. In Linux, drives are not given letters. They are given mount points. The root of your file system / is the mount point of your root partition, or folder, in the case of WSL. Not everything under / is the same drive. For example, on my laptop, I've installed two version of Ubuntu (20.04 and 18.04), as well as Debian. If I open those distributions, select the home directory with the command cd ~, and then enter the command explorer.exe ., Windows File Explorer will open and show me the directory path for that distribution.

Linux distroWindows Path to access home folder
Ubuntu 20.04wsl$Ubuntu-20.04homeusername
Ubuntu 18.04wsl$Ubuntu-18.04homeusername
Windows PowerShellC:Usersusername


If you are seeking to access the Windows file directory from your WSL distribution command line, instead of C:Usersusername, the directory would be accessed using /mnt/c/Users/username, because the Linux distribution views your Windows file system as a mounted drive.

You will need to install Git on each file system that you intend to use it with.

Installing Git

Git comes already installed with most of the Windows Subsystem for Linux distributions, however, you may want to update to the latest version. You also will need to set up your git config file.

To install Git, see the Git Download for Linux site. Each Linux distribution has their own package manager and install command.

For the latest stable Git version in Ubuntu/Debian, enter the command:


You also may want to install Git for Windows if you haven't already.

Git config file setup

To set up your Git config file, open a command line for the distribution you're working in and set your name with this command (replacing 'Your Name' with your Git username):

Set your email with this command (replacing '[email protected]' with the email you use on your Git account):



If you don't yet have a Git account, you can sign-up for one on GitHub. If you've never worked with Git before, GitHub Guides can help you get started. If you need to edit your git config, you can do so with a built-in text editor like nano: nano ~/.gitconfig.

We recommend that you secure your account with two-factor authentication (2FA).

Git Credential Manager setup

Git Credential Manager enables you to authenticate a remote Git server, even if you have a complex authentication pattern like two-factor authentication, Azure Active Directory, or using SSH remote URLs that require an SSH key password for every git push. Git Credential Manager integrates into the authentication flow for services like GitHub and, once you're authenticated to your hosting provider, requests a new authentication token. It then stores the token securely in the Windows Credential Manager. After the first time, you can use git to talk to your hosting provider without needing to re-authenticate. It will just access the token in the Windows Credential Manager.

To set up Git Credential Manager for use with a WSL distribution, open your distribution and enter this command:

Now any git operation you perform within your WSL distribution will use the credential manager. If you already have credentials cached for a host, it will access them from the credential manager. If not, you'll receive a dialog response requesting your credentials, even if you're in a Linux console.


If you are using a GPG key for code signing security, you may need to associate your GPG key with your GitHub email.

Adding a Git Ignore file

We recommend adding a .gitignore file to your projects. GitHub offers a collection of useful .gitignore templates with recommended .gitignore file setups organized according to your use-case. For example, here is GitHub's default gitignore template for a Node.js project.

If you choose to create a new repo using the GitHub website, there are check boxes available to initialize your repo with a README file, .gitignore file set up for your specific project type, and options to add a license if you need one.

Git and VS Code

Clion Git Diff

Visual Studio Code comes with built-in support for Git, including a source control tab that will show your changes and handle a variety of git commands for you. Learn more about VS Code's Git support.

Git line endings

If you are working with the same repository folder between Windows, WSL, or a container, be sure to set up consistent line endings.

Clion Git Clone

Since Windows and Linux use different default line endings, Git may report a large number of modified files that have no differences aside from their line endings. To prevent this from happening, you can disable line ending conversion using a .gitattributes file or globally on the Windows side. See this VS Code doc about resolving Git line ending issues.

Clion Git Add

Additional resources