如您所知，与GNU工具的兼容性以及对GDB的支持使得几乎任何流行的开发环境都适合调试各种嵌入式平台，并且大多数情况下是免费合法的。 从理论上讲。
尝试与STM32和NetBeans交朋友时在实践中会发生什么，并且从原理上讲，有可能在削减成本的情况下获得支持最新宝石的可行系统。
一些歌词
我真的不想离开微芯片。 但是，在被Atmela收购之后，他们首先掩盖了该公司产品组合中最有前途的家族之一-PIC32MM，然后是整个MIPS系列。 很明显，在可预见的将来，向ARM过渡是不可避免的，因为两年来的微芯片尚未在其生态系统中集成Atmelovsk控制器的支持，因此“与我们同行”并没有任何优势。 相反，合并的上升定价政策和传统的组织困难使Atmelovskiye AWP的吸引力下降。 同时，一个项目被PIC32MZ偶然发现。 已经达到临界质量。
为什么选择STM？
调试-第一印象
SW4STM32以传统方式安装-反复按下Next>按钮（以下简称*，所有实验均在Win7 x64上进行）。 从STM32Cube固件包中删除了一个适合测试所需功能的演示项目，所有内容或多或少都可以立即使用。 JTAG仿真器的首次启动给人留下了深刻的印象：事实证明，进入调试模式的整个周期（从连接开始，到main（）的开头停止，并更新上下文）可以在1-2秒内完成。 与微芯片调试器（甚至REAL ICE一半）相比，速度的差异是倍数！
然而，有些令人不愉快的惊奇。
Eclipse / SW4STM32有什么问题
大量的设置和不合理的组织，隐藏的菜单项，视角，界面错误和视觉伪像，工具栏上缺少常用的快捷按钮和功能，笨拙，无法理解的象形图和标记，缺少“查找用法”在某种程度上是主观的，并且您可以根据需要进行调整。 但是：尽管在必要时会勾选所有复选标记，但通常会在汇编之前忘记保存已修改的文件； 在强制手动保存的情况下，它看不到更改，并且增量装配件被证明是无关紧要的； 没有作为一个团队进行的完整重建（Clean and Build），并且在通过Clean Project进行强制清理之后，程序集失败（文件访问？），并且仅在第四次尝试之后才成功完成-无法再作合理解释。 甚至十年前基于古老NetBeans 6.xx的MPLAB X Beta发行版也没有10年前与今天官方支持的STM32开发环境相同的问题。
此外，使用SW4STM32，已经在系统中拨打了3个典型IDE的副本，因为除了它之外，仍然将MPLAB X牢牢地钉在NetBeans 8.0.1上，并且有点被围起来（即，不可能将其用于其他语言/平台），以及适用于Java和C / C ++的NetBeans 8.2。
事实证明，设置NetBeans 8.2与STM32一起使用将消除上述的Eclipse实际问题，减少IDE副本的数量，并将其缩减为一个平台，尽管版本略有不同。
NetBeans 8.2和GNU ARM工具
NetBeans最好使用32位，因为除了使内存消耗增加一倍之外，没有发现64位版本的差异。
Google很快找到了
安装指南 。 主要区别仅在于操作系统（对我而言，它们具有针对Win7 x64的Linux），因此安装MinGW软件包中包含的* nix-environment MSYS成为有奖游戏。 工具链设置应如下所示：
重要的一点-添加GNU ARM工具链时，选择“ GNU MinGW”系列，在这种情况下，NetBeans将正确调用MSYS。 如果计算机上已经安装了Cygwin，则使用它是合乎逻辑的；因此，GNU ARM系列应选择“ GNU Cygwin”。
实现成功的编译并非易事，但非常简单。 由于SW4STM32使用相同的编译器，因此请在SW4STM32中查看编译器调用的命令行，然后在项目属性→C编译器→其他选项中复制缺少的键。
我们得到的输出结果完全相同，但是有一个重要的实际差异-第一次收集所有内容，有Clean and Build，并且工作正常：
但是，通过添加可选的后期构建处理，也可以改善此结果。 打开Makefile，然后在.build-post：.build-impl部分中添加：
.build-post: .build-impl cp ${CND_DISTDIR}/${CONF}/${CND_ARTIFACT_NAME_${CONF}} ${CND_ARTIFACT_NAME_${CONF}} arm-none-eabi-objcopy -O ihex ${CND_ARTIFACT_NAME_${CONF}} ${CND_ARTIFACT_NAME_${CONF}}.hex arm-none-eabi-size ${CND_ARTIFACT_NAME_${CONF}}
（重要-缩进必须是单个制表符，而不是空格）
逐行：1-将目标文件（.elf）从输出文件夹复制到项目的根目录，以便于访问； 2-从elf生成HEX（如果不需要HEX，可以将其注释掉）； 3-按段显示已占用的内存量。
最终结果：
到目前为止一切顺利。
OpenOCD-第一个困难
在上述在线手册中，通过OpenOCD编程芯片既简单又常规。 安装最新版本（0.10.0），获取配置文件（从OpenOCD套件或从项目文件夹SW4STM32），在“项目属性”→“运行”中写入格式命令。
一切都会立即生效。 确实，对于STM32F103和F407等较年轻的家庭来说就是这种情况，但是我对F7和H7感兴趣。 首先，正式版本的OpenOCD 0.10.0崩溃，错误为“ auto_probe failed”和“ undefined debug reason 7”； 完全不支持后者。 从2017年1月到2018年1月，我们尝试了所有可用的官方程序0.10.0-结果相同。 关键字搜索可以确认问题的存在，尽管您不能将其大量命名。 没有分析和解决方案。
但是有一个肯定可以使用的版本-来自SW4STM32套件。 自然地，事实证明它得到了改进和补充，有了新的脚本和对H7系列的支持。 此外，文件结构也发生了变化，并且插件中的资源存储在单独的模块中，因此，为了使实用程序合并到一个文件夹中才能查看其脚本，需要使用-s开关。
NUCLEO-F767ZI的Board.cfg，无任何评论，并压缩为：
set CHIPNAME STM32F767ZITx source [find interface/stlink-v2-1.cfg] transport select hla_swd source [find target/stm32f7x.cfg] set WORKAREASIZE 0x10000 set ENABLE_LOW_POWER 1 set STOP_WATCHDOG 1 reset_config srst_only srst_nogate connect_assert_srst set CONNECT_UNDER_RESET 1
最后通过运行主项目启动：
固件成功，代码正在执行。
侦错
该方案被认为是最传统的方案：OpenOCD上的本地GDB服务器，NetBeans通过localhost通过TCP通过3333连接到它。 因此，NetBeans将需要Gdbserver插件。
可以通过bat脚本简化OpenOCD的启动，由于会话完成后进入了控制台，因此可以无休止地循环重启：
:start openocd -f debug.cfg -sd:/Prog/openocd/scripts goto start
发射：
未明确编写来自SW4STM32的版本，但是服务器正在等待与端口3333的TCP连接。在NetBeans中，选择“调试”→“附加调试器...”，然后安装：
会话处于活动状态。 OpenOCD终端：
从外观上看，一切看起来都很好-调试会话处于活动状态，代码已执行。 但是，问题仍然存在。
问题
在自由运行模式下，无法停止执行。
如果在开始会话之前设置了断点，则在进入调试时，它将停止更新上下文，逐步执行并查看/更改变量将起作用，也就是说，原则上，完全调试所需的所有基本功能：
但是仅直到下一次自由启动，此后它才保持关闭并重新启动会话。
另一个不愉快的琐事与软件断点相关：SYSTEM_Halt（）函数定义为__asm__（“ bkpt”），其操作导致显示不必要的对话框：
当您单击“放弃并暂停”时，它会按要求工作（即停止执行），但是，默认情况下无法设置此选项并通过标准方式关闭窗口显示。
在堆之前，我想自动启动OpenOCD并直接通过NetBeans连接调试器。
但是，客观上，唯一不足以进行或多或少完整调试的功能是停止执行（还需要即时设置断点）。
调试调试
谷歌搜索显示，NetBeans停止GDB的类似问题已停止，但几年前已解决。 由于缺少更好的主意，因此下载了NetBeans源，希望能逐步调试一下。 令人惊讶的是，我们能够在调用外部实用程序GdbKillProc.exe之前快速定位问题，该实用程序实际上是WinAPI中DebugBreakProcess（pid）的包装。 该实用程序的原理简化为该过程的一种非侵入式中断（在* nix下或控制台中的Ctrl + C下类似“ kill -SIGINT [pid]”的模拟）。
但是她不工作。
测试了什么
在控制台模式下，GDB客户端（arm-none-eabi-gdb.exe）对Ctrl + C作出正确反应，即，它在不关闭会话的情况下停止执行代码，并等待进一步的指示。
ps -W和Windows Process Explorer正确显示进程，并且PID与NetBeans中的内部变量匹配。
从MSYS软件包中手动调用“ kill -SIGINT [pid]”会引发“无此过程”错误。
通过检查“ taskkill / pid [pid]”会产生“该进程...无法终止...只能强制终止该进程...”，这似乎表明系统已锁定。 使用/ f开关，该过程完全关闭，这也不是很好。
在此过程中，事实证明，在Windows中，产生中断信号的情况并不重要，或者根本没有关系：默认情况下仅支持SIGTERM模拟，这对应于该过程的粗略削减，并且没有公认的解决方案。
在Internet上，发现了一个Windows-kill实用程序，旨在模仿Ctrl + C和Ctrl + Brk。 进程发现中断发送没有错误，但是GDB客户端仍然没有响应。
实验使用所有32位版本（NetBeans，ARM Tools，MSYS 1.0）进行，但Windows-kill拒绝启动32位（“ ...无法正确启动...”）。 也许正是因为这个问题，因为根据论坛和Bugtrackers的零碎数据，该实用程序的位深度与过程应该一致。 这里的困难是ARM不提供Windows的x64版本的工具链，包括消除异质性的唯一方法是使x32版本的Windows-kill正常工作，这也不清楚在Win x64原则上是否可行。
在此过程的中间，从头开始重新安装了OS，没有发现实验对象的行为发生任何变化，包括非常有信心地可以消除特定系统的功能。
需要大厅协助
实际上，以上所有内容都可以视为本段的介绍。
剩下的最后一步是使NetBeans下的STM32调试成为现实：
需要一种有效的软件机制来将SIGINT中断信号（Ctrl + C）发送到Windows GDB客户端进程以下是设置足以验证/调试上述问题的最低配置的建议。 如果/当它可以解决时，将在一个简单的分步指南中重做这篇文章，内容涉及如何为几种不同的系列和调试板配置NetBeans + OpenOCD。 已有功能可行的基本解决方案，可以随意完成其他功能。
测试设置
建议使用基于STM32F103C8T6的Blue Pill板和克隆的ST-Link V2作为硬件平台。
有必要：
1.安装
GNU Arm嵌入式工具链2.安装OpenOCD 0.10.0（
在Win下构建 ）
3.在PATH（控制面板→系统→高级系统设置→环境变量...→路径）中注册两个软件包的bin文件夹。
4.在方便的地方创建board.cfg文件，复制内容：
source [find interface/stlink-v2.cfg] source [find target/stm32f1x.cfg] transport select "hla_swd" reset_config none separate set WORKAREASIZE 0x5000 set CHIPNAME STM32F103C8T6 set ENABLE_LOW_POWER 1 set STOP_WATCHDOG 1 set CLOCK_FREQ 4000 set CONNECT_UNDER_RESET 1
5.选择适当的测试固件（test.elf），主要标准是执行和停止有明显区别。 复制到方便的地方。
6.在方便的地方闪动电路板：
openocd -f board.cfg -c "program test.elf verify reset exit"固件应启动。 OpenOCD输出到控制台的示例：
7.在方便的地方启动OpenOCD GDB服务器：
openocd -f board.cfg代码仍在执行； 样本输出（控制台保持被OpenOCD锁定）：
8.在另一个控制台中，或直接从GNU ARM嵌入式工具链包运行arm-none-eabi-gdb.exe并执行以下命令：
target extended-remote localhost:3333 （代码仍在执行）
continue （代码正在运行，控制台已锁定）
Ctrl+C （代码已停止，控制台处于活动状态）
continue （再次运行，控制台已锁定）
任务是通过编程从执行状态（即本质上模拟Ctrl + C）中删除GDB客户端。
要查找进程ID，请在* nix环境中使用“ ps -W”，或使用Windows Process Explorer（可选安装）。
也许有人会在NetBeans的初始设置后立即正确调试-这些信息也将很有用，尤其是在详细描述系统和可能的功能时。
请在评论中分享想法，我希望通过合作，我们可以将一个大胆的实验变成有用的指南，以建立一个更加有用的工具。