Skip to main content
Glama

UV4 命令行批处理调试(-d + 初始化文件)

batch_debug_script
Destructive

Execute a fixed sequence of Keil debug commands in command-line batch mode for repeatable smoke/regression testing without UVSOCK.

Instructions

用 Keil 官方命令行批处理通道跑一段固定的调试脚本:UV4 -d <工程> -j0 进调试并执行初始化文件里的命令序列。不依赖 UVSOCK(不需要 Keil 里开着 UVSOCK、也不怕连接被占/空闲断连),适合可重复的冒烟/回归(复位后采现场、跑几步看寄存器、抓一段打印),以及 UVSOCK 不可用时的降级通道。交互式排查请仍用 UVSOCK(enter_debug + keil_command)——那条通道可以中途改主意,本通道是「一条道跑到黑」。 commands:命令清单(数组,或换行分隔的字符串),一行一条。常用的有 g, main(运行到 main)、BS <符号>(下断点)、BLG(跑到断点)、T/P/O(单步)、EVAL <表达式>printf("%08X", _RDWORD(0x20000000))(无头读内存)。 四条真机实测的坑(工具已尽力兜住)

  1. 命令报错不改退出码(UV4 恒回 0):成败只认日志里的 *** error N, line M。本工具把退出码、逐条命令的 error、以及每条命令是否走到完成标记分开返回,ok 字段是综合判定结果。

  2. Go main / Go挂死(官方语法是 g, main,逗号不可省);DISPLAY/SAVE-j0 无头模式下也挂死。这两类写法会被静态检查提前告警,但仍请避开。

  3. 无窗口焦点时单步退化为指令级T 会进函数逐条指令走)。

  4. 每轮 15~25s(含进调试 + Erase/Program/Verify),显著慢于 UVSOCK;timeout_s 默认 240。 实现细节:初始化文件与 trace 日志写在系统临时目录(ASCII 路径,真机实测中文路径会 UnicodeEncodeError),并把路径写入 .uvoptx 的 <tIfile>前置备份、无论成败都还原,不会把你的工程改脏。返回 artifacts 里给出 init_file / trace_log / workdir 现场路径,log_tail 是日志尾部。高风险:会真正进调试并下载程序(Erase/Program/Verify)。 【参数】必填: commands;可选: project, timeout_s, visible 【调用示例】{"commands": [{"tool": "read_mem", "args": {"addr": "0x20000000", "n_bytes": 16}}]} 【风险】高——不可逆:会改写目标 Flash/内存,或关闭/重启用户的 Keil 实例。执行前确认目标与工程正确。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
projectNo
visibleNo
commandsYes
timeout_sNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.8

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate destructiveHint=true, but the description goes far beyond by detailing the exact destructive actions (Erase/Program/Verify), the fact that it can close/restart Keil, the return-code pitfall (always 0), the hang-prone commands, and the backup/restore behavior. This full disclosure significantly exceeds what annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Though long, the description is exceptionally well structured: core purpose upfront, then bullet-pointed pitfalls, then implementation details, then parameters and an example. Every sentence adds value – no fluff. The front-loading and use of headings/bullets make it easy to scan and grasp quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a high-risk, high-complexity tool with annotations and an output schema, the description is essentially complete. It covers purpose, usage, parameters, return values (artifacts, log_tail), risk warnings, and even handles edge cases like Unicode paths. An agent has everything needed to call it correctly and understand consequences.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description carries the entire burden of parameter explanation. It explains commands (array or newline-separated), gives concrete command syntax examples, notes timeouts, mentions the optional project and visible parameters, and even describes the return artifacts. This fully compensates for the missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description precisely identifies the tool as a UV4 command-line batch debug channel that runs a fixed init-file script. It clearly distinguishes this from the UVSOCK interactive channel by naming the alternative (enter_debug + keil_command) and stating when each is appropriate. This gives an agent a definitive understanding of what the tool does beyond its name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states use cases (repeatable smoke/regression, fallback when UVSOCK unavailable) and explicitly tells agents to use UVSOCK for interactive troubleshooting. It also warns about hangs and slower execution, providing concrete operational guidance and criteria for choosing this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.