Embedded Development in CLion

For the specific instructions and details, check out our webhelp for Embedded Development in CLion.

What is supported

Q: Does CLion support embedded Linux?

A: Yes, it does. A project for Embedded Linux has to be compiled with a cross-compiler and then deployed and run on the target device under remote debugger. Here is an example project that demonstrates both embedded Linux support and a workaround for a related feature request.

In some cases, on-chip debugging using SWD/JTAG can be helpful, and this is also supported via the Embedded GDB server. 

Q: What kind of bare-metal hardware is supported?

A: While we don’t test CLion extensively with all possible types of hardware, in general, any hardware that is supported by a relatively recent GCC toolchain or by IAR compilers should work. For example, expressif32(ESP8266, ESP32), mips32(pic32), avr8(arduino), and risc-v etc are likely to work fine. Please see our webhelp for the officially supported hardware types. CLion also offers special support for STM32 MCUs and a snippet of CMakeLists.txt, which may be a starting point for projects based on other MCU series.

Q: Is it possible to debug on a microcontroller with CLion?

A: That depends on the hardware type. For instance, AVR firmware can be compiled and flashed to the hardware, but an on-chip debugger is not supported because of hardware limitations. For many other target platforms, like ARM or RISC-V, on-chip debugging is supported via the gdbserver protocol. At the moment our primary target is ARM Cortex-M kernels: on-chip debugging is fully supported there using SEGGER, ST-LINK, and some other debug adapters.

Q: Are all STM32 chips supported out of the box?

A: The answer depends on the MCU series. For most of the STM32 MCUs, the project sources may be generated with STM2CubeMX for STM32CubeIDE, and then opened with CLion directly. Unfortunately, there are some exceptions where this approach does not work:

• Dual-core STM32H7. The generated project is not supported, but there is an experimental snippet of CMakeLists.txt. Just copy it into the generated project, look through all the “todo” comments, make the necessary changes, and then open it as a CLion project.
• STM32L5 and  STM32U5 with TrustZone enabled. However, you can manually write CMakeLists.txt for your project; the example snippet above might help. STM32L5 with TrustZone disabled works out of the box.
• STM32MP1. The generated project contains two parts – Linux for Cortex A7 and bare metal for Cortex M4. This is not supported out of the box, but specific CMakeLists.txt should work. This has yet to be documented.

Q: Which hardware probes may be used?

A: You can use any probes that have gdbserver support, either via OpenOCD or via vendor-specific gdbservers. The verified hardware includes:

• stm STLINK/V2
• Segger J-Link
• Raspberry Pi direct GPIO connection
• PE-Micro Multilink Universal FX
• Some specific configs like FT232 in bitbang mode

Q: Which build systems are supported?

A: The primary project model is CMake. Starting from 2020.2, CLion also supports the Makefile build system. When configured properly, any project model should work via Compilation Database and Custom Build Targets. However, some IDE features are still limited to CMake only.

Q: How to start a project for a non-STM ARM-based MCU?

A: Make sure you have the following:

• Toolchain installed
• CMakeLists.txt for your project (feel free to use https://gist.github.com/elmot/3b4f0e9f8b23864fdf8bb509c329d051 as a basis)
• Linker script (specific to the chip)
• The CMSIS library necessary for all ARM devices
• Chip vendor libraries
• GDB server

The linker script and the libraries usually can be taken from a standard example for the chip.

As a toolchain, you should use compilers from the GNU ARM toolchain, as well as a debugger – either the GDB from the toolchain or CLion’s bundled GDB. 

The GDB server is specific to your debug probe. It can be ST-Link, Segger, PE Micro, or something else. The setup procedure is briefly described in this article. You may use Raspberry Pi as well.

Troubleshooting

I’m seeing strange Gdbserver behavior, like missed or miracle breakpoints, strange hangs, etc. (especially with SEGGER J-Link).

Make sure that you have only one gdbserver instance running. Those GDB servers MUST be run in single-run mode (-s CLI switch in the case of SEGGER).

There is a limit on how many hardware breakpoints are used. For most Cortexes, the limit is 6 breakpoints simultaneously (not counting disabled ones). If more breakpoints are set, gdb will not work properly. However, some probes, such as advanced models of Segger J-Link, can help overcome the problem.

When I use a custom CMake project, diagnostics like “Compiler can’t compile a simple program” appear.

The solution is straightforward: disable the compiler check by adding the following before the project clause:

SET(CMAKE_C_COMPILER_WORKS 1)
SET(CMAKE_CXX_COMPILER_WORKS 1)

Here’s a  slightly more accurate and less radical solution: relax the compiler check by adding the following before the project clause:

set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)

Also, for non-Linux projects, it’s worth adding the following before the project clause:

SET(CMAKE_SYSTEM_NAME Generic)
SET(CMAKE_SYSTEM_VERSION 1)

Is there a way to provide more than one .cfg file for openocd?

There is another, more universal way: write a new .cfg file that calls all the required files plus adjustments, and additional commands, if required.
The syntax should be quite self-explanatory, for example, st_nucleo_f103rb.cfg:

# This is an ST NUCLEO F103RB board with a single STM32F103RBT6 chip.
# http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/LN1847/PF259875

source [find interface/stlink.cfg]
transport select hla_swd
source [find target/stm32f1x.cfg]
reset_config srst_only

I cannot seem to get the debugger working properly with Nordic Semiconductor Bluetooth MCU (nRF52x). After reaching a breakpoint and trying to continue the execution, the application crashes. 

This is a very generic problem for the Bluetooth stack. The protocol has very strict timings, and any debugger activity breaks those timings. When that happens, an nRF soft device either hangs or falls into a hard fault. This is not specific to CLion but happens under any IDE or debugger. It might be that double-core Bluetooth MCUs (nRF53xxx, STM32WBxxx, etc.) work better, but we haven't tried those yet. Unfortunately, not much can be done about this.

One possible workaround would be to develop and debug all the functionality that is not related to Bluetooth first, and only then add the communication level.

You could also use prehistoric printf diagnostics via UART, RTT, or SWO.

We’re planning to implement a “live data” feature where the debugger will be able to display near-real time memory changes without stopping MCU cores. Feel free to follow and upvote CPP-22056.

For more information about CLion and nRF52x firmware development, we recommend this nRF Connect 5 SDK blog post, thanks to Nick Brook from NRB Tech.