AT32编译、下载、调试全自动命令行调试环境搭建

目标： 受之前esp32全自动开发启发。 想着能不能让AT32这类单片机开发也能自动化跑起来。在 VSCode / Cursor 中，通过 PowerShell 命令行实现一键编译、烧录、RTT 日志捕获、GDB 源码级调试，并交付 Cursor AI 自动调度。

【ESP32学习实录】非官方板适配ESP-Claw：从环境搭建到源码修改

硬件与工具链

项目结构

textF:\桌面\AT32F403AVGT7\project\MakeFile\
├── Makefile              # AT32 Work Bench 生成，稍作修改
├── AT32F403AxG_FLASH.ld  # 链接脚本
├── startup_at32f403a_407.s
├── build/                # 编译输出目录
├── debug/                # 自动化脚本目录
│   ├── flash.jlink       # J-Link 命令脚本
│   ├── flash.bat         # 烧录批处理
│   ├── rtt_capture.bat   # RTT 日志捕获
│   └── gdb_server.bat    # GDB 服务器启动
└── AI规则.md             # Cursor 项目规则

想法其实很简单——我就坐在Cursor前面，说一句“帮我编译烧录然后抓10秒日志分析一下”，它自己就去跑完全部流程，最后把结果告诉我。跟使唤小弟一样。

但想法归想法，真正搭起来中间还是踩了几个坑。

第一步：编译

这个最简单 编译反而是最顺的。AT32 Work Bench生成的Makefile本身就支持命令行，而且默认开了-g -gdwarf-2调试信息和-Og优化，不用我操心。这样只要注意确保有gcc编译链就行了。我是偷懒用的用的之前安装的AT32_IDE里的编译链。在PowerShell里敲一下就行：

mingw32-make clean mingw32-make -j$env:NUMBER_OF_PROCESSORS

  如果能正常生成build/AT32F403AVGT7_WorkBench.elf和.bin，那编译这关就算过了。

第二步：烧录

    踩了第一个坑 烧录用J-Link命令行，本来以为很简单。我在项目的debug目录下建了一个flash.jlink脚本：

device AT32F403AVGT7si SWDspeed 4000connectloadbin build/AT32F403AVGT7_WorkBench.bin 0x08000000rgexit 

然后在同一个目录下写了个flash.bat：

@echo off"D:\app_major\jlink\install\JLink.exe" -NoGui 1 -CommandFile flash.jlink

 结果一跑就报Failed to open file——找不到bin文件。

坑点1：路径不对。 我在PowerShell里站在项目根目录执行.\debug\flash.bat，但批处理的工作目录没切过去，J-Link在debug目录下找build/…，鬼才找得到。

解决：批处理最前面加一行cd /d “%~dp0…”，退到项目根目录再干活。

坑点2：芯片型号不对，手动查了一下需要前面多个-。也是安装的AT官网下的jlink支持包但是型号都多了个-

两个坑填完之后，烧录终于正常了，log里出现Flash download: Program speed: 43 KB/s那一刻，还挺有成就感的。

PowerShell后台作业又踩一坑 RTT这块，我的固件已经集成了SEGGER RTT库，不需要额外干活。PC端用J-Link自带的JLinkRTTLogger.exe就行。结果在中文编码上有踩坑了，因为我的文件用的GB2312，解析也得需要都改成GB2312。

坑点3：后台作业的当前目录不是你以为的那个目录。 PowerShell后台作业默认的当前目录是你的用户文件夹，不是项目根目录。所以.\debug.…这个相对路径在作业里不成立。

解决也不难，用$using:PWD把当前目录传给作业： 

$rttJob = Start-Job -ScriptBlock { Set-Location $using:PWD; & “.\debug\rtt_capture.bat” } 

先切目录再执行，搞定。由于这是个新项目目前功能还不是很多，打印信息也比较少。

第四步：GDB调试

反而最顺 GDB我走的是“一次性脚本”路线。先启动GDB Server：

start "JLinkGDBServer" "D:\app_major\jlink\install\JLinkGDBServer.exe" -device AT32F403AVGT7 -if SWD -speed 4000 -port 2331

然后写一个GDB脚本test.gdb：

target remote localhost:2331loadbreak maincontinuebacktraceinfo registersquit

用arm-none-eabi-gdb -batch -x test.gdb build\AT32F403AVGT7_WorkBench.elf一把梭跑完。

跑出来的结果：

程序下载成功：Loading section .text, size 0x12998

断点精准停在main的第89行，所有寄存器打印得明明白白。最后自动退出，不需要交互

这一步意外地顺畅，什么坑都没有。可能因为前面的坑已经把该踩的都踩完了。

后面又陆陆续续加了一些脚本最终的脚本文件也不少。

最后一步：写规则

        让Cursor学会干活 所有命令跑通之后，我把这些流程写成了一个AI规则.md文件，丢在项目目录下。规则里写清楚了：

用PowerShell语法，别给我整cmd那套&&

编译器在哪、J-Link在哪、芯片型号是啥

标准流程：编译→烧录→抓RTT→分析日志

GDB调试怎么做：启动Server→生成脚本→执行→清理

规则放进去之后，我直接在Cursor里说：

“一键下载并抓10秒RTT日志分析是否正常运行”

它就自己跑完了全部四步，最后根据日志告诉我运行正常。

“停在main然后打印寄存器”

它就启动GDB Server，写了个临时脚本，跑完把寄存器状态返回来，然后自己打扫干净。

总结一下

整个流程跑通之后，这套东西大概长这样：

关键点就几个：路径要对齐、脚本要健壮、规则要写清楚。至于固件本身，啥也不用改——RTT库你本来就集成了，GDB调试是芯片自带的能力，编译选项Makefile也帮你配好了。

现在坐在Cursor前面，跟使唤小弟一样使唤AI帮我调试，这感觉确实挺爽的。需要我的脚本配置的可以公众号留言 “嵌入式自动化脚本”