车载无线充电这两年是真的卷，尤其是一提到 Qi V1.3 认证，很多团队的第一反应就是“又要加安全芯片了”。我去年跟的一个前装车载无线充电项目，就是在送检 WPC 前被卡了一轮，原因倒不是功率、效率或者异物检测，而是 EPP（扩展功率协议）输出不满足 Qi V1.3 的数字认证要求。后来换了 STSAFE-V110 这颗安全芯片重新做方案，才把 15W 的认证闭环走通。今天就把这个方案拆开聊一聊，从为什么绕不开这颗芯片，到硬件怎么接、软件流程怎么跑、产线怎么烧录、送测时最容易踩哪些坑，一次性说透。这篇文章主要面向正在做车载发射端（Power Transmitter）的硬件工程师、嵌入式软件工程师和项目经理，如果你是做接收端方案的，里面有一节也会讲到角色的切换逻辑。
1. 一场被忽略的认证升级：Qi V1.3 到底改变了什么
1.1 从 BPP 到 EPP：功率档位背后的强制关卡
先说一个基础但很多人没真正理解透彻的点。Qi 规范分两个功率档位：BPP 是基础功率档，也就是 5W；EPP 是扩展功率档，常见的是 7.5W、10W 和 15W。在 Qi V1.2.4 时代，EPP 充电并不强制做数字认证，很多方案靠模拟握手或者简单的脉冲编码就能把功率抬上去。但 V1.3 发布之后，WPC（无线充电联盟）把规则改了：凡是支持 EPP 的发射端和接收端，都必须完成一次基于椭圆曲线密码学的数字认证，认证通过之后才允许从 BPP 切换到 EPP。换句话说，15W 不再是你功率拓扑能做多高的问题，而是你“有没有资格”输出那么高功率的问题。
对车载场景来说，这个变化特别致命。因为车里用户对充电功率的期望值从一开始就不会是 5W，很多车型的卖点就是“无线快充 15W”，如果认证不过，手机端会默认把功率限制在 5W，用户充满一台大屏手机可能要三个小时。更麻烦的是，整车厂的前装项目周期很长，送检 WPC 认证只是其中一环，一旦方案不满足 V1.3，整个项目节点全部后移，损失的不只是时间。
1.2 为什么必须是“数字认证”而不能靠模拟握手
有同事问过我：以前用手写板识别一下充电协议就能开始快充，为什么 V1.3 非要用一整套 PKI 公钥体系？原因很简单：协议识别是“约定”，数字认证是“证明”。
过去那种握手方式，本质上是双方核对几个电压波形或者带上拉电阻的编码，攻击者完全可以做一个伪造的接收端，告诉发射端“我是合法 15W 设备”，让发射端把功率拉满，然后引发过热甚至火灾。WPC 在 V1.3 里引入的认证机制，是让接收端出示一份由 WPC 根证书签发的数字证书，发射端用内置的根公钥验证这条证书链是否合法，并且还要通过一次随机数质询响应来证明“我确实持有证书对应的私钥”。这里面涉及椭圆曲线签名验证、证书链校验、随机数生成、防侧信道攻击等一系列密码学操作，普通 MCU 的软件方案很难达到合规要求，而且私钥如果放在普通 Flash 里，几乎等于把保险柜钥匙挂在门口。
所以 STSAFE-V110 这种安全芯片的角色，不是“多一颗料”，而是承担整套可信根存储和密码学运算的保险柜。它内部有硬件真随机数发生器，有经过 CC EAL5+ 评估的安全防护，有专门为 Qi V1.3 设计的指令集和流程支持，可以在发射端完成证书验证，也可以在接收端完成签名响应。
2. STSAFE-V110 在方案中的角色与选型思路
2.1 安全芯片不是“多一颗料”，而是“账户体系”的保险柜
在设计车载无线充电器方案时，首先要明确 STSAFE-V110 在你的系统里到底扮演哪个角色。这里有一个容易混淆的地方：Qi V1.3 的数字认证是双向的，发射端要验证接收端的合法性，接收端也要确认发射端有没有被授权输出高功率。
对于车载无线充电器来说，它是发射端，要做的事情是：接收端设备（比如手机）发来一条“我想进入 15W 充电模式”的请求，同时会把自己的数字证书链发过来。发射端收到后，要验证这条证书链是否由 WPC 根证书逐级签发、有没有过期、签名是否正确，然后在本地生成一个随机数叫作“质询”（Challenge），把这个质询发回给手机，手机用自己安全元件里的私钥对这个随机数做签名，再返回给发射端。发射端用手机证书里的公钥验证这个签名，如果验证通过，才确认“这个手机确实是一台合法接收端，可以升到 15W”。
在这个流程里，STSAFE-V110 放在发射端板子上，充当的角色是“验签者”。WPC 根证书的公钥会被安全地存储在 STSAFE-V110 内部，MCU 只负责把 I2C 读上来的证书数据、签名数据转发给安全芯片处理。安全芯片会返回验证结果，MCU 再根据结果决定是否开启 EPP 功率输出。
2.2 STSAFE-V110 与普通 EEPROM/MCU 方案的本质差异
市面上有一些方案，想省掉独立安全芯片，用一颗带加密引擎的高端 MCU 来做验签。从纯技术角度看不是完全不行，但你要面对三个绕不开的问题。
第一是密钥存储问题。WPC 根公钥虽然说是“公钥”，但它在某种程度上属于整套认证体系的信任锚，如果可以被随意改写，整个验证链条就可以被伪造。普通 MCU 的 Flash 很容易被调试接口或者 Bootloader 漏洞读取，就算做了读保护，侧信道攻击和故障注入的防御能力也远不如专用安全芯片。WPC 认证实验室在审核时，对密钥存储方式的审查很严格，不是你说“我有读保护”就认可的。
第二是合规性问题。Qi V1.3 认证中，发射端必须展示自己具备防伪造的能力，说白了就是你的方案要能扛住一定程度的逻辑攻击和物理攻击。专用安全芯片本身拿到了 CC EAL5+ 这样的通用标准评估证书，直接作为你的“证据”使用，审核方会认可。而 MCU 软件方案，你在认证报告里写清楚防护机制，往往要额外补充很多材料，并且要证明你真做了防侧信道设计。这会增加认证周期和不确定性。
第三是开发成本。使用 STSAFE-V110 时，ST 官方提供了针对 Qi V1.3 的中间件库和示例代码，I2C 命令封装、证书解析、签名验证这些底层工作都已经做好了，你只需要理解调用流程，再适配到自己的平台。反过来，软件实现 ECDSA P-256、证书链解析、随机数生成、时间戳校验，工作量不小，而且容易被测试机构抓出漏洞。
2.3 发射端方案 vs 接收端方案：先确认你站在哪一侧
我在项目早期犯过一个定位错误：一开始团队以为 STSAFE-V110 是给手机里的接收端用的，结果把方案讨论方向都带偏了。后来才理清楚：STSAFE-V110 是一颗通用 Qi 认证安全元件，既能用在发射端做验签，也能用在接收端做被验签。如果你们公司同时做发射端成品和接收端模组，选型都可以用同一颗料，只是配置的密钥和加载的固件逻辑不同。
发射端方案中，STSAFE-V110 主要执行证书链验证和签名验证，它需要预置的是 WPC 的 Root CA 公钥，以及你自己产品证书的签发链信息。接收端方案中，STSAFE-V110 需要存储 WPC 为你签发的产品私钥，内部生成密钥对的私钥永远不导出，只对外提供签名结果。这个区别必须在项目立项时确认清楚，因为两种模式下你向 ST/WPC 申请的证书类型、生产时的烧录数据、内部命令调用顺序都不一样。如果选型文档写错，后面流片回来就是废片。
3. 车载环境下的硬件集成要点
3.1 最小系统与接口电路设计
STSAFE-V110 的正常工作接口就是 I2C，外加供电、复位、时钟。先说 I2C，安全芯片在系统里通常作为从机，挂在 MCU 的 I2C 总线上。由于车载板子上 I2C 设备往往不止一个，可能还有温度传感器、电量计、屏幕驱动，所以要注意地址配置是否有冲突。
实际设计中我比较推荐把 STSAFE-V110 单独挂在一条 I2C 总线上，或者至少加一颗 I2C 多路复用器隔离。原因是安全芯片的通信时序要求相对严格，如果总线上有其他设备频繁占用，你很难排查偶发的通信超时。曾经遇到过一个问题：无线充电主控和 NFC 芯片共用一条 I2C 总线，NFC 芯片在某些时候会把总线拉死，直接导致 STSAFE-V110 无响应，结果 15W 输出被手机拒绝。后来把安全芯片单独挪到第二路 I2C 上，问题就消失了。
硬件电路还有其他细节：I2C 上拉电阻要按总线负载算，一般 4.7kΩ 起步，如果走线太长或者挂载设备多，可以降到 2.2kΩ 试一下，但不要盲目减小，否则上升沿变陡，反射和振铃可能带来额外干扰。供电引脚旁边要放 100nF 和 1μF 的退耦电容，而且电容要尽量靠近芯片引脚，不要因为 PCB 空间紧张就随意摆放，这在车载振动和温度变化的环境下容易出问题。
3.2 车载电源域和时钟设计
车载环境下，电源来自车载电池经过 DCDC 转换后的系统电源。如果 DCDC 输出纹波大，或者瞬间跌落，安全芯片可能发生异常复位。复位后 STSAFE-V110 内部状态可能需要重新初始化，如果在无线充电的功率输出阶段发生这种情况，认证状态会被清掉，手机端会中止 EPP 输出。因此建议在 STSAFE-V110 的供电入口加一个 LDO 或至少加一个 TVS 管加电容组合，确保电源质量。
这里必须强调一个容易被忽略的点：STSAFE-V110 需要外部时钟输入。有些安全芯片内部自带振荡器，但这颗芯片不是，MCU 必须提供一个特定频率的时钟源给它。我当时第一次画板子时看的参考设计不够仔细，晚上调试怎么都读不到芯片，第二天对着原理图查才发现时钟引脚悬空了。所以硬件设计阶段，一定要在原理图上用标注清楚地写上“CLK 来源：主控 MCO 输出或独立有源晶振”，给 layout 的同学看，否则这种人肉检查很容易漏。
时钟的精度也直接影响认证稳定性。如果时钟偏差太大，安全芯片在执行密码学运算时可能出现偶发性失败。建议在量产设计里优先使用独立晶振或者从 MCU 的高精度 PLL 输出引时钟，而不是从普通 GPIO 直接引脚翻转。
3.3 温度、振动与 EMC 的功课
车载前装产品要过的高温、低温、振动、EMC 测试，对安全芯片的影响不像功率器件那么直接，但也不是完全能忽略。STSAFE-V110 的常规工作温度一般在 -40℃ 到 105℃，选择车规型号时还要确认它是否做了 AEC-Q100 认证。如果你的项目是后装车载支架，可能要求相对宽松；但如果是前装车厂定点，物料清单里每一颗半导体器件都必须提供车规一致性声明，到时候拿着消费级型号去交差，采购和项目组都会很难看。
EMC 方面，无线充电器本身就是一个大辐射源，逆变桥的开关噪声、线圈耦合的共模干扰都有可能干扰板上的 I2C 通信。建议在安全芯片附近加一颗 100Ω 的磁珠串联到电源，或者预留一个 RC 滤波器位。PCB 布局上，STSAFE-V110 尽量远离线圈和功率桥的驱动电路，至少保持 10mm 以上的间距，并且下方不要走功率回路地。还有一个经验是，I2C 的 SCL/SDA 走线最好相邻并包地，两侧打地孔，防止线圈产生的高频磁场在走线上感应出差模噪声。
4. 认证流程与软件实现拆解
4.1 一次完整的 Qi V1.3 认证握手过程
软件层面要做的第一件事，是理解整个认证握手过程。我们拿发射端来举例。
第一步，接收端（手机）靠近线圈，建立基础通信，双方通过 Qi 协议完成 ping、配置等流程。此时系统处于 BPP 状态，功率输出只有 5W。
第二步，手机端如果想进入 EPP，需要一个“身份证明”的交换过程。手机把它的证书链通过 Qi 消息发送给发射端。这个证书链通常是三段，包括产品证书、中间 CA 证书和根证书，其中根证书可以不传，因为发射端本地已经有 WPC 的 Root 公钥。
第三步，发射端 MCU 把这些证书数据打包，通过 I2C 发给 STSAFE-V110。安全芯片解析证书链，用内部存储的 WPC Root 公钥去依次验证每级证书的签名，确认证书链完整、可信、没有过期。
第四步，验证通过后，STSAFE-V110 会产生一个随机数作为 Challenge（质询），MCU 把这个 Challenge 通过 Qi 消息发给手机端。
第五步，手机端用自己安全芯片里的私钥对这个 Challenge 做签名，把签名结果返回给发射端。
第六步，发射端把签名数据再次转发给 STSAFE-V110，安全芯片从手机证书中提取公钥，验证这个签名是否匹配。匹配成功，STSAFE-V110 返回一个“认证成功”的状态。
第七步，MCU 收到认证成功状态后，切换控制器进入 EPP 功率传输配置，把目标功率升到 15W，同时继续监控 FOD（异物检测）和其他保护逻辑。
这里每一步之间都有严格的超时控制和状态机要求。比如手机发出 Certificate Chain 之后，如果发射端超过规定时间没有响应，手机会判定发射端不支持认证，拒绝进入 EPP。反之，如果发射端发出 Challenge 后手机没有响应，发射端也要主动回落到 5W，不能强行拉高功率。
4.2 MCU 侧软件集成步骤
软件集成方面，如果你用的是 ST 官方评估板，直接启用配套中间件会省不少事。中间件通常已经封装好了 I2C 读写、证书链解析、Challenge 生成、签名验证等 API，你只需要在应用层把 Qi 协议消息和数据帧映射到这些 API 上。
移植到自己的 MCU 平台时，我建议分四步走。先做“寄存器级通信验证”：用最简单的 I2C 读操作，确认 MCU 能访问 STSAFE-V110，这一步排除硬件问题。接着做“命令级验证”：调用中间件里的初始化命令，比如读取芯片 ID、检查配置区状态，确认安全芯片已经正常启动并能返回正确序列号。第三步是“证书链验证测试”：把开发阶段从 ST 申请的一套测试证书数据放在本地，模拟手机端发数据，走一遍完整的证书链校验和 Challenge 响应，确认整个密码学流程闭环。最后才是“协议联调”：把上述测试嵌入到你的 Qi 协议栈里，用一个支持 Qi V1.3 的接收端设备（比如经过认证的工程手机）做真机测试。
在实际开发中，最容易出错的是数据帧格式的组装。Qi V1.3 的数字认证消息不是随便把证书拼在一起发过去就行，它有自己的帧头、长度、报文类型、数据段和 CRC 校验。很多团队在真机联调时发现验证总失败，最后排查出来是 CRC 算法算错或者长度字段包括了不该包括的字节。建议你把协议解析模块单独写一个单元测试，用 WPC 官方的测试向量反复验证，不要直接上真机调。
4.3 生产环节的证书注入与密钥管理
这是一个很多团队前期忽视、后期被抓得很惨的环节。Qi V1.3 数字认证的生命力在于私钥保密，你的生产设备里如果直接烧录一份“万能私钥”，那和没做安全设计没有区别。正确的做法是：每台设备的密钥和证书都应该唯一化，至少要做到批次唯一或设备唯一。
WPC 为每一家会员企业签发证书时，会提供一套证书链和密钥材料。STSAFE-V110 支持在安全芯片内部生成密钥对，并且私钥永不出芯片。所以产线过程应该是：在生产工的电脑上，用 ST 提供的工具生成本批次硬件设备的 CSR（证书签名请求），提交到 WPC 的证书签发系统，下载对应的产品证书。然后在产线上通过烧录器把 Root CA 公钥、产品证书、中间 CA 证书注入到 STSAFE-V110 里。注意不能把私钥文件直接拷贝到产线电脑上，因为那会留下巨大的泄露面；正确的流程是让芯片自己生成私钥，CSR 也由芯片内部生成，电脑只负责传递 CSR 和下载证书。
产线上还要做“认证自检”环节。每一台设备在烧录完成后，要用上位机模拟接收端，跟 STSAFE-V110 完成一次完整的认证握手，确认返回的认证结果是成功。这一步不能省。我见过一个项目，生产测试漏掉了这个自检，结果到了一千台货发出去之后，客户陆续反馈手机只能 5W 充电，最后发现是某一批芯片在 SMT 回流焊时引脚虚焊，I2C 通信不稳定但 PCB 静态测试又测不出来。如果每台设备都跑一遍认证自检，这个问题在出厂前就能暴露。
5. 认证测试与常见问题排查实录
5.1 WPC 认证测试中容易挂掉的项目
Qi V1.3 认证测试比 1.2.4 多了“数字认证”这一大板块，而且这部分牵涉到安全机制，测试人员的手法会比较激进。常见挂掉的项目有这么几类。
第一类是证书链验证失败。不是因为你的芯片算错了，而是你在送测样机里烧录的 Root 公钥和 WPC 测试台架的根证书不匹配。这种情况很尴尬，但真的会发生。我们在开发早期用的是 ST 测试证书，到正式送测前必须把 WPC 正式证书和对应 Root 公钥烧录进去，如果换证书的时候没有同步更新芯片里的 Root 公钥，验证就是失败的。
第二类是 Challenge 响应逻辑紊乱。发送端每收到一个证书链，都应该生成一个新的随机 Challenge。如果实现时不小心复用了上一次的随机数，测试仪器可能会认为加密随机性不足，判定不通过。所以随机数必须每次重新从安全芯片获取，不能缓存。
第三类是超时处理不严谨。握手过程中，即使认证失败，设备也必须在一个规定时间内安全回落到 5W 或终止充电。有些设计在这个环节逻辑上直接卡死，或者需要重新上电才能恢复，测试人员会在这种场景下判定产品不合格。软件设计上一定要做好异常分支，认证失败、通信超时、证书过期都要有明确的回退处理。
5.2 现场排查遇到的六个高频问题
我把实际项目中遇到过的问题整理一下，方便大家对照排查。
第一个问题是“I2C 扫描不到 STSAFE-V110”。先量电源电压和电流，确认芯片有没有供电；再量 CLK 引脚有没有时钟信号。如果两者都正常，再用 I2C 扫描工具看地址是否正确，有些型号支持配置地址，如果地址读保护导致默认地址变化，需要先在安全芯片的配置状态下恢复。
第二个问题是“能读到芯片但初始化失败”。大概率是时钟精度不够或者供电毛刺导致芯片状态机没有正常进入 Ready 状态。先把芯片的复位时序拉长一点，上电后等待 50ms 再发命令；不行就把 LDO 换成低噪声型号。
第三个问题是“证书链校验失败”。检查你发给安全芯片的证书顺序是不是对，证书链必须是“产品证书 -> 中间 CA -> 根”，顺序不能乱，也不能自己加额外的字节。另外确认根证书公钥是不是最新版本，WPC 可能会做根证书轮换，老产品如果用的旧根钥，需要软件支持升级。
第四个问题是“手机能识别到无线充，但总是只有 5W”。这种情况优先看认证有没有成功。你可以在协议日志里抓认证消息，看停留在哪一步。最常见的是手机把证书链发过来后，发射端没有及时响应 Challenge。检查 MCU 的任务优先级，是不是在发送 Challenge 的瞬间被其他中断抢占，导致超时。
第五个问题是“功率升到 15W 后偶尔掉回 5W”。这个不一定是认证问题，很可能是 FOD 或者温度保护误触发。但车载场景里有个特殊情况：如果板子布线时把安全芯片 I2C 总线放在了线圈正下方，认证状态在某些功率点会被磁场干扰，偶发性掉认证。把总线挪走或者加屏蔽，问题通常能解决。
第六个问题是“产线上十台设备里有那么一两台认证自检不过”。这种偶发性问题很可能是烧录时序造成的。检查烧录工位的 USB 转 I2C 工具稳定性、供电电压、线缆长度。还有一个大家容易忽略的因素是静电，产线工人如果在干燥季节没有佩戴防静电手环，很容易在插拔治具时造成芯片内部状态错乱。加装离子风机，规范操作流程，不良率会明显下降。
5.3 经验心得：不要在这三处省时间
最后说点项目推进上的经验。第一，不要在 SMT 贴片前才开始准备 WPC 正式证书。证书申请涉及商务流程和审核周期，往往需要几周时间，一定要跟芯片选型同步启动。第二，不要在开发阶段混用测试证书和正式证书。测试证书有效期内可以反复使用，但一旦开始正式认证准备，整个产线测试、开发工程机、送测样机都要切换到正式证书链路，否则容易出现“开发环境一切正常，送测就失败”的情况。第三，软硬件团队要约定好日志接口。认证失败时，没有日志基本等于盲猜，我们的做法是通过 UART 把每次认证握手的关键数据和结果码打到一个外接日志工具上，这样既能快速定位是证书问题、随机数问题还是通信问题，也方便和 ST 的 FAE 远程协作时直接把日志发过去。
我个人在实际项目里最深的体会是：STSAFE-V110 本身只是一个安全芯片，它解决的是“信任根”的问题，但真正决定 Qi V1.3 认证能不能顺利通过的，是你对整个认证流程有没有敬畏心。电源、时钟、I2C 时序、证书链顺序、密钥管理、产线自检，每一环都按流程做扎实，后面自然会顺。最后分享一个建议：量产阶段把“认证自检”做成每次开机时的必检项，一旦发现安全芯片通信异常就点亮故障灯，这能帮你提前拦截大量售后问题，比后知后觉强得多。
