问题描述
在基于STM32F4的系统中，我使用SWO进行跟踪输出（以常规方式拦截_write()以使用ITM_SendChar()）。我可以在ST的[基于Eclipse]的Cube IDE中以2 MHz的SWO时钟（核心时钟168 MHz）无缺陷地查看SWO的输出。从来没有一个问题。但是，我需要为CI可以阅读的流，并且一直在使用OpenOCD [0.10.0 + dev-01193-g5ce997d（2020-02-20）]，意法半导体在其工具链中提供了意法半导体，并提供了意法半导体提供的设置脚本。那。
此主要正常运行，除了大约50％的时间OpenOCD不写出跟踪输出的末尾。这与我在Cube IDE中使用的目标HW / SW完全相同，因此它必须是PC端工具，而不是目标HW / SW问题。它看起来像一个缓冲问题，因此我也尝试过使OpenOCD通过其TCL服务器端口导出SWO流，而不是将其写入文件，但是行为方式完全相同。
目标硬件/软件没有崩溃，我从一个闪烁的LED看到它已经执行完毕，并且标准ITM_SendChar()实现（从CMSIS标头）阻塞在一个寄存器值上，直到该字符已发送，因此从目标SW的角度来看不会遗漏任何东西。但是不知何故，结局已经消失了。
是否有人对此主题有任何建议或建议？
我正在使用参数OpenOCD：
-c "init" -c "itm port 0 on" -c "tpiu config internal swo.dat uart off 168000000 2000000" -c "reset init" -c "resume"
...当然，它指向ST的STM32F4配置和接口文件。
这一切都在Windows 10上，以防万一。
解决方法
最后，我弄清楚了如何使用ST-Link GDB服务器，这是STM32Cube IDE在幕后使用的服务器，因为这样做并没有显示问题。但是，如果其他人遇到此问题，以下是我从某人那里收到的一些建议，该人已成功使用OpenOCD在STM32F7平台上进行SWO捕获：
- 我使用的是最新版本的openocd xpack（由ST Cube IDE提供的openocd和gcc版本已经过时，并且已经出现了许多问题。 自原始发布以来已更正。）
- 我必须将gdb事件添加到我的.cfg文件中，以强制itm端口一致地初始化和刷新...使用以下操作：
$_TARGETNAME configure -event gdb-detach { itm port 0 off; itm port 1 off; reset; shutdown } $_TARGETNAME configure -event gdb-attach {adapter_khz 4000; itm port 0 on; itm port 1 on}