嵌入式系统固件更新：基于I2C的TPS6598x PD控制器安全升级方案

1. 项目概述

在硬件开发，尤其是涉及USB Type-C和Power Delivery（PD）的系统中，固件更新能力是产品生命力的核心。想象一下，你的产品已经出货到全球用户手中，这时USB-IF发布了新的PD协议规范，或者发现了与某款热门手机充电兼容性的问题。如果不能远程或在用户无感的情况下更新固件，就意味着需要召回硬件或承受用户投诉，这对任何产品都是灾难性的。我经历过不止一次因为早期固件问题导致的现场维护成本飙升，所以对一套可靠、可嵌入的固件更新机制有着近乎偏执的追求。

TPS6598x系列芯片作为独立的USB Type-C和PD控制器，广泛应用于笔记本电脑、扩展坞和充电器中。它的应用代码存储在外部SPI Flash中，上电时加载到内部RAM运行。这就带来了一个关键需求：如何在不拆机、不借助专用编程器的情况下，由系统内的另一个“大脑”——嵌入式控制器（EC）——来更新它的固件？答案就是利用I2C总线。I2C协议简单，只需要两根线（SDA和SCL），几乎所有的微控制器都原生支持，是主从设备间通信的绝佳选择。本项目要解决的，就是如何让EC扮演I2C主设备，通过一系列精心设计的命令序列，指挥TPS6598x（作为I2C从设备）去擦写它自己管理的SPI Flash，最终完成固件升级。这不仅仅是发送几个字节那么简单，它涉及到对Flash存储结构的理解、命令时序的严格把控、更新过程的容错设计，以及如何确保万无一失，避免把设备变成“砖头”。接下来，我将结合TI的应用笔记SLVA783A和多年的实操经验，为你拆解这个过程的每一个技术细节和避坑指南。

2. 核心原理与架构设计

2.1 TPS6598x固件存储与启动机制

要理解如何更新，必须先明白固件放在哪里以及如何运行。TPS6598x内部是一个RAM-Based的处理器，这意味着它本身没有非易失性存储器来存放程序。它的“操作系统”存放在一颗外挂的SPI Flash芯片里。芯片上电或复位后，会执行一段固化在ROM中的引导程序（Bootloader），这段程序负责从SPI Flash的指定位置读取应用程序代码，并将其加载到内部RAM中，然后跳转到RAM中执行。

这种架构的优势是灵活，可以通过更换SPI Flash中的内容来彻底改变芯片行为。而我们要做的更新，本质上就是替换这颗SPI Flash芯片里的内容。关键在于，TPS6598x在设计上允许自己作为SPI Master去操作这片Flash，而我们（EC）则通过I2C命令来“遥控”它完成这个操作。

2.2 SPI Flash的存储结构：冗余与安全

为了防止固件损坏导致设备无法启动，TPS6598x采用了经典的A/B双区备份设计。在SPI Flash中，固件被存储在两个完全独立的区域：Region 0（低区）和Region 1（高区）。这两个区域存储的内容是完全相同的，互为备份。

每个区域又分为两部分：

1. 头部（Header）：大小固定为4KB。它包含了固件的版本信息、CRC校验值、配置数据以及指向实际应用程序代码的指针。
2. 应用程序代码区：存放主要的固件二进制代码，对于TPS65982，最大为64KB。

芯片启动时，引导程序会依次检查两个区域的头部信息（如CRC）。它会尝试从第一个有效的区域启动。如果Region 0校验失败，它会自动 fallback 到Region 1。这种设计确保了即使一次更新过程意外中断（比如断电），另一个完好的备份区域仍然能让设备正常启动，极大地提高了更新过程的安全性。我们通过I2C更新的文件，正是这个包含了头部和代码的完整“低区镜像”（low-region.bin），我们需要将这个镜像文件同时写入Region 0和Region 1。

2.3 I2C命令集：与芯片对话的“语言”

EC与TPS6598x的整个交互建立在I2C寄存器和一套特殊的“4字符命令”（Four-Character Command， 4CC）之上。TPS6598x预留了特定的I2C寄存器地址用于命令和数据交换：

• CMD1/CMD2寄存器（0x08/0x10）：用于发送4CC命令码。
• DATA1/DATA2寄存器（0x09/0x11）：用于传递命令所需的参数或读取命令的返回结果。

核心的固件更新命令都是“FL”开头的ASCII命令：

• FLrr(Flash Read Region)：读取当前激活的固件区域指针。这是更新的第一步，用于确认当前运行的区域和Flash布局。
• FLem(Flash Erase Memory)：擦除Flash。固件更新前，必须将目标区域彻底擦除。擦除操作以“扇区”（Sector）为单位，每个扇区4KB。
• FLad(Flash Address)：设置Flash操作的起始地址。在执行写入或验证前，必须告诉芯片从Flash的哪个地址开始操作。
• FLwd(Flash Write Data)：向Flash写入数据。这是最核心的操作，但一次只能写入64字节。你需要将整个固件镜像（最大68KB+）分成1088个64字节的数据包，逐个发送。
• FLvy(Flash Verify)：验证写入Flash的数据的完整性。发送此命令并指定地址后，芯片会计算该地址后一段数据的CRC，并与头部存储的预期CRC对比，返回验证结果。
• GAID：这是一个特殊的硬件复位命令。发送后，TPS6598x会执行一次硬件复位，重新从SPI Flash加载新的固件并运行。

命令执行流程是严格同步的：1) 将参数写入DATA寄存器；2) 将命令码写入CMD寄存器；3) 轮询读取CMD寄存器，直到其值被清空（变为0x00000000），表示命令执行完毕；4) 从DATA寄存器读取命令执行的结果或状态。任何步骤的时序或数据错误都可能导致更新失败。

2.4 整体更新流程设计

基于以上原理，一个健壮的更新流程设计如下：

1. 前期检查：EC首先读取TPS6598x的版本寄存器（0x0F）和启动标志寄存器（0x2D）。启动标志会告诉我们当前是从Region 0还是Region 1启动的，以及两个区域的健康状态（如CRC是否通过）。这是决定更新策略的基础。
2. 安全准备：在开始更新前，最好通过修改系统配置寄存器（0x28）禁用Type-C端口，防止在更新过程中有设备插拔引发意外状态。
3. 更新非活动区域：根据启动标志，优先更新当前未运行的那个区域。例如，如果当前从Region 0运行且状态良好，则先更新Region 1。这是最重要的安全策略——永远先更新备份区，确保有一个可回退的版本。
4. 验证并切换：更新完非活动区域后，立即使用FLvy命令验证。如果验证通过，则重启芯片（GAID命令），芯片会重新检查两个区域。由于我们刚更新完的区域是新的，芯片很可能会选择从这个新区启动。
5. 更新原活动区域：重启后，再次检查启动标志，确认新固件已成功运行。然后，重复擦除、写入、验证流程，更新原先的那个活动区域（现在它变成了非活动区域）。至此，两个区域都更新为相同的新版本。
6. 最终确认：再次读取版本寄存器，确认运行版本已更新为目标版本。

这个“先备份，再覆盖”的流程，是保证更新过程砖头率降至最低的关键。我曾在早期项目中尝试过直接覆盖活动区域，一次意外的I2C通信干扰就导致了设备变砖，教训深刻。

3. 嵌入式控制器端软件实现详解

3.1 工程文件结构与职责划分

参考TI的示例代码，一个清晰的固件更新模块可以划分为以下几个文件，这在实际项目中非常有助于团队协作和代码维护：

• hostIF82.h：硬件抽象层头文件。它定义了所有与TPS6598x通信相关的常量，包括I2C从设备地址、关键寄存器地址、寄存器长度、4CC命令的宏定义，以及用于解析寄存器位域的结构体（如tBootFlags82，tFWVersion82）。这里的一个关键技巧是使用位域结构体来访问寄存器中的特定标志位，这比手动进行位移和掩码操作更清晰、更不易出错。
• i2cHandlerHostTo82.c/.h：I2C驱动层。它封装了最基础的ReadIICRegister和WriteIICRegister函数，以及一个统一的fourCC_Command函数。这个驱动层应该与具体的EC平台（如STM32， NXP， 还是TI的Tiva-C）的I2C底层驱动对接，实现与TPS6598x的物理通信。将通信协议与业务逻辑分离是本设计的一大优点，更换EC平台时，通常只需要适配这一层的底层驱动函数。
• i2cFwUpdate82.c/.h：固件更新业务逻辑层。这是核心所在，包含了FWUpdate82()主函数和RegionUpdate82()等辅助函数，实现了第2.4节描述的完整更新流程、状态判断和错误处理。
• main.c：应用层。负责系统初始化，然后调用FWUpdate82()函数。在实际产品中，这里可能是由EC的上层任务调度器触发，例如检测到有新的固件文件存在时。

3.2 核心函数拆解：RegionUpdate82(bool rgnNum)

这个函数负责更新单个区域（Region 0或1），是更新过程的骨干。我们来一步步拆解：

第一步：获取并确认区域指针

fourCCerror = fourCC_Command(FLrr, (uint8_t *)&i2cDataFlrrRgn[rgnNum]); readError = ReadIICRegister(I2C1_BASE, DefAddr1, REG_DATA1, 4, i2cReadData); tempData = (i2cReadData[0] | (i2cReadData[1] << 8) | (i2cReadData[2] << 16) | (i2cReadData[3] << 24)); if (tempData == rgnPntrVal[rgnNum]) { // 指针正确，继续 }

首先发送FLrr命令获取指定区域的指针。这个指针值是芯片从Flash头部读出的，指示了该区域代码在Flash中的实际起始地址。我们需要与预期的常量（rgnPntrVal）进行比较，以确认Flash的映像布局符合预期。这是防止错误固件文件的第一道关卡。如果指针不匹配，很可能你准备的是一个错误格式的low-region.bin文件。

第二步：擦除目标区域

i2cDataFLemIn[0] = rgnPntrVal[rgnNum]; i2cDataFLemIn[1] = sectorCount; // TPS65982为17， TPS65982D为3 fourCCerror = fourCC_Command(FLem, (uint8_t *)&i2cDataFLemIn);

FLem命令需要两个参数：起始地址和要擦除的扇区数。对于TPS65982，一个区域是68KB（64KB代码+4KB头），需要擦除17个4KB扇区。这里有一个巨坑：TPS65982D的固件结构不同，其区域大小可能只有12KB（8KB代码+4KB头），因此sectorCount需要改为3。如果按17个扇区去擦除82D，会擦写到其他区域，导致不可预知的错误。务必根据芯片型号正确设置此参数。

第三步：设置写入地址并循环写入

fourCCerror = fourCC_Command(FLad, (uint8_t *)&rgnPntrVal[rgnNum]); for (count32bit = 0; count32bit < 1088; count32bit++) { // 68KB / 64B = 1088次 // 1. 准备64字节数据（从你的固件文件缓冲区读取） // 2. 调用 fourCC_Command(FLwd, dataBuffer); }

设置好起始地址后，进入最耗时的写入循环。每次调用FLwd只能写入64字节。因此，你需要一个循环，从你的low-region.bin文件缓冲区中，每次取出64字节，通过FLwd命令发送。这里必须注意两点：一是每次写入后最好有几十毫秒的延迟，确保芯片有足够时间将数据编程到Flash中；二是务必处理好文件结束（EOF）的情况，最后一次写入可能不足64字节，需要用0xFF或特定值填充。

第四步：验证区域

fourCCerror = fourCC_Command(FLvy, (uint8_t *)&tempData); // tempData为区域指针 readError = ReadIICRegister(I2C1_BASE, DefAddr1, REG_DATA1, 4, i2cReadData); if (i2cReadData[0] == 0x00) { rgnVrfy[rgnNum] = true; // 验证成功 }

写入完成后，立即使用FLvy命令验证。芯片会计算从指定地址开始的数据的CRC，并与头部存储的CRC进行比对。返回值为0x00表示验证成功。验证失败是更新过程中最常见的错误之一，可能原因包括：数据传输过程中出现位错误、Flash物理损坏、或者准备的固件镜像本身CRC就不正确（即文件已损坏）。

3.3 主更新逻辑：FWUpdate82(void)

这个函数是更新的总调度器，体现了更新策略的智慧。

1. 读取当前状态：读取版本号和启动标志（REG_BOOT_FLAGS）。重点关注BootOk、Region0、Region1、Region0CrcFail、Region1CrcFail等位。这些标志位揭示了芯片的“健康史”。
2. 决定更新顺序：
   • 情况A：BootOk=1且Region1=0。这表示芯片从Region 0成功启动，甚至没有尝试Region 1（可能Region 1无效）。此时最安全的方法是先更新Region 1，验证成功后，重启，再更新Region 0。
   • 情况B：BootOk=1，Region0=1且Region1=1，但Region1CrcFail等错误位为0。这表示芯片尝试了双区，最终从Region 1启动。此时应先更新Region 0，验证后重启，再更新Region 1。
   • 情况C：BootOk=0。这表示当前固件启动失败，设备可能处于一种不稳定状态。此时不应尝试更新，而应记录错误并中止流程。强行更新可能雪上加霜。
3. 执行更新与复位：按照决定的顺序调用RegionUpdate82()。一个区域更新验证成功后，发送GAID命令重启芯片。重启后必须等待足够长的时间（建议2-3秒），让芯片完成完整的引导加载过程，然后再去读取新的启动标志和版本号进行确认。
4. 状态返回：函数最终返回一个布尔值，指示整个更新过程是否完全成功。上层应用可以根据这个返回值决定是删除临时固件文件，还是标记更新失败需要进行错误处理。

3.4 关键细节与平台适配要点

• I2C时序与速率：TPS6598x的I2C接口通常支持标准模式（100kHz）和快速模式（400kHz）。在发送大数据量的FLwd命令时，使用快速模式可以显著减少更新时间。但在发送GAID复位命令前，建议切换回标准模式或确保时序兼容性，有些芯片在高速率下对复位命令的响应可能不稳定。
• 数据缓冲区的管理：示例代码中使用initCountUpDwn64函数生成测试数据。在实际项目中，你需要替换为从外部存储器（如EC内部的Flash、SD卡）或通过其他接口（如UART、USB）接收到的真实固件二进制数据流。务必在更新开始前，对整个二进制文件进行完整性校验（如SHA-256），避免传输错误导致写入垃圾数据。
• 错误恢复与超时机制：示例代码中的错误处理相对简单。在生产代码中，必须在每个I2C读写和4CC命令后检查返回值，并加入重试机制。例如，如果FLwd写入失败，可以重试最多3次。对于FLvy验证失败，应记录错误日志并中止流程，而不是继续更新另一个区域。此外，在轮询CMD寄存器等待命令完成时，必须设置超时（例如，循环读取100次后仍未清空则视为超时失败），防止程序死锁。
• TPS65982D的特殊处理：如示例代码注释所示，82D的固件结构、Boot Flags寄存器位定义以及需要擦除的扇区数都与82不同。在编写通用代码时，必须通过芯片ID或编译宏来区分这些差异，否则会导致更新失败或设备���坏。

4. 实操步骤与现场调试记录

4.1 开发环境搭建与前期准备

1. 硬件准备：

   • 一块带有TPS6598x芯片和EC的开发板或产品原型。
   • EC需要有可用的I2C主控制器接口，并与TPS6598x的I2C引脚正确连接（上拉电阻必不��少）。
   • EC需要有调试接口（如JTAG/SWD）和日志输出接口（如UART）。
   • 一个可靠的电源，更新过程中断电是最大的风险。

2. 软件准备：

   • EC的集成开发环境（如IAR Embedded Workbench， Keil MDK， 或基于GCC的IDE）。
   • TPS6598x的最新配置工具和实用工具（TPS6598x Configuration Tool & Utilities Tool）。实用工具至关重要，它可以模拟I2C主设备，让你在编写EC代码前，手动发送命令测试整个更新流程，验证硬件连接和固件镜像的正确性。
   • 目标固件镜像文件（config82_v1.X.X_low_region.bin），通常由配置工具生成。

3. 第一步：手动验证。不要急于写代码。先用I2C调试工具（如Utilities Tool或Bus Pirate）连接EC的I2C总线，手动执行一遍FLrr，FLem，FLad，FLwd（写一小段测试数据），FLvy，GAID命令序列。记录下每个步骤的请求与响应数据。这个步骤能排除80%的硬件连接和基础协议问题。

4.2 代码移植与集成

1. 移植驱动层：将i2cHandlerHostTo82.c中的ReadIICRegister和WriteIICRegister函数，适配到你EC平台的I2C驱动API上。注意处理I2C传输中的NACK（无应答）错误，这是判断从设备是否在线或忙的关键。
2. 实现延时函数：示例代码中的DelayInMilliseconds()需要你实现。确保延时准确，特别是FLwd写入后的延时和GAID复位后的长延时。
3. 集成文件系统：修改RegionUpdate82函数中的数据源。你需要编写一个函数，能从你的存储介质中读取固件文件，并按64字节分块提供给写入循环。强烈建议在内存中开辟一个大小固定的缓冲区（如2KB）进行缓存读取，而不是每次只读64字节，以提高效率。
4. 添加日志系统：将示例中的UARTprintf替换为你项目的日志输出函数。详细的日志是调试的生命线。至少记录：开始更新、每个区域更新开始/结束、验证结果、复位动作、更新后的版本号。

4.3 分阶段测试与调试

注意：首次测试务必使用开发板，并确保你有恢复手段（如通过JTAG擦除Flash并重写）。

1. 阶段一：通信测试。只编译调用ReadIICRegister读取版本号（0x0F）的代码。确保能正确读到芯片ID和当前版本。如果失败，检查I2C地址（0x38或0x3F）、时序、上拉电阻。
2. 阶段二：只读不写。运行完整流程，但在RegionUpdate82函数中，注释掉FLem（擦除）和FLwd（写入）的调用，只执行FLrr和FLvy（验证现有固件）。这可以测试命令序列是否正确，而不会有任何破坏性。
3. 阶段三：更新备份区。准备一个已知良好的新固件。修改代码，使其只更新非活动区域（例如，当前跑在Region 0，就只更新Region 1）。更新后发送GAID重启，观察日志确认芯片是否从新区（Region 1）启动，并且版本号已更新。这是最关键的一步，验证了核心更新功能。
4. 阶段四：完整双区更新。在阶段三成功的基础上，解除注释，让代码完成第二个区域的更新。最终验证两个区域版本一致。
5. 阶段五：异常测试。
   • 断电测试：在FLwd写入循环中途切断电源，然后重新上电。设备应该能从完好的那个旧区域启动。检查启动标志，看是否如预期发生了区域回退。
   • 错误文件测试：故意提供一个CRC错误的固件文件，观察FLvy验证失败是否被正确捕获，并且更新流程被中止。
   • 通信干扰测试：在I2C线上人为制造一些毛刺（需谨慎），测试代码的重试和错误处理机制是否生效。

5. 常见问题排查与实战心得

在实际部署中，你几乎一定会遇到下面这些问题。这里是我的排查清单和解决思路。

我的几点实战心得：

1. 版本管理是前提：EC端代码必须有一个机制来管理它自身支持的TPS6598x固件版本。在尝试更新前，要检查本地存储的固件文件版本是否比当前运行的版本新，并且是兼容的。盲目降级或跨大版本升级有时会引发问题。
2. 日志是你的眼睛：在产品的测试版本中，保留详细的UART日志输出。记录下每一个关键步骤的结果、寄存器值和耗时。当现场出现问题时，这些日志是远程诊断的唯一依据。量产版本可以关闭详细日志以减少字符串存储开销。
3. 设计一个“安全模式”：考虑在EC中实现一个机制，如果连续多次（如3次）更新后启动失败，EC应能回滚到一个绝对已知良好的“安全固件”（可以预先烧录在EC自己的Flash中），并通过一个特定的GPIO状态（如闪烁LED）告知用户。这能有效防止设备因固件问题而永久变砖。
4. 功耗与时序的权衡：在电池供电的设备中，整个更新过程（尤其是擦写68KB数据）可能耗时数秒到十数秒，会增加��耗。需要评估这是否可接受。有时，可以将更新过程分解为多个小任务，在系统空闲时执行，而不是一次性完成。
5. 团队协作的接口定义：i2cFwUpdate82.h中暴露的FWUpdate82()函数，应该定义清晰的输入参数（如固件数据缓冲区指针和长度）和输出状态（成功、失败及失败原因枚举）。这能让负责应用逻辑的同事和负责底层驱动的同事高效协作，而不需要深入理解彼此模块的内部细节。