主题

MCU flashing integration

MCU flashing integration 表示项目通过 espflash 管理 ESP32 系列,通过 probe-rs 管理 STM32/其他 probe-supported MCU,并把这些 backend 接入项目配置或明确的本地操作入口。Topic token 使用可复用工程模式命名;espflash 与 probe-rs 作为具体工具名放在定义和证据里。 这个 Topic 关注的是“硬件操作入口可复现且可审计”。

  • 硬件
  • 工具

目录

Definition

MCU flashing integration 表示项目通过 espflash 管理 ESP32 系列,通过 probe-rs 管理 STM32/其他 probe-supported MCU,并把这些 backend 接入项目配置或明确的本地操作入口。Topic token 使用可复用工程模式命名;espflash 与 probe-rs 作为具体工具名放在定义和证据里。

这个 Topic 关注的是“硬件操作入口可复现且可审计”。它不只是记录某个 README 命令,而是要求项目把 MCU target、chip、artifact、probe/serial selector、reset/monitor 策略和后端差异写成可维护配置或 operation record,减少 Agent 在真实硬件上猜命令的风险(projects/loadlynx.md、projects/pd-sink-stm32g431cbu6-rs.md)。

When to use

当项目 snapshot 中该模式影响运行、交付、硬件操作或跨仓库复用时使用;如果只是一次性脚本或历史残留,先保留在项目笔记里,不急着提升为 Topic。

当项目需要自动 flash、monitor、reset、串口日志、probe-rs attach、ESP32 bootloader 或多 target 切换时使用。若仓库只有 firmware 代码但没有可复用 flashing 入口,应先在项目快照中记录证据缺口,而不是声称已经完成集成(projects/flux-purr.md、projects/pd-sink-stm32g431cbu6-rs.md)。

Habits / defaults

  • 每个 MCU target 明确 backend、chip、artifact_elf 和 backend-specific 参数。
  • ESP32 target 默认记录 log format、baud、reset 策略;STM32 target 默认记录 SWD、speed、connect-under-reset。
  • 真实硬件操作前要确认 selector cache 和串口/probe 归属,避免多 Agent 争用。
  • 把 flashing 入口和设备项目配置绑定,让 Agent 能从项目资料定位 target,而不是要求用户重新解释板子、端口和 artifact(projects/loadlynx.md、projects/pd-sink-stm32g431cbu6-rs.md)。
  • 对双 MCU 或多板项目,默认把每个 target 的职责写清楚。ESP32-S3 UI/联网侧与 STM32G431 电源/模拟侧不能共享一套模糊命令(projects/loadlynx.md)。
  • 默认在操作前复核 artifact 是否来自当前源码和目标芯片;旧 ELF、错误 profile 或跨 target 复用 build 目录都会让 flash 看似成功但设备行为错误(projects/loadlynx.md)。

Reference implementations

  • projects/loadlynx.md:ESP32-S3 digital + STM32G431 analog 双 target,适合验证每个 target 的 backend、chip、artifact 和 selector 是否独立可追溯。
  • projects/flux-purr.md:ESP32-S3 frontpanel target,适合说明 firmware build、flash/monitor 记录和 host preview 不能共享模糊的验证结论。
  • projects/pd-sink-stm32g431cbu6-rs.md:STM32G431 USB PD sink/PowerVista firmware,适合验证 probe-rs、artifact 和板级风险如何进入项目记忆。
  • projects/mains-aegis.md:设备项目中 firmware、Web UI 与 docs 共存,适合说明 flashing integration 只是硬件操作链路的一环,不能替代产品行为验证。

Failure modes

  • 把 flashing 命令散落在 README 或 shell history,后续 Agent 会误操作。
  • chip id 写错可能导致连接失败或刷错目标。
  • 日志/monitor 生命周期没有统一管理,会让硬件调试难以复盘。
  • 多 Agent 同时操作同一串口或 probe 会造成不可预测失败;执行前必须确认资源归属,并在项目配置或操作记录中保留 selector 证据(projects/loadlynx.md)。
  • 把 CI build 通过误认为 flash 成功,会污染硬件项目状态。项目快照应区分 compile proof、flash proof 和真实设备行为 proof(projects/loadlynx.md、projects/flux-purr.md)。

Evidence index

  • projects/loadlynx.md
  • projects/flux-purr.md
  • projects/pd-sink-stm32g431cbu6-rs.md