做过车载无线充电项目的朋友应该都有体会，Qi 标准从 1.2.4 升到 1.3 之后，整个行业最大的变化不是功率、不是频率，而是“认证”这两个字突然变得特别重。如果你正在做 15W 以上的 EPP 发射端，或者打算把自己的产品送进 WPC 认证流程，那一定躲不开 STSAFE-V110 这颗安全芯片。
这篇内容我基于实际项目经验，把车载 Qi V1.3 无线充电器如何用 STSAFE-V110 完成认证方案这件事，从“为什么一定要加”、到“硬件怎么接”、再到“软件怎么调”、“认证怎么过”完整梳理一遍。无论你是硬件工程师、嵌入式软件工程师，还是刚接手无线充电项目的产品经理，这篇文章都值得收藏，里面写的都是文档里不会细讲、但实际开发中一定会踩的坑。
1. 为什么 Qi V1.3 卡在了“认证”这个坎上
1.1 从 Qi 1.2.4 到 1.3，标准到底改了啥
先说一个背景。Qi 1.2.4 及之前的版本，EPP（Extended Power Profile，扩展功率协议）发射端虽然也有一套通信握手流程，但这里面有个巨大的漏洞：接收端（比如手机）告诉充电板“我是某某品牌的手机，我支持 15W”，充电板就真的信了，然后把功率提上去。这个信任模型完全建立在“设备自己报身份”的基础上，没有任何加密手段。
结果就是市场上出现了大量所谓的“兼容 15W”充电器，实际上输出端根本没做协议适配，甚至有的发射端直接不校验身份信息，只要是 Qi 信号就直接上高功率。问题来了：如果充电板给一个只支持 5W 的设备强行灌 15W 的功率，接收端可能过热、电池受损，严重的会有安全隐患。WPC（Wireless Power Consortium，无线充电联盟）显然不能接受这种情况一直持续，因为在他们的认证体系里，安全性是底线。
所以 Qi V1.3 标准做了一个非常硬性的要求：所有支持 EPP 的发射端（也就是能输出 5W 以上的充电器），必须支持身份认证。这个认证不再是简单的“我报名字”，而是基于椭圆曲线密码学的数字签名认证。充电器需要内置一颗安全芯片，里面预置了由 WPC 颁发的证书，然后在与接收端握手时完成双向或者至少单向的签名验证，只有验证通过，才允许提升到高功率档。
这一步改动，表面上看只是加了一个安全芯片，实际上是把整个 Qi 充电的信任链从“软件层”硬拉到了“硬件层”。
1.2 安全芯片在认证链路中扮演的角色
很多第一次接触这个项目的工程师会问：我直接在 MCU 里面做一套认证算法，不也能实现签名验证吗？为什么非要加一颗独立的安全芯片？
这里要理解 WPC 的认证模型：WPC 并不信任你的 MCU，也不信任你的代码。因为 MCU 里面存的私钥是可以被读出来的，代码也是可以被逆向的。哪怕你做了各种混淆，只要私钥在通用处理器里，就存在被提取的风险。而一旦私钥泄露，攻击者就可以伪装成你的产品，通过认证，然后对任何接收端设备输出高功率，这等于把整个安全体系击穿了。
STSAFE-V110 这类安全芯片存在的意义，就是把私钥放在一个内部物理防护的硬件安全单元里，外部任何接口都读不到私钥本体。内部有主动屏蔽层、传感器和加密引擎，物理攻击、侧信道攻击的成本极高。所以 WPC 在认证规则里明确规定：EPP 发射端必须使用经过 CC EAL5+ 或更高等级认证的安全芯片，并且证书私钥必须存储在芯片内部且不可导出。
放到实际链路里，安全芯片的工作方式大概是这样的：Qi 通信过程中，接收端发来一个挑战值（Challenge），充电板的 MCU 把这个挑战值发给 STSAFE-V110，安全芯片用内部存储的 WPC 私钥对这个挑战值做 ECDSA 签名，然后把签名结果返回给 MCU，MCU 再通过 ASK/FSK 通信回传给接收端。接收端用 WPC 的公钥证书链验证签名，验证通过后才允许进入高功率模式。
所以总结下来，安全芯片在认证链路中干的活，就是两件事：存好私钥、算好签名。但这两件事，恰恰是整个认证方案里最不能出错的环节。
2. STSAFE-V110 这颗料到底特殊在哪
2.1 它和普通安全芯片（比如 ATECC608A）的区别
市面上安全芯片其实不少，Microchip 的 ATECC608A、NXP 的 SE050 都很常见。但如果你去翻 WPC 官方发布的认证产品列表，会发现 STSAFE-V110 是专门为 Qi V1.3 定制的一颗料。为什么专门定制？两个核心原因。
第一，STSAFE-V110 出厂时已经预置好了 WPC 的完整证书链。这个证书链包括 WPC Root CA、WPC PPA（Product Personalization Authority）、制造商证书和设备证书。对制造商来说，你买到的 STSAFE-V110 不是一颗空白的芯片，而是一颗已经“实名认证”过的芯片：只要你从授权渠道采购，芯片里的证书链就是合法的、可被 WPC 公钥验证通过的。这意味着你在生产端不需要自己搭建一套 PKI 证书签发体系，极大降低了准入门槛。
第二，ATECC608A 虽然也能做 ECDSA 签名，但它的默认存储结构、密钥配置、证书格式并不是为 Qi V1.3 量身定做的。你需要自己向 WPC 申请证书、自己往芯片里灌证书、自己处理各种字段格式。这中间涉及 WPC 的注册流程、PPA 的协调周期、以及芯片内部 OTP 区的规划，很多团队在这一步就卡了几个月。而 STSAFE-V110 直接把这条路铺好了，连 JEDEC 的标准 I2C 命令接口都给你定义得清清楚楚。
当然这不是说 ATECC608A 不行，只是从“过认证”的角度来看，STSAFE-V110 的时间成本和技术风险都小得多。尤其是对中小团队，选 STSAFE-V110 基本就是答案。
2.2 内部结构、通信方式和封装选型
STSAFE-V110 的核心是一个通过 Common Criteria EAL5+ 认证的安全微控制器。它的内部有安全 CPU、存储器（包括 Flash/OTP/RAM）、硬件随机数生成器（TRNG）、以及非对称加密协处理器（支持 ECDSA P-256 签名和验证）。和外部 MCU 之间通过标准 I2C 接口通信，支持标准模式（100kHz）和快速模式（400kHz），这对大多数主控来说都没什么压力。
封装方面，STSAFE-V110 常见的有 SO8 和 SO8（或更小的封装）形式。车载场景建议优先考虑 SO8 封装，因为焊接可靠性和散热性能都比更小的封装好一些，而且手工贴片、返修也方便。数据手册上会标注工作温度范围，工业级是 -40℃ 到 +85℃，车载环境如果要求更高（比如 -40℃ 到 +105℃），还是要仔细核对具体型号后缀。
需要注意的一点是：I2C 地址是芯片出厂固化的，具体地址值要查对应型号的数据手册。不同批次的芯片，I2C 地址如果有差异，一定要在软件里做成配置项，不要写死。我见过一个项目，硬件工程师照着老版本原理图画的板子，结果新采购的芯片地址变了，软件层一直 ACK 失败，排查了整整两天才发现是地址问题。
还有一个容易被忽略的细节：STSAFE-V110 的 I2C 通信并不是简单的一读一写，它有比较复杂的命令帧格式，包含 CRC 校验、命令码、数据长度、状态字等字段。建议直接用意法半导体提供的驱动库，不要自己从零写协议栈，自己写的很容易在边界条件上出错，而且出了问题还不好找官方支持。
3. 车载场景下的硬件设计要点
3.1 供电、I2C 上拉和布局
之前提到 STSAFE-V110 通过 I2C 和 MCU 通信，但它的供电设计在车载场景里有几个容易踩的坑，得单独拎出来说。
STSAFE-V110 一般支持宽电压供电，但很多参考设计用的是 3.3V。在车载环境里，这个 3.3V 通常来自板载 LDO 或者 DCDC。如果电源纹波太大，尤其是高频纹波，可能会干扰 I2C 通信，甚至导致安全芯片内部逻辑异常。我建议在 STSAFE-V110 的电源引脚旁边放一个 1μF 的陶瓷电容，再并联一个 0.1μF 的高频去耦电容，电容位置尽量靠近芯片电源引脚。
I2C 上拉电阻的选取也要注意。车载线束通常比较长，如果充电器主控板通过连接线连接充电面板，I2C 走线可能比较长。上拉电阻太小，灌电流大，影响信号边沿；上拉电阻太大，上升时间变长，高速通信容易出错。以 400kHz 快速模式为例，总线上拉等效电阻一般在 2.2kΩ 到 4.7kΩ 之间。如果 I2C 走线超过 10cm，建议用 2.2kΩ 并适当降低通信速率，或者改用 I2C 缓冲器。
布局上还有一条铁律：STSAFE-V110 及其相关电路，尽量远离无线充电线圈的磁场辐射区和功率开关管的开关节点。无线充电系统在工作时，线圈附近有很强的磁场，功率级的高频开关会产生大量 EMI 噪声，如果不做隔离，安全芯片的通信很容易被干扰。有些项目把 STSAFE-V110 放在线圈正下方，结果每次功率一升上去，I2C 就开始丢数据。这是一个真实案例，不是理论推测。
3.2 车规要求与可靠性补充
车载无线充电器和普通桌面充电器不一样，它要过的不只是 Qi 认证，还有一系列车规可靠性要求，所以硬件设计阶段就必须考虑更严格的裕量。
首先是温度范围。车内环境夏天暴晒后，中控台附近温度可能到 85℃ 以上，如果充电器安装在空调出风口附近还好，如果安装在中控储物盒里，局部温度可能更高。建议选型时直接查找 STSAFE-V110 的完整车规版本或工业级版本，并确认工作温度上限是否满足你的目标客户整车规范。别只看商用级参数，否则高温老化测试会直接把你按在地上摩擦。
其次是 EMC 设计。车载环境里，无线充电器要过 CISPR 25 的传导和辐射发射测试。STSAFE-V110 本身是个低功耗小芯片，不是噪声源，但它的 I2C 走线如果过长且无保护，很容易成为天线，把 MCU 的高频噪声辐射出去。建议 I2C 走线做包地处理，必要时加串联电阻（比如 33Ω）在 MCU 和 STSAFE 之间，用于抑制振铃。
另外，车载供电系统的瞬态电压波动很常见。发动机启动瞬间、电池切换、继电器通断都会产生浪涌。无线充电器的电源输入端建议加 TVS 管和共模电感，但这部分通常属于整板设计，这里只是提醒：如果板子电源部分不干净，STSAFE-V110 的供电也会被牵连，进而导致认证流程中断，影响用户体验。
注意：STSAFE-V110 本身属于安全器件，不建议在量产板上对其进行“热插拔”调试。调试时如果频繁插拔 I2C 线缆，静电可能损坏安全芯片，一定要在断电并且人体接地的情况下操作。
4. 软件侧集成：从 I2C 驱动到证书交互
4.1 驱动层要做什么
硬件焊好之后，第一件事不是写 Qi 协议栈，而是先打通 MCU 和 STSAFE-V110 的 I2C 通道。
我推荐的做法：先写一个最简单的 I2C 读操作，读取芯片状态寄存器或者设备 ID，确认底层的通信没问题。STSAFE 的命令格式一般是：控制字节 + 命令 + 参数长度 + 参数 + CRC。如果返回的状态字是成功码，说明链路通。
这时要注意一个问题：不要一上来就调库。先拿逻辑分析仪抓一下 I2C 波形，确认地址、ACK、数据帧格式都正常，再去跑驱动库里的高级 API。很多问题的根子不在协议栈，而在最基础的 I2C 通信上，比如地址错误、上拉不够、时钟延展（Clock Stretching）未处理等。逻辑分析仪一抓，这些问题全都现原形。
之后再把意法半导体官方驱动库移植到你的 MCU 平台。官方库一般会封装好初始化、发送命令、接收响应、CRC 校验这些函数。移植的时候注意把底层 I2C 收发函数替换成你平台上的驱动接口，同时保证 I2C 读写的超时时间设置合理。安全芯片在某些操作（比如 ECDSA 签名）时，内部计算需要一点时间，I2C 读操作可能不会立即返回数据，所以要实现“等待非忙状态”的机制，或者至少给 I2C 读写加一个合适的超时重试。
4.2 WPC 协议层的对接逻辑
打通安全芯片的底层驱动后，接下来要让 STSAFE-V110 真正参与到 Qi 认证的流程里。
Qi V1.3 认证的典型流程大致如下：
- 接收端设备进入充电区域，与发射端建立基础通信（Ping、Identification、Configuration）。
- 双方进入协商阶段，接收端询问发射端是否支持 EPP 认证。
- 发射端回复“支持”，并从 STSAFE-V110 中取出 WPC 证书链，并通过 ASK/FSK 发送给接收端。
- 接收端发送一个随机挑战值（Challenge）。
- 发射端将该挑战值交给 STSAFE-V110，安全芯片用私钥生成一个 ECDSA 签名。
- 发射端把签名返回给接收端，接收端用公钥验证签名有效性。
- 验证通过后，接收端才能确认可以升压到 15W 或者更高功率档。
这里最关键的两个软件接口点：第一，发射端要能从 STSAFE-V110 中正确读取证书链，并按 WPC 规定的 TLV 格式封装后发送出去；第二，发射端要能把接收端发来的挑战值原样传递给安全芯片，然后把签名结果按协议要求回发。
如果你用的是官方库，一般会提供“Get Certificate”和“Generate Signature”这类高层次的 API，直接调用就行。但要注意：挑战值长度是固定的（32 字节），签名结果长度也是固定的（DER 编码的 ECDSA 签名）。不要在中途做任何格式转换，WPC 协议对字段格式的要求非常严格，一个字节的差异都会导致认证失败。
4.3 开发中容易掉进去的坑
软件集成的坑，我随手就能列出一堆，挑几个最容易踩的分享。
第一个坑是证书链长度。WPC 证书链可能不止一层，发射端的证书链里包含 Root CA 证书、PPA 证书、制造商证书和设备证书，整体长度可能是几百甚至上千字节。而 Qi 通信的底层包（尤其是 ASK 数据包）有长度限制，所以需要把证书链分段发送。分段逻辑写错，证书链解析就失败。网上很多方案是直接参考 WPC 官方参考代码里的分段算法，别自己发明。
第二个坑是超时时间。接收端在发起认证后，会有一个超时窗口，如果发射端在规定时间内没有完成签名计算并返回结果，接收端可能直接放弃认证。STSAFE-V110 做一次 ECDSA 签名理论上很快，但如果你在 I2C 通信中加入了过多重试逻辑，或者 MCU 主频太低、驱动效率太差，就可能超时。建议在正式开发时先实测一次完整签名流程的耗时，然后给整个流程留出足够的超时余量，并且把优先级拉高，确保认证期间不被其他中断阻塞太久。
第三个坑是状态管理。认证不是一锤子买卖，充电过程中接收端可能会多次发起重新认证（比如位置变动、温度变化、功率档切换）。你的软件状态机一定要支持多次认证，并且保证每次认证都从安全芯片中读取最新的证书和签名，不要把上一次的结果缓存起来。否则在某些边缘情况下会出现“第一次认证通过，之后突然不充电”的诡异问题。
第四个坑是错误处理。STSAFE-V110 的驱动库里一般都有错误码。在开发阶段，建议把所有错误码都打印出来，方便定位问题。量产版本可以适当裁剪日志，但至少要保留“认证失败计数”和“安全芯片通信失败计数”这两个诊断字段，用于售后问题分析。我见过有的团队量产固件里不返回任何错误信息，售后出了问题只能干瞪眼。
5. 认证测试：从 PTS 到实际产品
5.1 认证流程概览
聊完软硬件设计，再来说说大家最关心的认证测试流程。
Qi V1.3 认证测试的核心工具是 WPC 官方的 PTS（Protocol Test System，协议测试系统）。PTS 是一套软硬结合的工具，用来验证你的设备是否严格符合 Qi 协议的每一个细节。PTS 测试中，安全认证相关的内容占了很大的比重，包括但不限于：证书链格式是否正确、签名是否有效、认证流程的状态转换是否符合规范、错误处理是否正确、是否会在认证失败时正确拒绝升功率。
整个 WPC 认证流程大致是：产品开发完成后，先提交样品给 WPC 授权的测试实验室，实验室使用 PTS 和配套的测试夹具进行符合性测试。测试通过后，再由实验室把测试报告提交给 WPC 审核，审核通过后产品就会出现在 WPC 官网的认证产品列表里。这个过程一般需要几周到几个月不等，取决于实验室的排期和你的产品修改迭代速度。
这里提醒一句：不要等到产品全部做完了才开始准备认证。WPC 认证对产品硬件形态是有要求的，如果你改了线圈布局、改了 EMI 滤波电路，测试结果可能完全不同。建议在硬件设计定型之前，就跟测试实验室沟通清楚，了解关键的测试项和测试夹具要求，避免后期大改。
5.2 常见失败项和排查手册
我把自己见过的认证失败案例整理成一张表，方便各位在送测前自查。
| 失败现象 | 可能原因 | 排查建议 |
|---|---|---|
| 证书链验证失败 | 从 STSAFE 读取的证书链不完整或格式错误 | 用官方工具读取完整证书链，与 WPC 参考值比对 |
| 签名验证失败 | 挑战值传递错误或 ECDSA 实现有问题 | 用逻辑分析仪抓 I2C 数据，确认挑战值和签名值一致 |
| 认证超时 | 安全芯片通信耗时过长或协议分段逻辑效率低 | 实测一次完整签名流程耗时，优化驱动重试逻辑 |
| 认证流程卡在中间状态 | 状态机设计有缺陷，不支持多次重新认证 | 用 PTS 日志回放，定位状态跳转异常的位置 |
| 大功率输出被拒 | 认证失败时未正确降级为 5W 基础模式 | 检查失败处理逻辑，确认失败后不进入 EPP 档 |
| PTS 测试间歇性失败 | 硬件 EMI 干扰或 I2C 时序不稳 | 检查板级布局、上拉电阻、I2C 走线屏蔽 |
这张表只是最典型的几种情况，实际测试中还会有更多细碎问题。但核心思路是一样的：出现失败先抓完整日志，包括 Qi 协议层日志、I2C 通信层日志、安全芯片错误码日志，三层对齐后再定位问题。千万不要只看现象猜原因，安全认证问题尤其忌讳拍脑袋。
那说到日志，我多说一句。PTS 在跑认证测试的时候，它的日志信息非常详细，连每个数据包的每个字节都会打印出来。如果你的产品在 PTS 上失败，最有效的方式是先看 PTS 日志，它会告诉你具体在哪一步、哪个包、哪个字段出了问题。我之前碰到过一次认证失败，排查了两天，最后发现是证书链里某个 TLV 字段的 Length 多了一个字节。这个问题如果只看现象，根本无从下手，但 PTS 日志会直接指出来。
6. 量产阶段的注意事项
6.1 芯片供应链与数据管理
产品通过认证后，进入量产阶段，有几个和生产相关的问题值得提前规划。
首先，STSAFE-V110 是安全芯片，它的采购渠道必须从意法半导体或其授权分销商走正规渠道。因为每一颗芯片的证书链都是唯一的、与物料批次绑定的。如果你从非正规渠道采购，芯片的证书链可能没有在 WPC 的数据库里注册，过不了验证，这就等于白买了。
其次，生产烧录环节要注意：STSAFE-V110 通常在出厂时已经预置好证书，不需要产线二次烧录安全数据。这其实是个好消息，因为不需要管理复杂的密钥灌装流程。但代价是你在生产时要做好物料追溯管理。每一片 PCBA 上贴的是哪一颗芯片、用的是哪个批次，都要记录在案。因为一旦某个批次的芯片证书出问题，你要能追溯到具体交付给哪个客户的产品。
6.2 终端用户体验的设计
最后说说产品层面的设计建议。车载用户在插入手机后，如果手机开始正常充电，通常不会再看车机界面。但如果认证失败，接收端会拒绝高功率充电，用户只会看到手机充电很慢，可能以为是充电器坏了，直接找售后投诉。
为了避免这种情况，建议在发射端加入状态指示功能：当认证正在进行时，指示灯显示特定状态；当认证失败时，给出明确提示。另外，认证失败后不应该死锁，软件要自动进入基础 5W 模式，并定时尝试重新认证。比如手机在充电位置稍微挪动了一下，认证失败了一次，但下个充电周期又可以重新建立认证。这个“重试”逻辑对实际用户体验的影响，比我预想的还要大。
我在实际项目里还碰到过一个情况：某个批次的手机系统对 Qi V1.3 认证要求特别严格，如果发射端在首次认证时签名耗时超过它的容忍阈值，手机会直接判定认证失败，并且短时间内不重新发起认证。优化办法就是严格控制安全芯片通信耗时，以及把 MCU 的 I2C 通信优先级提到最高，认证期间关闭一切不必要的中断任务。
7. 最后分享一点个人经验
做了几个 Qi V1.3 项目之后，我最大的体会是：STSAFE-V110 方案本身并不难，难的是对整个认证流程的理解和尊重。
硬件上，只要照着参考设计做，供电和 I2C 不踩坑，基本不会有太大问题。软件上，驱动库都给你封装好了，真正容易出错的是状态机和协议细节。最难熬的反而是认证测试阶段，因为 WPC 协议对每个字节、每个时序都有严格要求，差一点就得来回改。
建议所有计划做车载 Qi V1.3 产品的团队，在最开始设计的时候就把安全芯片的选型、布局、软件架构全部定下来。中途换安全芯片的代价非常高，因为证书链、硬件布局、软件驱动、PTS 测试项全部要跟着变。
最后的最后，再分享一个调试小技巧：在开发阶段，可以在 STSAFE-V110 的 I2C 总线上挂一个逻辑分析仪，把所有通信数据录下来。当出现认证问题时，不要只看现象，先看抓包记录，真的能救你很多次。
