CLion 2019.1 EAP: CLion for Embedded Development, Part III


Here comes a new CLion 2019.1 EAP build 191.5701.24! Get it from our website, Toolbox App, or via a snap package (if you are using Ubuntu). The patch will be available shortly if you are using the previous EAP build.

When sharing our plans for 2019, we identified Embedded development support as one of the major areas of focus for the year. Ilya Motornyy, the author of the OpenOCD + STM32CubeMX plugin, joined our team in late 2018 and has already integrated the plugin into CLion. As a result, starting with this EAP, OpenOCD debugger support and integration with STM32CubeMX is available out of the box:

Embedded dev support plugin


STM32CubeMX & OpenOCD integration

In his two guest blog posts from 2016 and 2017, Ilya shared his experience in programming for microcontrollers in CLion and explained how the flow with the CLion plugin may look like:

Below we’ll briefly summarize the setup and the steps, and we’ll highlight the changes introduced with the plugin’s integration.

Start by getting the tools ready

Currently the plugin targets STMicroelectronics boards (such as STM32 Discovery, Nucleo, or EVAL) and debugging with Open On-Chip Debugger. To start developing, you’ll need the following tools:

  • ARM toolchain. Install and check you have arm-none-eabi-gcc in the system path.
  • OpenOCD debugger.
  • STM32CubeMX, a graphical tool to configure STM32 microcontrollers.

Check the STM32CubeMX and OpenOCD were detected automatically by CLion in Settings/Preferences | Build, Execution, Deployment | Embedded Development or set the correct paths manually.

If you are on Windows, note:

  • Works fine with MinGW and MinGW-w64 environments
  • Doesn’t work currently with Cygwin (CPP-15034) or MSVC
  • As for the debugger:
    • arm-none-eabi-gdb.exe works fine, but doesn’t include correct pretty printers
    • arm-none-eabi-gdb-py.exe works fine, including the pretty printers, but requires python 2.7 (32 bit) installed and throws an error on the first launch (CPP-15502)
    • Bundled GDB works, but throws an error on the first launch (CPP-15502)

The OpenOCD + STM32CubeMX plugin is now bundled, so you don’t have to additionally install anything in CLion.

Create a new project in CLion

When you open File | New Project, the dialog now suggests an embedded project type – STM32CubeMX:
New Project for Embedded

Simply provide the location for the project and CLion will create the .ioc file for you with the default MCU STM32F030F4.
New ioc project

The project sources are not yet generated though, so you should go to STM32CubeMX and run ‘Generate Code’. STM32CubeMX can be opened right from CLion: open the .ioc file and click ‘Open with STM32CubeMX’.

The newly created project in CLion has the MCU set to STM32F030F4. You can change the MCU in the MCU Selector of STM32CubeMX:
Change MCU
But STM32CubeMX will then reset the project name (as it creates a new one) and you’ll have to provide it in STM32CubeMX’s Project Manager and overwrite the recently created project. You are nearly done here. Just check that the Toolchain / IDE is set to SW4STM32 and check Generate Under Root:
Generate code
You are ready to generate code now!

Go back to CLion and wait until the project is reloaded. A CMake project will be created for you automatically, and CLion will suggest selecting the board config:
Select Board Config

Open an existing project in CLion

If you already have an embedded project, just open it in CLion. When you then first open an .ioc file in the editor, CLion will generate the CMake project for you:
Existing project

What can I do now with my embedded project in CLion?

When the project is loaded and CMake is correctly generated, a few Run/Debug configurations are created automatically for you in CLion, including the OpenOCD one:
OpenOCD configuration

Use it to debug on your microcontroller.

You can also use Tools | CMake | Update CMake Project with STM32CubeMX to regenerate the underlying CMake for your project.
You are now free to create some cool stuff working on your STM board. CLion will assist you with editing and reading the code, and all the smart actions like refactorings and code generation will be available for your project in CLion!

What’s next?

This is just a first step into the vast area of Embedded Development. More smart IDE actions, deeper integration with STM boards and other MCUs, and other big features are definitely coming later this year. Give this EAP build a try, let us know what you think, and stay tuned for more!

By the way, next week, Thursday, February 28th, we’ll do a live webinar on Remote Development with CLion. Remote development on Raspberry Pi will be discussed as an example. There are still a few places left! Register now.

Other improvements

A new IntelliJ Platform feature worth mentioning here is the Recent Locations Popup (Shift+Ctrl+E on Win/Lin, ⇧⌘E on macOS). It lists all the locations that you’ve visited in a chronological order, with the latest visited location at the top and the first visited locations at the bottom.

A few great things to know about this new popup:

  • You can filter by changed code locations.
  • You can search by file name or code snippet: simply start typing, and the instant search will filter the matches for you.
  • You can remove any location from the popup by pressing Backspace or Delete.

Recent Locations Popup

That’s it. Read the full release notes if you like, and download and try the EAP build today. We are looking forward to your feedback!


Your CLion Team
The Drive to Develop

This entry was posted in Announcement, Early Access Preview and tagged , , , . Bookmark the permalink.

97 Responses to CLion 2019.1 EAP: CLion for Embedded Development, Part III

  1. Anton says:

    Control+Shift+E doesn’t do anything on Windows here. Moreover, it seems like CLion “remembers” the pressed Control key after using this shortcut: I can’t type at all until I restart CLion. I assigned an additional shortcut for this action and it works well so far.
    There is a chance it’s my own local issue though.

    • Anastasia Kazakova says:

      Try to switch to the default keymap, does it has the same issue? Can you also check Control+Shift+E isn’t used at your system?

  2. Kevin says:

    Why integrate STM32CubeMX on that level?
    Ever thought about embedded projects which are not based on STM32CubeMX?
    What about native GDB server support instead of openOCD server, any plans on this?

    • Anastasia Kazakova says:

      Remote GDB server debug is already there in CLion. OpenOCD is a very popular embedded debugger, that’s why we’ve integrated it.
      Regarding the STM32CubeMX – it’s one of the most popular ways to generate project for STM board. Other boards/mcu will definitely come, but later. That’s just a first step.

    • elmot says:

      If you do not use STM32, you can completely ignore STM32CubeMX part of the plugin and use virtually any kind of MCU and a probe, which are supported by GCC and OpenOCD. In this case, you need manually write CMakeLists.txt, then find suitable CMSIS and linker script.

      Then you need to make your own Run Configuration of type “OpenOCD Download & Run”. For instance, someone reported PIC32 MCU working with CLion, and I personally tried nrf51XXX MCU + FTDI/SWD probe (I believe this is cheapest possible JTag ever).

  3. Henry Borchers says:

    I’m not an embedded developer but I find this is super interesting. I love CLion so much that it make me almost interested enough to try embedded programming. This is not something that I’ll really use for my work but I’m glad that you have this in here. I’m sure it’ll make a number of people out there very happy. I love whenever I can move away from other tools for CLion and other Jetbrains programs in my projects.

    Side note: I hope that the MSVC debugger mentioned in the roadmap is coming along well, and at least a preview will still come out for 2019.1. I’m sure you can’t comment on it right now but just wanted you know that you have me very excited about this feature.

    Keep up the excellent work!

    • Anastasia Kazakova says:

      Thank you for your feedback and we are really glad to impress you and push to some experiments with embedded dev!

      As for MSVC debugger, it’s indeed under development. However, I doubt it will be ready in 2019.1, but definitely, we’ll start the preview with 2019.2 EAP then.

      • Henry Borchers says:

        Anastasia, You are very welcome!

        Don’t worry, I completely understand about pushing the MSVC debugger preview to 2019.2 EAP. You explained what was involved a while back and it sounds like a very large and challenging task. I’m just happy that you’re working on it and I’ll get to use it soon.

  4. Richard Vowles says:

    You should consider direct support for PlatformIO. It would greatly enhance the usefulness and decrease the pain of embedded development if CLion had similar if not better integration than vscode.

  5. Samuel Urban says:

    I was using segger embedded studio for all my mcu related work and clion for pretty much everything else.. you can’t imagine how happy am i knowing that you support STMCube!

    Anyway, there are still some issues with IDE itself(especially slow indexing on large files/projects) but clearly, one of the best i’ve ever used. I also want to say that i’ve seen large steps forward(using clion from 2017-ish) in your c++ in time analysis as the completition is more and more contextual, templates and lambdas are not giant red block of text marked as syntax error and so on.. Thank you very much for this amazing IDE, but please, really look forward into those bottlenecks as they are becoming annoying at some point :)

    • Anastasia Kazakova says:

      Thank you very much for your feedback! We do appreciate it greatly and really happy you are staying with CLion for that long!

      And I want to assure you that performance is our top priority for now and we do our best to address such issues as much as we can.

  6. Taw says:

    I really hope that the team will concentrate also on bugs, there are a lot of very old bugs which are not solved yet are annoying, example: CPP-7364, CPP-5501.
    Also for me is unusable on Windows because of CPP-15505, it loads for 9 hours and then it fails…

    Instead, in 2019.1 EAP, we got naming conventions. :-)

    • Anastasia Kazakova says:

      We definitely fix bug and currently investigating your issue with CMake load. However, while some users care about some particular bugs, others are waiting for some features that are critical for their workflow. Naming is one of such features. So we try to share our resources among both parties)

      • Taw says:

        Thank you, I understand that your resources are limited.
        So some users consider naming conventions “critical” for their workflow…funny.:)
        Regarding my issue, I will try to use VStudio or WSL with CLion, perhaps it will work.

  7. Richard Vowles says:

    Anastasia – that is not “nicely” that is cmake with the command line. Please compare the VSCode integration. However if you are not wishing to play in this space, thats ok too.

    • Anastasia Kazakova says:

      Why the command line? You can configure the File Watcher that will regenerate CMake project every time you touch the Platform IO files. We’ve discussed that with Platform IO team and they seem it’s a nice way to go. Anything in particular you would like to see in terms of integration?

  8. Belussi says:


    Native embedded development support is something I’m waiting for a very long time. I’m using elmot’s plugin with Microchip MCUs and is working perfectly. Unfortunately, this is still not enough to convince people to move from eclipse. For example, memory view is something what should be added (I know that some work is in progress).To be honest, without OpenOCD plugin I wouldn’t buy CLion for sure.


  9. Iziren says:

    Hi is there anything yet for using CLion with TM4C Series Microcontrollers (ARM-M Microcontrollers from Texas Instruments). Thanks!

    • elmot says:

      Yes, you can write code, compile, flash and debug your application with CLion. There is OpenOCD support for TI Stellaris MCU family. Most probably you need to migrate your project to CMake for that.

  10. Oleksandr Gusiev says:

    Looks good as a first step, but it is far far from perfect, we need deep integration with CubeMX, like in Atollic or IAR, current level of manual configuration is unacceptable for every day usage. Hope it will be as easy, as “create new project from CubeMX -> next -> next -> finish” in future, otherwise it is noncompetitive.

    • Anastasia Kazakova says:

      Indeed, that’s just a very first step. We communicate with STMicroelectronics and hope CubeMX will soon get some API to do the deeper integration.

  11. Regaron says:

    PlatformIO plugin like that of VSCode or Atom would be nice.

  12. Belussi says:


    What about including SVD files for example for Microchip MCUs? It would be good to state of all peripherals.

    Second thing is RTOS-aware debugging. VSCode has it.


  13. Hauke Radtki says:

    I was able to make this example work. But my main intention to switch to CLion would be good (host) test integration.

    I’m currenlty failing at setting up two toolchains with integration to CLion needed to both crosscompile for the target and compile tests for the host system.

    Is test support considered/being worked on for embedded development in CLion?

    • Anastasia Kazakova says:

      Not sure what you mean under “test support”. Any specific testing tool/framework?

      • Hauke Radtki says:

        Basically: Run tests on non-target dependent modules on the host machine (means, compile tests for x86 and run them on the development pc) with any testing framework (be it GTest, Catch, Boost.Test) from within the IDE.

        For this CMake/CLion need to have two toolsets. But since the arm-none-eabi-gcc toolchain only configured within CMake and not within CLion, this doesn’t work out. When creating a test launch configuration it would build for the target (arm) and fail to execute on the host (x86).

        • Elmot says:

          Your desired setup looks quite complicated, and we are moving forward to make such kind of setups easier in future CLion version. Anyway, you may try to setup your project using some tricks. First of all, you may move toolchain definitions out of your CMakeLists.txt into toolchain file, as it was done here, and then configure two CMake profiles, one with that toolchain file for ARM and one without, for host x86.

  14. Klaus Nagel says:

    I appreciate your work for embedde development very much!
    I dont like the out of the box, often not stable eclipse based solutions from the semicoductor vendors for professional development. At the moment i use the SEGGER Jlink Probe with the GDB Remote Debug Debug cofiguration. What I’m missing there is the possibility of a build before launch step like in the OpenOCD Configuration. Do you plan to integrate this also in the GDB Remote Debug configuration?

  15. skyyu.zhang says:

    After having CLion for Embedded Development I found some questions. When I use cubeMX to create demo with Fatfs system. then I write some code to verify it is ok to run . compiling is successful !!!! but unfortunately it not work . The question seem to be some “low hardware driver error”. so it can not create any file on my tf card. but when I use SW4STM32 to compile it , it works !!!!! I don’t why?? the same code also it can be compiled successfully on any software keil SW4STM32 CLion but not the same resultcompile !!!! help me

    • Elmot says:

      Sounds really strange, because CLion uses the same compiler as SW4STM32 does, but keil uses it’s own compiler. Most likely, there is a problem with the project setup. And I have not enough information to find it, sorry.

  16. Sergey Kilimnik says:

    CLion 2019.1.2

    I create new Embeded developer project, CLion creates .ioc file and instead of “STM32F030F4 configured” I see “No MCU Configured, invalid file content”. Opening in MX Cube, changing boards doesn’t help at all. Any of old ioc file I’ve tested doesn’t work.

  17. Hordon says:

    I would switch to CLion immediately with my STM32 embedded projects but the BSP library not added automatically to the project (despite it’s downloaded by CubeMX). When I added manually I get more error than code line. Would be nice to make this more convenient for the users. Or am I missed something?

    • Elmot says:

      I think it’s better if you report this with to our youtrack with maximum of details – board type, which BSP are you trying to use, Cube version etc.
      Most probably your problem could be fixed with some limited modifications to CMakeLists.txt

  18. Ken says:

    I can’t find a way to load in two .cfg files – one for interface and one for target. The current “OpenOCD Download & Run” only allows me to select one .cfg, since it assumes I will be using a board .cfg file. However, I am working on a custom PCB and not a development board like the ST Nucleo so a board-specific .cfg isn’t really applicable to me. Is there a workaround I can use to load in an interface .cfg as well as a target .cfg?

    Additionally, how can I pass in commands to openOCD? I am using a Segger J-Link and I want to select the transport layer to be SWD using “transport select swd”, or else it defaults to JTAG.

    • says:

      Please take any of existing board files as the example and write your own .cfg file. They have pretty trivial format, and you can put your “transport” command there

      • Ken says:

        Thanks for the reply. I did what you suggested and it was fairly trivial like you said and it seems to work just fine!

        Another question, does this openOCD + GDB setup support multithreaded debugging in any way?

        • says:

          I do not understand what kind of support you mean. We deal with bare metal single-core MCU’s.

          If you are asking about RTOS support, we do not have that yet.

          • Ken says:

            Is there a ticket for implementing some kind of RTOS support? E.g. view details about each task. Or is there no plans for that yet?

        • says:

          We do not have RTOS support ticket. Feel free to create one, with maximum of details – which kind of RTOS to support, what the features are most important, some links to existing tools.

  19. Sergey says:


    Trying to setup it on macOS.

    Once I generate the code in Cube and trying to reload it in CLion, I’m getting this error:

    Cannot get compiler information:
    Compiler exited with error code 1: /Users/sergey/Applications/gcc-arm-none-eabi/arm-none-eabi-gcc -xc -DSTM32F411xE -DUSE_HAL_DRIVER -D__packed=__attribute__((__packed__)) -D__weak=__attribute__((weak)) -I/Users/sergey/Temp/nucleo3/Inc -I/Users/sergey/Temp/nucleo3/Drivers/STM32F4xx_HAL_Driver/Inc -I/Users/sergey/Temp/nucleo3/Drivers/STM32F4xx_HAL_Driver/Inc/Legacy -I/Users/sergey/Temp/nucleo3/Drivers/CMSIS/Device/ST/STM32F4xx/Include -I/Users/sergey/Temp/nucleo3/Drivers/CMSIS/Include -mcpu=cortex-m4 -mthumb -mthumb-interwork -ffunction-sections -fdata-sections -g -fno-common -fmessage-length=0 -specs=nosys.specs -specs=nano.specs -std=gnu99 -fpch-preprocess -v -dD -E
    Using built-in specs.
    Reading specs from nosys.specs
    arm-none-eabi-gcc: error: nosys.specs: No such file or directory

    Could you advise what could be a problem?

  20. Ken says:

    Is there any support for SWO/SWV>

  21. Ken says:

    Is there any plans to support unlimited breakpoints for J-Link debuggers?

    • says:

      I can not verify if it works but I think it should be supported out-of-the-box.
      Of course, you need to have compatible J-link probe, appropriate Segger license, and please use new (CLion 2019.2+) Embedded GDB Server run configuration + Segger GDB Server software.

  22. Ken says:

    Is there any way to change the search path for CMakeLists_template.txt? I have multiple CLion OpenOCD projects that have the same requirements and thus share the exact same CMakeLists_template.txt. It would be great to have a top level CMakeListst_template.txt like so:

    |—> Project 1
    |—> Project 2
    |—> Project 3

    And be able to configure every project to search for the CMakeLists_template.txt one directory above

    • says:

      Sorry, there is no such a possibility. Please file a ticket, if it gets popular, we’ll implement the feature. At the moment you may try to workaround this using symlinks (yes, that’s supported on Windows) or with some script which copies your master template to every project. There is “External Tool” feature to tun scripts right from IDE.

  23. Ken says:

    With the new “Embedded GDB server” that came with 2019.2, is there still any reason “OpenOCD Download & Run”? It seems like I can use “Embedded GDB server” to run OpenOCD, but with even more flexibility because I can pass in arguments to the command line.

    • Anastasia Kazakova says:

      It was historically the first and planned as the most specific configuration. But likely we’ll remove it in the future, so you can use Embedded GDB server one.

  24. Ken says:

    What is the trigger for CLion to re-generate CMakeLists.txt based on CMakeLists_template.txt. So far I found that I need to

    1. Open CLion
    2. Open STM32CubeMX inside CLion by clicking on .ioc
    3. Re-generate code
    4. Wait a couple seconds and then CMakeLists.txt is finally updated.

    Is there an easier way to do this? Better yet, is it possible to trigger this update from __outside__ of CLion and do it on the command line somehow?

    • says:

      The embedded support plugin tracks modification time of several files generated by STM32CubeMX, and updates the project if they are changed.
      You may trigger the update manually, via Tools->CMake-> Update CMake Project with STM32CubeMX, or via right-click menu on .ioc file, or on CMakeList.txt or on it’s template.
      Of course, you can add the action to some handy place, for instance, to the main toolbar, and/or assign a shortcut to it.

      If you need to trigger the action outside CLion, it’s enough to run code generation in STM32CubeMX and then wait for several seconds.

  25. Ken says:

    Let’s say i have a project called FOO. CLion will generate an OpenOCD Download & Run configuration named “OCD FOO” for me. I noticed that if I change the configuration name in anyway (e.g. “OCD FOO” to “OCD FOO2”), then CLion for generate __another__ “OCD FOO” for me. Is there a way to disable this behaviour? That is, I want to be able to rename the OpenOCD configuration without CLion generating another one for me.

  26. Ken says:

    How is the UPLOAD build configuration meant to be used? I read the code in the CMakeLists_template.txt and it seems like it tries to connect arm-none-eabi-gdb to an OpenOCD GDB server at the default TCP port. However, don’t you still need to have an active OpenOCD GDB server to begin with?

    Moreover, it seems like in the article above, you are encouraged to only use OpenOCD Download & Run and not UPLOAD?

    • says:

      This is outdated thing, and it does not work. Please remove from your cmake template.
      Already dropped in new releases.
      If you need to flash your firmware without debugging, please use Run button

  27. Mathieu says:

    I am trying to generate my project for a Nucleo board (NUCLEO-F429ZI) with CubeMX. As soon as the project is generated, CLion (2019.1.3) throws an error (see below) and doesn’t generate anything. Any chance you could tell me how to fix this?

    java.lang.StringIndexOutOfBoundsException: String index out of range: 7
    at java.lang.String.substring(
    at xyz.elmot.clion.cubemx.ProjectData.setMcuFamily(
    at xyz.elmot.clion.cubemx.ConvertProject.loadProjectData(
    at xyz.elmot.clion.cubemx.ConvertProject.updateProject(
    at xyz.elmot.clion.cubemx.CubeFileListener.askProjectUpdate(
    at xyz.elmot.clion.cubemx.CubeFileListener.lambda$after$0(
    at com.intellij.openapi.application.TransactionGuardImpl$
    at com.intellij.openapi.application.impl.LaterInvocator$FlushQueue.doRun(
    at com.intellij.openapi.application.impl.LaterInvocator$FlushQueue.runNextEvent(
    at com.intellij.openapi.application.impl.LaterInvocator$
    at java.awt.event.InvocationEvent.dispatch(
    at java.awt.EventQueue.dispatchEventImpl(
    at java.awt.EventQueue.access$500(
    at java.awt.EventQueue$
    at java.awt.EventQueue$
    at Method)
    at java.awt.EventQueue.dispatchEvent(
    at com.intellij.ide.IdeEventQueue.defaultDispatchEvent(
    at com.intellij.ide.IdeEventQueue._dispatchEvent(
    at com.intellij.ide.IdeEventQueue.dispatchEvent(
    at java.awt.EventDispatchThread.pumpOneEventForFilters(
    at java.awt.EventDispatchThread.pumpEventsForFilter(
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(
    at java.awt.EventDispatchThread.pumpEvents(
    at java.awt.EventDispatchThread.pumpEvents(

  28. Sergei Ovchinnikov says:

    Hello, I have the CLion 2019.2.2version (Ubuntu 16.04) and generated my project for STM32VLDISCOVERY board with CubeMX. As the debugger I use OpenOCD (0.9.0) and set it in Settings->Build,Execution,Deployment->Toolchains->Debugger = openocd(/usr/bin/openocd), but CLion return “Not found”. On the tab Embedded Development, OpenOCD location = /usr/bin/openocd it is tested successfully.
    What the problem could be? Thanks.

  29. Jonathan Dumaresq says:

    Is it possible to use the “load” gdb command to flash the program ?

    From what I see, the program “xyz.elf” is passed directly on the command line of openocd. This is working well when the code has no offset. I can program an elf file directly. The problem appear when I want to use a bootloader to start my board, i need to program my application with an offset of 1K for example.

    with the openocd program command, this is not working well if no other parameters is passed for the offset.

    If instead of using the program command of openocd, you use the gdb load command, all this stuff is handled by gdb and openocd.

    Is this something doable right now in clion 2019.3 beta ?

    • elmot says:

      Starting from CLion 2019.3, I see at least two alternatives for you. You may either:

      • Configure your OpenOcd Run Configuration to Download: None and then add all required commands to your project’s .gdbinit file
      • Use fully-customizable Embedded GDB Server Run Configuration. It uses “load” command internally
  30. john says:

    Hello there
    When my STM32CubeMX Projects was created, the cmake project was not automatically created. I tried to reinstall clion, stm32cubemx, but it was still useless. In addition, the board config files interface will not be automatically generated.

  31. TengWenzheng says:

    Go back to CLion and wait until the project is reloaded. A CMake project will be created for you automatically, and CLion will suggest selecting the board config
    But in my case, the cmake project does not appear automatically after I generate the stm32cubemx project, and so does the board config menu.

  32. claus says:

    Running CLion 2019.3 and following the steps from the post, I don’t get the select board menu, and CMake menu item is grayed out, I can’t trigger the update manually via Tools->CMake-> Update CMake Project with STM32CubeMX, or via right-click menu on .ioc file.

    Also trying to install the plugin gives me error: Plugin ‘OpenOCD + STM32CubeMX’ support for ARM embedded development is incomatible with this installation.

    Plugin:’OpenOCD + STM32CubeMX’ version 1.3.alpha1 (build 191.4212 — 191.5700 Jan 29, 2019)

    CLion 2019.3.3
    Build #CL-193.6015.37, built on January 20, 2020
    Runtime version: 11.0.4+10-b520.11 x86_64
    VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
    macOS 10.12.5

    • Anastasia Kazakova says:

      The plugin is now bundled into CLion, so you don’t have to install the one from the repository.
      Are you creating a new prj or opening an existing .ioc file?

      • claus says:

        Without installing the plugin.

        Creating a project I can get into CubeMX, on return I don’t get the select board menu, and CMake menu item is grayed out, I can’t trigger the update manually via Tools->CMake-> Update CMake Project with STM32CubeMX, or via right-click menu on .ioc file.

        Opening existing .ioc file doesn’t seem to work either.

        • elmot says:

          First of all, try to update your STM32CubeMX. If it does not help,
          there is another way – try to create a fresh project with STM32 CubeMX and then open it with CLion. Please keep in mind, project name and path must not contain spaces, special or i18nal symbols; target IDE type should be set SW4STM32 or STM32CubeIDE.

Leave a Reply

Your email address will not be published. Required fields are marked *