使用CLion开发STM32的正确步骤

前言

目前开发STM32程序的方式相比之前已经简单了许多，无非就是使用ST官方的Cube系列开发工具集，通过CubeMX生成特定IDE的工程模板和外设代码，然后在指定的IDE中进行编码构建操作，大家最熟悉的就是Keil，CubeIDE和IAR。

这里给大家介绍下如何使用CLion开发STM32工程，凭借CLion强大的代码解析能力和舒适的编码环境，提升STM32的开发体验。

CLion官方是支持STM32开发的，如果你正在使用CLion，相信你在创建项目时已经注意到它了。我们小学二年级就学习过，开发STM32程序需要进行编码，编译，调试，下载等操作，编译器和调试下载过程需要使用的调试器在CubeIDE中一定会包含，我们只不过是使用CLion来调用这些工具，实现这些操作，所以只需安装一个CubeIDE就足够了，里面的工具足够满足我们的需求，不需额外手动下载安装OpenOCD这类调试工具。

你可以根据向导在CLion中创建STM32工程，但是大概率你会直接卡在第一步的编译过程中，不然我也不会写这篇文章。

操作流程及问题解决

我们就按照CLion中的向导创建STM32工程，遇到问题解决问题，问题全解决了，也就有了正确步骤。嫌麻烦的可以直接看"正确操作流程"章节。

在CLion中依次点击: 文件->新 建->项目，左侧选择STM32CubeMX，初次使用会让你填写OpenOCD路径和CubeMX路径。CLion可以直接启动CubeMX生成代码和CMakeLists.txt，如实填写CubeMX路径；OpenOCD用于下载和调试，这里可以不填，后面介绍如何下载调试。

接下来设置好项目存储路径和项目名称，点击创建。

CLion自动为你创建了STM32CubeMX的配置文件ioc，并且调用了CubeMX，你会发现CLion自己默认让CubeMX选择了一个STM32F0单片机作为目标设备。

1.Clion自动为我们选择的目标设备并不是我们需要的，如何变更？

CLion通过CubeMX默认创建了F0的设备，并生成了模板代码，这并不是我们需要的，所以不建议使用向导创建，推荐使用以下方法：直接打开CubeMX，按照常规操作选择目标设备，依次点击File->Save Project As…，保存路径的最后一级文件夹名即为项目名称，保存后关闭CubeMX。

CLion中打开项目文件夹，CLion此时会识别到ioc文件，通过CLion启动CubeMX，生成代码。注意生成的项目类型要选择CubeIDE。稍等片刻生成CubeIDE项目代码，以及CLion构建项目时需要的CMake文件。

你当然可以直接像之前一样打开CubeMX，直接创建CubeIDE项目，然后使用CLion打开该项目，弹出任何OpenOCD的警告均忽略，因为我们根本不用使用它。

使用CLion打开CubeIDE会自动生成CMakeLists.txt配置文件，这种方法更加方便。

• CLion使用CMake构建C语言项目，配置文件为CmakeLists.txt，里面描述了项目中的哪些文件参与编译、头文件路径、编译器参数等信息。构建时由cmake程序加载项目路径下的CmakeLists.txt文件，生成Makefile，指导编译器完成编译操作。

• CubeIDE由于基于Eclipse，项目中参与编译的文件、头文件路径、编译器参数等信息是存放在项目路径的.project文件中，在点击构建时自动生成Makefile，指导编译器完成编译操作，这是Eclipse自身的特性。

2.CMakeLists.txt生成后，CLion自动构建项目时出错，上来就报错，非常不友好

这个错误你一定会遇到，CMakeLists.txt中指定了生成的程序名称，需要使用的编译器，图中可以看到后续编译时需要使用到的编译器名称，但是并没有指定编译器所在路径，因此构建失败。

这里我并不想修改CMakeLists.txt中的编译器路径，因为协作开发时由于编译器版本并不完全相同，所以这里的编译器路径也不完全相同。

这里我采取另外一种方法: 既然CLion调用的cmake程序只知道编译器程序名却不知道所在路径，不如直接配置好CLion下的PATH环境变量，这样只需保证在CLion调用的cmake中，PATH环境变量中包含编译器所在路径即可。

• 依次点击: 文件->设置(macOS用户点击CLion->Prefrences)，左侧找到构建执行部署->CMake，修改当前配置文件Debug的环境变量。
  

• 点击Debug配置文件，点击右侧环境旁边的编辑按钮，勾选包括系统环境变量，找到PATH环境变量，对其进行扩充，扩充的内容就是编译器所在路径，注意分隔符。
  

  这个路径该如何获取？

  • Windows使用Everything搜索一下arm-none-eabi-gcc.exe，在CubeIDE安装路径下的就是。
  • macOS在CubeIDE的APP上右键，显示包内容，右上角搜索arm-none-eabi-gcc，将找到的程序拖入终端，即可获取到路径，注意只拷贝编译器程序所在路径即可。

• PATH的值扩充完毕后点击确定，然后重新加载CMake项目，或手动重新加载
  

• 此时正常生成Makefile脚本，CLion也识别到了编译目标，点击编译按钮项目成功编译。
  

• 点击运行按钮，尝试将程序下载至目标板中，发现无法下载程序，点击调试也进不了调试模式。

3.程序下载失败，运行失败，调试失败，真的烦死了

调试下载过程这里值得说一下，在调试或下载单片机程序时大家都是电脑通过USB连接调试器，然后调试器的SWD或JTAG接口连接目标板，但这是物理层的链路，你看得见摸得着，就这三部分缺一不可。

软件层面的调试下载细节决定了程序如何下载至目标板，这里大家只需知道两个程序: GDB和GDB Server。顾名思义，一个是充当客户端的GDB，一个是充当服务器的GDB Server，二者通过TCP通讯。

客户端是谁？

举个例子: 你在使用CubeIDE的调试功能时，当前程序执行的位置、各个寄存器的值等信息都是客户端GDB从服务端GDB Server获取到的，程序名为arm-none-eabi-gdb。作为客户端，就必然会向服务端通讯.

服务端是谁？

GDB在调试时需要知道程序执行的位置等调试信息，这些信息是硬件调试器通过JTAG或SWD接口从目标设备读取来的，而GDB Server就是调试器硬件与GDB客户端沟通的桥梁，GDB Server会使用USB驱动与外部调试器ST-Link或J-Link等调试器通讯，并创建一个本地TCP服务，等待GDB客户端连接。

GDB调试的链路就是这样打通的，有点类似计算机网络的OSI参考模型，因此链路可以简化为: IDE–GDB–GDB Server–硬件调试器–目标设备(JTAG/SWD)。

所以这就更好理解了，为什么这些IDE们能支持多种硬件调试器，实际上是GDB Server将他们都统一化了，ST-Link使用的是STLinkGDBServer，Jlink也有自己的GDB Server，而OpenOCD本身作为一个能够兼容众多硬件调试器的GDB Server程序，为了就必然要有配置文件去描述接口和硬件规范，这也就是为什么OpenOCD在使用时需要搭配.cfg配置文件来使用。

接下来讲一下如何配置CLion，使用ST-Link搭配STLinkGDBServer完成程序的下载和调试。

• 在右上角的运行/调试配置点击箭头，点击编辑配置;
  

• 点击左上角加号，点击嵌入式GDB服务器，并为改配置文件命名，比如"ST_GDB";

• 目标和可执行二进制文件均选择elf;

• 调试器选择你电脑上CubeIDE安装路径下的arm-none-eabi-gdb;

• 下载可执行文件选择"始终";

• target remote中指定GDB服务器端口，ST-LINK_gdbserver的默认端口为61234，因此填写"tcp:127.0.0.1:61234";

• GDB服务器选择ST-LINK_gdbserver程序所在路径;

• 最后，GDB服务器实参可以从CubeIDE中获取: 使用CubeIDE打开项目，点击调试按钮右侧箭头点击Debug Configurations，点击调试器，看到CubeIDE使用的是ST-Link+ST-LINK_gdbserver的形式调试下载，点击show Command Line可以看到调试时使用的参数。
  

  如图所示，从-p 61234到最后就是参数了，而在CLion中端口号61234作为必须填写的参数已经在target remote中填写了，因此CLion中的GDB服务器参数只需从"-l 31 "开始即可

• 在高级GDB服务器选项中，将重置命令设置为从不，防止由于程序起始地址不是默认的0x8000000导致无法在断点处停下。最后填写后的窗口如图
  
  调试时在main函数内的第一行打个断点，运行配置选择ST_GDB，点击调试按钮，此时CLion就会调用GDB Server连接目标设备，调用GDB连接GDB连接GDB Server的61234端口，调试链路打通，成功进入调试模式。