debug - eclipseCPP + openocd + 引入arm-gcc makefile工程来单步调试

debug - eclipseCPP + openocd + 引入arm-gcc makefile工程来单步调试

概述

开源工程如果是用IDE建立的工程，跟着人家走就行。

但是如果开源工程是用arm-gcc + makefile工程来实现的，这时，为了单步调试方便，就不能跟着作者的调试思路走。
想当然的就会想将开源工程迁移到可以图形化调试的IDE中。

前面做了实验，已经可以将arm-gcc + makefile的工程导入MCUXpresso来单步调试。
不过，好像MCUXpresso有bug, 导致有些开源工程(arm-gcc + makefile)工程导入MCUXpresso后，无法单步调试。
现象：开始调试后，已经连上了板子上的调试器，但是会快就会显示reset, 调试器进程就断开了。

如果用MCUXpresso自己做的工程当然没问题，能单步调试。这没用啊。
如果不能引入makefile工程并稳定的单步调试，那就不能用MCUXpresso来干这事。

我前面的实验，将正常单步调试的MDK工程，整理了一个makefile工程，产生的elf是一样的. 但是导入MCUXpresso后，无法单步调试。连接板子后，就会显示reset后，就断开了。这明显就是MCUXpresso的LinkServer有bug了。

也不能说一定是LinkServer有bug, 也许是LinkServer要求的elf格式更严格(e.g. elf的cheksum的细节检查更严格之类的问题)
也许导入makefile到MCUXpresso后，可能makefile和.ld的规则控制要更精细，才能生成符合LinkServer要求的elf, 这不是正常研发能搞得定的事情。毕竟不是每一个人都对gcc编译器的内部实验那么熟悉。

MCUXpresso转发arm-none-eabi-gdb的消息时，显示reset连接，错误是未知的reset.
如果硬要去搞定这个问题，就需要看看reset提示是咋来的，要去调试arm-none-eabi-gdb, 这哪是普通研发能搞定的事情?
如果是刚需，那硬着头皮也要去搞(缺啥学啥，堆够时间，弄懂细节，水到渠成)。如果还有其他方法，就去实验其他方法。

今天试了一下eclipseCPP, 导入正常的makefile工程，配好arm-gcc工具链 + openocd, 是可以正常单步调试的。
那以后要研究arm-gcc + makefile的开源工程时，就用这种调试方法了。

笔记

实验环境

win10
arm-gnu-toolchain-14.3.rel1-mingw-w64-x86_64-arm-none-eabi

openocd-20250710
openocd还有一个预编译版本(xpack-openocd-0.12.0-7-win32-x64), 因为实验已经成功，就没有实验这种openocd

eclipse-cpp-2025-09-R-win32-x86_64

实验

实验的makefile工程

我用的前面笔记(debug - MDK - arm-none-eabi - 从MDK工程做一个makefile工程出来)中的makefile v0.9

先确认makefile工程是可以正常编译的，因为我前面笔记已经确认过elf和相同源码的mdk工程的elf一致。我现在只要确认能正常编译过，就可以进入后续实验了。

将makefile工程引入eclipseCPP

启动eclipseCPP工程时要带环境

直接启动eclipseCPP时，是没有make和arm-gcc环境的.
为了不污染win10全局的path, 做一个bat来带上环境，并启动eclipseCPP.

start_eclipsecpp_with_arm_gcc_and_make.bat

@echo off
rem @file start_eclipsecpp_with_arm_gcc_and_make.bat
rem @breif 通用的arm-gcc工具链，编译哪个工程都可以
set path=%~dp0arm-gnu-toolchain\bin;%~dp0gnuwin32\bin;%~dp0curl;%path%
set path=D:\tools\eclipse\eclipse-embedcpp-2025-09-R-win32-x86_64\eclipse;%path%start eclipse.exe
cmd /k "echo %~nx0 && title %~nx0"

运行 start_eclipsecpp_with_arm_gcc_and_make.bat ，启动eclipseCPP

新建工作区

整一个新工作区开始实验。

配置arm-gcc工具链

确认工具链明显没有配置?

如果不确定arm-gcc工具链是否已经配置，可以先清理一下工程，如果看到没动静，或者和自己的makefile清理逻辑不一样，就需要配置arm-gcc工具链。

配置arm-gcc

尝试编译或者清除工程，和自己的makefile逻辑一样就ok.
我的makefile中，打印出了用到的arm-gcc的全路径，这样我就知道是不是用到了我指定版本的arm-gcc.

配置openocd

工程编译过后，来配置openocd.
如果工程中不止一个elf, 或者eclipseCPP将elf填错了，自己重新指定一下。

如果自己确认时，没看到openocd的全路径，就需要自己指定openocd的exe全路径

指定openocd调试参数

-f interface/cmsis-dap.cfg -f target/lpc17xx.cfg

这个参数指定了调试器是啥，MCU是啥。
因为我用的是官方开发板OM11043(mbed-NXP-LPC1768), 板载调试器LPC-LINK原始刷的是CMSIS-DAP固件，所以调试器配置文件选为 cmsis-dap.cfg. 官方板子的MCU是LPC1768, 所以MCU配置文件选的是lpc17xx.cfg.
interface/cmsis-dap.cfg 和 target/lpc17xx.cfg都是在openocd的目录下，openocd.exe他自己会去找相对路径，我们不用管。

开始调试

将板子连上计算机，没有win10错误配置信息。
在代码上先下好断点。

如果不在调试UI, 会提示是否切到调试UI, 选择“切换”
可能由于通讯速度的问题，有点慢，等一下。反正不是成功，就是报错。等着他。
如果等的不耐烦，或者不确定是否停了下来。去看一眼run菜单。

如果在下了断点的情况下，只有挂起和中止，openocd又没有报错信息，说明还在连接调试器，或者已经跑起来了(所以要先下断点)。
如果等了一会，还不确定是否已经断下来了，可以去看run菜单。

如果看到可以单步的F5, F6菜单，就说明已经可以单步了。

那现在就可以F5/F6的单步了。

备注

现在可以单步调试了，实验就完成了。
具体的openocd参数是否合适(是不是单步时，显得有点慢)？可以看一下openocd的提示信息，看看是不是可以在openocd参数配置那里，覆盖一些 interface/cmsis-dap.cfg ， target/lpc17xx.cfg 中提供的参数。

反正如果是正常情况，就用默认的openocd官方配置好的参数，就能用(能单步调试)。

openocd的提示信息备份

Open On-Chip Debugger 0.12.0 (2025-07-10) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
libusb1 d52e355daa09f17ce64819122cb067b8a2ee0d4b
For bug reports, readhttp://openocd.org/doc/doxygen/bugs.html
DEPRECATED! use 'gdb port', not 'gdb_port'
DEPRECATED! use 'telnet port', not 'telnet_port'
DEPRECATED! use 'tcl port' not 'tcl_port'
Warn : DEPRECATED: auto-selecting transport "swd". Use 'transport select swd' to suppress this message.
cortex_m reset_config sysresetreq
Started by GNU MCU Eclipse
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: Atomic commands supported
Info : CMSIS-DAP: FW Version = 1.10
Info : CMSIS-DAP: Serial# = 16017043
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 1 SWDIO/TMS = 0 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 10 kHz
Info : SWD DPIDR 0x2ba01477
Info : [lpc17xx.cpu] Cortex-M3 r2p0 processor detected
Info : [lpc17xx.cpu] target has 6 breakpoints, 4 watchpoints
Info : [lpc17xx.cpu] Examination succeed
Info : [lpc17xx.cpu] starting gdb server on 3333
Info : Listening on port 3333 for gdb connections
Info : accepting 'gdb' connection on tcp/3333
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1078 ms). Workaround: increase "set remotetimeout" in GDB
Warn : Prefer GDB command "target extended-remote :3333" instead of "target remote :3333"
[lpc17xx.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc
[lpc17xx.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc, semihosting
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1471 ms). Workaround: increase "set remotetimeout" in GDB
Warn : Boot verification checksum in image (0x00000000) to be written to flash is different from calculated vector checksum (0xefff7a2e).
Warn : OpenOCD will write the correct checksum. To remove this warning modify build tools on developer PC to inject correct LPC vector checksum.
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (3273 ms). Workaround: increase "set remotetimeout" in GDB
[lpc17xx.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc, semihosting
[lpc17xx.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc, semihosting

1. 从提示信息可以看到，我们没有显势指定去连接SWD.
2. clock speed 10 kHz, 有点慢。可以查一下配置，覆盖一下默认参数。
3. set remotetimeout 超时没设置，现在默认的参数是一秒，可以改大点。
4. “target extended-remote :3333” instead of “target remote :3333” 端口规则格式要改一下。
5. elf的checksum是0，openocd帮我们改了。这个应该是makefile和ld该做的事情，不过暂时不知道怎么搞。
6. 当看到 halted due to debug-request, current mode: Thread时，就是断下来了。

刚接触openocd, 也不知道这些参数该覆盖成啥？参数格式怎么写？
那等以后有就会再去研究。

反正现在用eclipseCPP + openocd 已经可以引入并调试 arm-gcc + makefile的工程。
且用eclipseCPP比用MCUXpresso好太多了。

MCUXpresso只适合他自己建立的工程，可以正常调试。对于引入的第三方的makefile工程，可能检查过于严格(e.g. elf的cheksum值)，导致无法单步调试。

END