Skip to main content
Glama

运行一段时间后自动暂停

run_timeout

Run the target MCU at full speed for a requested duration, then auto-pause and return the halt location with source and call stack for timing verification and state inspection.

Instructions

让目标 MCU 全速运行 timeout_ms 毫秒后自动暂停,并返回停靠位置(文件行+源码+完整调用栈)。用于验证时序 / 观察运行 N 毫秒后的状态。timeout_ms 默认 1000。时长以分段字段给出,别混用:requested_run_ms 是你请求的运行时长;actual_run_ms 是实测「run 返回 → 发 stop」的间隔(Windows 定时器粒度约 15.6ms,请求 137ms 时实测常在 140~155ms,属 sleep 精度而非工具延迟);stop_wait_ms 是 stop 之后等目标确认停止的耗时(这才是 wait_stopped.waited_ms 的含义,它与 timeout_ms 无关,不要当运行时长用);total_ms 是整次调用总耗时。halt 落点还受 UVSOCK 往返影响,毫秒级精度要求请改用 DWT 周期计数或 GPIO 打点。注意:到点 stop 后会轮询确认目标真正停止(stop 是异步生效的)才读 PC;若未能确认停止,返回 stopped=false + warning 且不返回停靠位置,避免把陈旧 PC(常量落复位附近 0x0800024c 之类)误当成停靠点。另外真机实测:halt 后首次读到的 PC 常是上一次 halt 的残留值(LR/SP 已是新值),故读取按'连续采样收敛'判定(连续两次 PC/LR/SP 一致才采纳),返回 pc_confidence=high/low;low 表示采样未收敛或复查发现目标其实仍在运行,PC 不可信,请重试。返回里始终带 pc_confidence 与 stop_verified:stop_verified=false 表示「没能确证目标已停」,此时绝不要把任何地址当停靠点(真机踩过:报出 HAL_Init / 连续同一个地址,而目标其实在跑)。若你怀疑目标没停或反复复位,请改用 wait_breakpoint(等断点命中)或 read_variable / 串口输出交叉确认。到点常停在 SysTick 等中断上下文,此时局部变量与调用栈层数可能受限/为空,AAPCS 寄存器解读不适用。需已进入调试且配置 .axf。 【参数】必填: 无;可选: timeout_ms 【调用示例】{} 【风险】中——会改变目标状态或占用共享资源(调试态/串口/Keil 实例),必要时可回退。 【参数别名】timeout_ms(毫秒) ← duration/duration_ms/duration_s/max/max_ms/max_s/ms/timeout/timeout_s/wait/wait_ms/wait_s;带 _s/_ms 的别名按后缀换算(_s=秒、_ms=毫秒)。规范名以上方【参数】行为准;未列出的参数名会被拒绝,不会静默忽略

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
timeout_msNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.8

TDQS

A4.9/5.0
Behavior5/5

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

With annotations offering only false flags valuation-description carries full behavioral burden delivered richly: it discloses asynchronous stop confirmation, stale PC residue, convergence-based sampling, pc_confidence/stop_verified semantics, Windows timer granularity, UVSOCK effects, and SysTick interruption context limitations. It also clearly states preconditions (must be in debug mode with .axf configured).

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

Conciseness4/5

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

The description is long but front-loaded with the core behavior and then structured into important caveats, parameter details, aliases, and risk. It is densely informative, though a few concepts (e.g., stale PC and stop_verified=false warnings) are reiterated, creating slight redundancy.

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?

Given the tool's complexity and the output schema existence, the description is exceptionally complete: it explains return fields, failure modes, when not to trust results, alternatives, side effects, and preconditions. Nothing an agent needs to call this safely and interpret results correctly is missing.

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?

Schema coverage is 0%, but the description fully compensates: timeout_ms default is 1000, aliases with unit conversion are listed, and the output timing fields (requested_run_ms, actual_run_ms, stop_wait_ms, total_ms) are carefully distinguished to prevent misuse. For the single optional parameter, semantics are complete.

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?

Description opens with a specific verb+resource: runs the target MCU at full speed for timeout_ms then auto-pauses, returning a stop location with file line, source, and full call stack. It states the intended use (verifying timing / observing state after N ms), clearly differentiating it from related run/stop/wait_breakpoint tools.

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?

It explicitly says when to use the tool (timing verification / observing state after a fixed duration) and warns against relying on it for millisecond-level precision, recommending DWT cycle counting or GPIO toggling instead. It also instructs to switch to wait_breakpoint or read_variable/serial output when the target might not have stopped or is repeatedly resetting.

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