复杂脚本工具：打造产品专用 Bootloader 刷写工具

BMCLI 的基础命令既可以单独使用，也可以组合成处理完整业务流程的复杂脚本工具。本篇以产品专用 Bootloader 刷写工具为例，看看 AI 如何将项目规范转化为可供 CI/CD、台架和现场复用的程序。

设想团队要把“构建固件—刷入 ECU—启动回归—归档结果”接入 CI/CD。项目已有 Bootloader 规范和获准使用的安全算法，但还没有统一的刷写入口。无论采用现有刷写软件还是自建程序，目标地址、会话、解锁与校验流程都需要适配；这些项目规则正适合交给 AI 整理成脚本。

工具首先提供命令行入口，不依赖界面即可运行：接收固件、目标和配置，输出阶段记录、结果文件与退出码。CI/CD 调用它，工程师也能在台架上手动调用；日后添加界面时，界面仍调用同一套流程。BMCLI 负责 UDS 事务与镜像传输，AI 生成的脚本负责把它们组织成完整、可维护的业务过程。

准备隔离刷写台架、稳定供电、匹配的 ECU 与固件、刷写规范和算法库后，就具备了项目输入。随文先用小型镜像和模拟器展示下载环节，再介绍怎样按项目规范组织完整刷写流程。

一个刷写入口，连接 CI/CD 与台架

图 4-1　脚本编排项目流程，BMCLI 执行 UDS 事务。工程关系示意。

给 AI 的输入：描述项目流程

输入包括项目刷写规范、流程配置、固件、算法库，以及 CI/CD 需要的参数和结果约定。本次要交付的是脚本工具；首次接入先做检查，验证过的目标与流程再交由流水线按固定配置运行。

我们的新项目需要把 ECU 刷写接入 CI/CD，请使用 BMCLI 生成一个无界面、可由外部进程调用的 Bootloader 刷写脚本工具。我已提供刷写规范、flash-plan.yaml、匹配固件与获准使用的算法库，目标连接取自项目 Bench。入口接收固件路径、目标配置和报告目录，先检查镜像与设备身份，再按规范组织会话、解锁、擦除、下载、校验、复位和版本读取。每个阶段记录结构化结果，全部通过时返回成功退出码；失败时返回非零退出码，保存失败阶段和 ECU 响应，并完成本次任务的收尾。请先离线检查并列出缺项，在我确认的隔离台架上验证完整流程；之后将已验证配置用于无人值守执行。交付脚本、配置、调用说明与报告样例。本次不制作图形界面，便于 CI/CD、台架程序和后续界面复用同一个入口。

AI 会将项目说明整理成流程程序，调用 BMCLI 完成各项动作。随文计划展示了组织方式，固件、算法库和项目例程参数则由实际项目提供。

脚本输出按当前阶段、阶段进度和整次结果分层。CI/CD 根据退出码决定是否继续回归，工程师则通过阶段记录定位失败原因。

成品与效果：流水线拿到明确的刷写结果

期望交付的是一个可独立调用的刷写入口。流水线传入本次固件与目标配置，得到阶段记录、刷后身份信息和退出码，再决定是否启动测试。以下镜像检查与模拟器输出展示其中的传输部分，AI 可据此结合 ECU 规范生成项目刷写脚本。

即使暂时没有 ECU，也可以先体验镜像检查。在本篇示例目录中，附带一个只有 4 字节的教学 HEX。离线检查结果如下：

检查项	结果
镜像格式	Intel HEX
数据段	1 段
地址范围	0x00000000～0x00000003
有效数据	4 字节
计划请求	RequestDownload → TransferData → TransferExit
估算传输块数	1 块，连接后按 ECU 协商值确定

这份结果回答的是“文件里装了什么、准备怎样传输”。--dry-run 不发送总线请求，适合在接入 ECU 前检查镜像。

连接自有模拟 ECU 的下载案例还展示了几种典型结果：

模拟器响应	工具呈现
接受请求和数据	完成 4 字节传输及 TransferExit
responsePending，随后正常响应	继续等待并取得最终结果
返回错误块序号	定位到 transfer_data，并保留预期与实际序号
RequestDownload 返回 NRC 0x31	定位到 request_download，显示否定响应

镜像很小，但下载工具最重要的能力已经能看出来：完成传输，以及解释传输为何没有完成。

实现解析：BMCLI 在成品中承担的工作

下面结合关键调用说明应用的实现方式。AI 生成的程序将这些调用组织成完整流程，并处理返回结果与任务收尾。

BMCLI 承担哪些工作

镜像预览由应用调用离线下载检查，读取镜像段与传输计划，不发送总线请求：

# 离线解析镜像并生成传输计划，不向 ECU 发送下载请求。
bmcli uds download --file=firmware/demo.hex --dry-run --format=json

随文 demo.hex 的预览应为 1 段、共 4 字节、起始地址 0x00000000，并列出 0x34/0x36/0x37 下载序列及 ALF 0x44。这个离线步骤用于核对镜像段地址、长度和预估块数，为随后连接目标执行下载做好准备。

下面用一组项目参数说明命令怎样衔接。地址、解锁级别、例程数据和 BIN 大小均为配置示例：

# 设置本次刷写的逻辑通道、诊断地址及填充方式。
bmcli uds config set --channel=programming-can `
  --request-id=0x7E0 --response-id=0x7E8 `
  --flags=classic --padding=0xAA

# 请求进入编程会话，并采用 ECU 返回的会话时序。
bmcli uds session change programming --format=json
# 启动后台 TesterPresent，按项目允许的抑制响应方式维持会话。
bmcli uds present start --interval=2000 --suppress-positive-response
# 调用项目提供的算法库完成指定安全级别的解锁。
bmcli uds unlock --level=0x11 --algo=security/project-seed-key.dll
# 按项目约定调用擦除例程；例程 ID 和数据均来自刷写配置。
bmcli uds routine start 0xFF00 --data=0040000000002400 --format=json
# 传输镜像数据并处理块序号、等待和传输退出；完整刷写还需后续校验。
bmcli uds download --file=firmware/demo-app.bin `
  --addr=0x00400000 --size=9216 --format=json

session change 解析 ECU 返回的会话时序，后台 TesterPresent 维持会话，unlock 调用项目算法库。download 则处理镜像、协商块长、块序号和传输退出，AI 生成的脚本可以把主要篇幅留给阶段衔接、条件判断、失败处理与结果输出。

项目刷写流程在下载传输之后，继续完成规定的校验、复位和版本确认。工具逐项记录各阶段结果，形成完整刷写报告。

在项目台架上使用

首次接入时，将 ECU 身份、镜像地址、供电条件和恢复方法整理为配置检查结果。验证通过后，CI/CD 使用固定的目标与流程参数运行；环境或型号不匹配时，脚本在刷写前退出并给出原因。这样，无人值守执行依赖的是已确认的工程配置。

发生超时后，先查询设备状态和最后确认的阶段，再决定重试方式；退出时停止本工具创建的 TesterPresent 等任务。将这些处理统一放进程序，日常使用就能少一些手工收尾。

进一步探索：从刷写流程到交付工具

这个案例还可以继续完善，也可以延伸到更多工作中。您可以从感兴趣的一项出发，与 AI 讨论下一步的实现。

让一个工具适配多个产品型号

如果同一产品线有不同的 ECU 或存储布局，可以请 AI 将地址、镜像区域、诊断连接和刷写步骤整理成按型号选择的配置。工具先通过项目规定的身份读取确认设备，再显示匹配的固件与流程；BMCLI 继续承担诊断和传输，应用只负责选择与组织。每个型号先通过镜像检查和对应台架验证，再加入脚本支持的目标配置清单。这样可以复用同一套工具，又让型号差异保持清楚可查。

为小批量升级增加逐台履历

如果现场需要连续升级一批样机，可以追加扫码、设备身份与刷写记录的关联功能。AI 可复用已经验证的单台流程，在每台完成后保存固件标识、结果和操作时间，再生成批次摘要。BMCLI 仍处理当前设备的 UDS 事务，应用管理每台产品的履历与失败项。这样既方便逐台追查，也不会把单台成功误认为整批设备已经完成。

参考阅读

以下文档介绍本篇涉及的接口；具体参数可通过本机 JSON Help 查询。

下载本篇配套示例 ZIP