ST25R3916 NFC读卡器实战：从天线调谐到批量稳定读取

ST25R3916 是一颗需要认真对待的高频 NFC 读卡器前端芯片。它支持的协议比常见读卡模块更全，输出功率更高，适合做门禁读头、支付终端、工业读写设备这类产品。很多人第一次拿到这颗芯片，第一反应是按普通 NFC 模块的思路接上 MCU 去读卡号，实际这样做通常会卡在天线调谐和协议配置上。这篇文章按实际跑通的流程，从硬件准备、最小读取流程、批量读取思路到排查顺序拆一遍，适合做硬件开发的工程师，也适合刚开始接触 NFC 读写器固件的学生。最值得关注的地方不是它怎么读一张卡，而是如何稳定、可重复地读一批不同协议、不同距离、不同状态的卡片。

1. ST25R3916 解决的不是“读卡号”这么简单

1.1 它是一颗完整的 13.56MHz 高频读卡前端

ST25R3916 不是一颗封装好了全部读卡逻辑的“即插即用”模块，而是一颗射频前端芯片。它负责把主控 MCU 下发的命令转换成符合标准协议的射频信号，再通过天线发射出去；同时，它负责接收卡片返回的信号，解调、解码后把数据送回给 MCU。

所以这块芯片真正解决的是“高频信号的调制、发射、接收、解调”这一整条链路问题。主控端只需要通过 SPI 或者 I2C 接口与 ST25R3916 通信，再使用驱动接口发送标准命令，比如 ISO 14443A 的 REQA、WUPA，ISO 15693 的 Inventory 命令，FeliCa 的 Polling 命令等。

我最初接手这颗芯片时也犯过理解偏差：以为功能被封装好了，连上就能读 M1 卡的卡号。实际上它把“射频通道”和“协议状态机”都开放出来了，读卡能力完全取决于主控固件写得好不好。这也是它看起来比普通 NFC 模块门槛高的原因。

1.2 和手上现有的 NFC 模块相比，它的差异在哪

很多人比较熟悉的是 PN532、RC522 这类模块。它们好用，但设计目标完全不同。

常见的差异体现在这几处：

• 卡片协议覆盖范围不一样。ST25R3916 通常覆盖 ISO 14443A、ISO 14443B、ISO 15693、FeliCa，甚至部分场景还支持 NFC-A、NFC-B、NFC-F 的轮询切换。RC522 主要面向 ISO 14443A，读不了 ISO 15693。
• 发射功率可控性不一样。ST25R3916 的发射功率可配置，能够支持更大范围的天线设计和读取距离调整。
• 天线调谐能力不一样。它支持自动天线调谐，也就是 AAT 这类机制，可以在一定范围内自动匹配天线参数，降低人工调天线的难度。
• 数据速率和稳定性不一样。它支持更高比特率，并且在连续读写、多协议切换场景下更稳。

这里要提醒一句：支持更多协议不等于所有协议都好用。实际项目里，如果只读一种卡，用普通模块可能更方便；需要做多协议兼容、大功率天线、批量读取稳定性的场景，ST25R3916 才更值得。

1.3 实际落地场景和适用人群

我接触 ST25R3916 的主要原因，是做一个多协议读卡器。需要能读校园卡、门禁卡、部分电子标签，还要把数据通过串口汇总到上位机。

这种需求有一个共同点：不只要“读一张卡”，还要“读很多不同来源的卡”，并且要判断每张卡属于哪种协议、数据存在哪个区域、是否需要认证。

所以这篇文章的读者，应该是这几类人：

• 正在用 STM32 调 ST25R3916，但读取一直不稳定的开发人员。
• 想从 RC522 这类简单模块切换到多协议方案的工程师。
• 在做一个读卡器，需要自己设计天线和固件，不只是插上评估板跑 Demo 的开发者。
• 需要把 NFC 读取能力做成上位机工具，减少人工测试重复劳动的人。

2. 跑通 NFC 读取前，先把硬件和软件环境理清

2.1 硬件准备：最小系统怎么搭

ST25R3916 是贴片芯片，不是开发板，第一次测试最好用它官方的评估板或者第三方核心板。如果是自己画板，最小系统需要这几部分：

• 主控 MCU。常见搭配是 STM32，也可以用其他支持 SPI 或 I2C 的 MCU。关键是主控要有足够的中断引脚和定时器资源，方便处理 ST25R3916 的中断请求。
• SPI 或 I2C 接口连接。SPI 数据吞吐更高，适合需要频繁轮询多协议的场景。I2C 接线简单，但速度上限会偏低。
• 晶振时钟。ST25R3916 工作时需要参考时钟，常见做法是外接 13.56MHz 晶振，也可以从主控输入时钟信号。晶振频率准确度会影响射频精度，这一项不能马虎。
• 天线。可以买匹配好的天线板，也可以自己设计。第一次调试建议先用参考设计的常见天线尺寸，不要一上来就做异形天线。
• 电源。芯片发射射频时瞬时电流较大，电源纹波会影响读取稳定性。建议在供电引脚附近放足够容量的退耦电容，并用示波器确认发射瞬间电压没有明显跌落。

如果只是想先验证芯片能不能工作，最快的路径是买一块已经焊好 ST25R3916 和天线的开发板，用 STM32 或者电脑上位机连上去跑通一次读取。这个阶段不要混入自己画的天线，否则后续排查会把问题点搞复杂。

2.2 软件准备：驱动、库和调试工具

软件方面分三块：底层驱动、协议封装、验证工具。

底层驱动这块，通常可以用原厂提供的驱动包，也可以通过寄存器手册自己写寄存器配置。我的建议是第一次不要全部自己写，先把官方参考代码跑通，再按需修改。因为 ST25R3916 的寄存器很多，初始化顺序和时序要求都比较细，自己从零写容易漏步骤。

协议封装需要处理 ISO 14443A/B、ISO 15693、FeliCa 这几类标准。不同协议的防冲突、选卡、读写命令逻辑不一样。很多读取不稳定的问题，不是射频问题，而是协议状态机在某一帧没有正确流转。

验证工具也很重要。开发阶段，电脑上的 NFC 调试工具能帮你确认这套链路本身是不是有问题。我一般流程是：

1. 先在电脑上用读卡器工具确认待测卡片正常，能读到卡号和数据。
2. 再写固件跑单卡读取。
3. 最后才考虑批量、长时间稳定运行。

如果电脑上的工具都识别不到卡片，说明卡片类型比较特殊，或者卡本身有问题，这时候不要急着怀疑 ST25R3916。

2.3 环境准备检查表

我在实际调试前会按这个列表逐项确认：

• 主控和 ST25R3916 的供电电压是否正常。
• SPI/I2C 通信是否通，能不能读芯片 ID 寄存器。
• 晶振是否起振，频率是否在 13.56MHz 附近。
• 天线的谐振频率是否落在 13.56MHz 附近。
• 中断引脚是否连接到主控并配置正确。
• 上位机工具能不能识别待测卡片。

其中芯片 ID 寄存器能不能读出来，是最基础的确认项。如果这一步都不通，后面所有读取流程都不用看。很多“启动失败”问题，最后排查下来就是 SPI 接线写反，或者芯片供电没给够。

3. 单张卡片读取的完整流程

3.1 初始化射频前端

初始化 ST25R3916 的第一步，是给它一个正确的启动状态。这个步骤通常包括：

• 复位芯片，等待内部振荡器稳定。
• 配置输出时钟和供电模式。
• 设置 SPI/I2C 通信模式。
• 读取芯片版本寄存器，确认通信正常。

初始化完成后，芯片处于射频关闭状态，还没有开始往外发载波。先不要急着读卡，确认基础配置无误再做下一步。

这里我建议把初始化过程封装成一个独立函数，返回布尔值。主程序启动时如果初始化失败，直接打印错误信息，方便后续定位。

3.2 配置天线调谐和协议轮询参数

射频前端初始化后，需要把天线调到一个能有效发射和接收的状态。ST25R3916 可以配置天线调谐参数。使用自动调谐时，芯片会在校准过程中测量天线参数，并自动选择匹配配置。如果使用手动匹配，需要根据天线实际阻抗计算匹配电容电阻。

第一次做，直接用自动调谐最省事。它能处理大部分常规天线设计。但自动调谐不代表万能，如果天线本身设计得很偏，比如线圈匝数太少、面积太大导致阻抗偏离太多，自动调谐也无法完全补偿。

调谐完成后，配置轮询协议列表。常见需求是一张卡可能属于多种协议，固件需要按顺序轮询：

• 先发 ISO 14443A 的 REQA 请求。
• 如果没有响应，切到 ISO 14443B。
• 再没有，切到 ISO 15693。
• 最后试 FeliCa。

轮询顺序和超时时间会影响响应速度。默认配置顺序通常够用。如果项目只需要读一种协议，建议关闭其他协议轮询，降低复杂度和功耗。

3.3 发起轮询、防冲突、建立通信

这个阶段是读取流程的核心：芯片开始发射射频场，并等待卡片上电响应。卡片进入射频场后，会响应请求命令。

流程大致如下：

1. MCU 下发轮询请求。
2. ST25R3916 发射 RF 场并接收卡片应答。
3. 如果检测到卡片，芯片产生中断，MCU 读取事件状态。
4. 选择协议分支，进入防冲突流程。
5. 防冲突完成后，获得卡片的唯一标识符，也就是 UID。
6. 根据协议选卡，进入后续数据读取。

对于 ISO 14443A 卡片，防冲突可能得到 4 字节、7 字节或 10 字节 UID。不同长度的 UID，处理逻辑略有差异。有时候你已经成功发出了请求，但就是拿不到完整 UID，往往就是防冲突循环中某个级联标志没有处理对。

FeliCa 和 ISO 15693 的取 UID 流程又不一样。FeliCa 通过 Polling 命令拿到 IDm，ISO 15693 通过 Inventory 命令拿到 UID。所以固件里不能只有一套读卡号逻辑，要针对每种协议写对应的取 ID 流程。

3.4 读取数据、验证结果

拿到 UID 只是第一步。真正要“读取数据”时，还要区分卡的类型和数据区结构。

比如：

• M1 Classic 卡：需要先做扇区认证，认证通过后才能读写该扇区的块数据。
• NTAG 系列：无需复杂认证，直接按页读取，数据区和用户内存区域结构清晰。
• ISO 15693 的标签：通过 Read Single Block 或 Read Multiple Blocks 读取块数据。
• FeliCa：通过 READ WITHOUT ENCRYPTION 等命令读取服务数据。

每次发出读取命令后，固件应当判断返回状态。状态可能是成功、超时、CRC 错误、协议错误、无应答。不能只判断“有没有返回数据”，还要判断返回数据是否完整、是否正确结束。

我习惯在读取流程中加一个简单的重试机制：单次读取失败后，先关射频场，再打开射频场，然后重新轮询。这样做可以解决一部分卡片在复杂环境下的响应异常。

3.5 一次单卡读取的最小验证方式

单卡读取成功，可以从三个层面确认：

• 读到了预期 UID，并且 UID 长度符合该协议类型。
• 读到了数据区内容，打印出来与上位机读到的结果一致。
• 多次反复拿卡、放卡，每次都能得到一致结果。

如果这三项都通过，说明基础链路正常，可以进入批量或轮询读取。如果拿卡后偶尔读不到，先不要动协议配置，回到第 4 部分的硬件排查去确认天线和电源。

4. 读取不稳定时，按这个顺序排查

4.1 先看现象和输入条件

遇到读取不稳定，第一步不是改参数，而是记录现象。常见现象分这几类：

• 完全无响应：卡片放到天线上，芯片没有任何中断。
• 偶尔能响应，偶尔无响应。
• 能看到卡片信号，但读取中途卡住。
• 读取数据错误，比如 UID 长度不对、数据内容乱码。
• 距离很变态地近，必须贴住才能读取。

现象不同，排查方向完全不同。完全无响应和读取中途卡住大概率不是同一个原因。

所以我会先问几个问题：

• 用的是哪张卡？是 ISO 14443A 还是 ISO 15693？
• 之前该卡片用其他读卡器能不能正常读取？
• 天线是自己设计的还是评估板自带？
• 电源用的是 USB 供电还是独立电源？
• 有没有在金属桌面附近测试？

这些问题看起来基础，但能快速缩小排查范围。很多“芯片不工作”的现场，最后其实出在测试环境太恶劣。

4.2 再查硬件信号和天线匹配

硬件层面，我建议的排查顺序是：

1. 用示波器检查 ST25R3916 发射端的天线波形。正常情况下，发射期间应该有稳定连续的 13.56MHz 载波。如果波形幅度抖动或者起始阶段跳变太大，多半是电源问题。
2. 检查天线谐振频率。把天线接到网络分析仪上，看阻抗是否在 13.56MHz 附近。误差太大时，读取距离会明显下降。
3. 检查天线匹配网络的元件值。差分天线、非平衡天线、匹配电容的取值要和参考设计接近。
4. 检查供电电压。发射瞬间电流上升时，电压有没有塌陷。如果电压跌落超过一定范围，卡片无法获得足够能量响应。

我在实际测试中遇到过一种情况：天线谐振频率偏到 15MHz 以上，卡片只有紧紧贴在天线上才能读到。把匹配电容替换成参考值后，读取距离马上恢复正常。这类问题通过波形分析比反复改软件有效得多。

4.3 再看协议配置和卡片因素

硬件没问题时，回到软件协议配置上。重点看这几项：

• 发射功率。ST25R3916 支持不同功率档位，调低后读取距离会下降。如果距离要求高，需要确认功率配置和天线是否匹配。
• 调制深度。ISO 14443A 的调制深度有区间范围，配置需要符合标准。
• 波特率。部分卡片只支持标准速率，不支持高速率。不要为了追求速度而直接把比特率拉高。
• 防冲突状态机。多张卡同时在场时，防冲突流程是否完整，没有完成的级联是否超时。
• 超时时间。轮询超时设置太短，可能出现卡片还没响应就结束轮询。

卡片本身也是重要变量。不同厂商、不同批次的卡，物理特性会有些差异。尤其是 M1 卡和 NTAG 卡，虽然都走 ISO 14443A，但数据区读取方式完全不同。还有一些二手卡或复制的卡，芯片本身工作状态可能不稳定，用它们来调试容易产生错误判断。

4.4 最后看软件状态机

软件层面的排查，我按这个思路走：

• 初始化顺序。是不是在射频开启前就把寄存器、天线调谐、协议配置都做完了。
• 中断处理。ST25R3916 通过中断通知 MCU 事件。中断响应太慢，事件标志被清掉，会导致状态机跑飞。
• 重试机制。读取失败后，是直接退出，还是自动关场重开。
• 资源占用。MCU 如果在读卡期间同时处理其他任务，可能延迟或漏掉中断，导致超时。

排查软件问题，最有效的手段是加日志。每进入一个状态，打印当前位置和关键事件。连续跑几十次，把日志拿回来对照，就能看出哪一步最不稳定。

4.5 一个典型的排查顺序表

这张表不是绝对标准，但能帮助减少盲目改参数的时间。遇到问题先锁定一层，确认没问题再进下一层。

5. 从单卡读取到批量读取的工程化思路

5.1 单卡流程稳定后再做轮询循环

很多开发者会跳过单卡验证，直接写“循环读卡”。结果可能是单张卡能读，多张卡连续读就会出现偶发失败。这通常不是因为芯片性能不够，而是轮询逻辑没处理好。

单卡流程跑通后，下一步是把它包成一个可重复执行的函数：

• 每轮先关闭射频场，让上一张卡完全离开射频场。
• 短延时后重新开启射频场。
• 执行多协议轮询。
• 读到卡片后做数据处理。
• 处理完后再次关闭射频场。

关场、开场这个动作非常重要。它保证了每张卡片是在相同条件下被唤醒的，不会出现上一张卡的内部状态残留。

5.2 批量读取时的防冲突和重试逻辑

如果是读取一批卡片，比如测试时一次放十张卡到天线上，这时候防冲突就非常关键。

NFC 协议本身设计了防冲突机制，ST25R3916 可以协助完成部分流程，但最终的防冲突循环控制逻辑还是要主控固件完成。每一轮防冲突中，MCU 需要处理冲突位，生成新的命令帧，继续下一次防冲突请求，直到卡片响应满足条件。

批量读取时的重试逻辑也要重新设计。不能简单在单卡失败后无限重试，那样会导致整批任务卡死在一个错误上。更好的做法是：

• 每张卡最多重试 N 次。
• 超过 N 次后，记录错误原因，跳过当前卡，继续下一张。
• 最后生成统计结果：成功多少、失败多少、失败原因分类。

这样做即使中途出现异常卡，也不会影响整批任务的完成度。

5.3 数据记录与上位机对接

读卡数据最终通常要汇聚到上位机或者数据库。这层对接越早做好，后面测试和调试越省力。

常见的数据记录方式有这些：

• 简单串口打印：适合单张调试。
• CSV 文件记录：适合批量测试，后续可以直接用表格工具分析。
• 无源数据库，比如 SQLite：适合本地长时间运行。
• 通过 USB 或网口发送给上位机软件：适合设备级产品。

我建议在开发阶段就固定一套输出格式。比如每行数据包含：时间戳、协议类型、UID 长度、UID 内容、数据区读取结果、错误码。这样无论单卡还是批量，拿到的日志格式都一致，排查效率会高很多。

电脑版的 NFC reader tool 也可以用来做上位机对照，但它通常只是验证工具，不是产品级方案。真正的设备固件要自己实现完整的数据处理流程。

5.4 长时间运行的稳定性验证

批量读取还不是最终目标，连续运行数小时甚至一整天才算过稳定性关。

长时间运行时，最容易出现的问题有：

• 内存泄漏或缓冲区溢出，导致运行一段时间后死机。
• 中断频繁累积，主控处理不过来。
• 射频场长时间开启导致发热，影响芯片参数漂移。
• 天线和卡片距离发生微小变化，导致偶发读取失败。

验证稳定性的方法是加压测：跑一整晚，统计每小时的读取成功率和失败率。如果失败率不稳定或趋于上升，说明有隐藏问题需要排查，不是单纯运气不好。

6. 实际踩坑记录和参数边界

6.1 天线设计对读取距离的影响

我最早做 ST25R3916 读取测试时，用了自己画的一个小型 PCB 天线，面积约 4 厘米乘 4 厘米。结果读取距离非常不理想，只有 1 厘米左右，而且角度稍偏就完全无响应。

后来用网络分析仪测天线阻抗，发现谐振点偏移比较大。更换匹配电容后，读取距离变到 3 厘米以上。这个经验说明，ST25R3916 本身发射能力不弱，但如果天线设计偏离参考值太多，芯片能力发挥不出来。

天线设计的核心是谐振频率和品质因数。品质因数太高会导致带宽过窄，对卡片频率偏移敏感；太低则信号衰减快，读取距离下降。实际项目中，天线调试主要靠反复调整匹配网络，然后用实际卡片验证。

6.2 电源噪声导致的不稳定

另一个高频坑是电源。

ST25R3916 发射阶段电流不是平稳的，而是上下跳变的。如果供电链路阻抗偏高或者退耦电容不足，电源电压会出现明显跌落。这种情况下，轻则读取距离下降，重则芯片进入复位状态，表现为“偶然完全无响应”。

我排查这类问题时，会先看两个点：

• 靠近 ST25R3916 供电引脚，用示波器观察发射期间的电压波形。
• 确认主控和 ST25R3916 不是共用一条高阻抗走线供电。

如果电压跌落明显，先增加大容量储能电容，再把电源走线加宽，很多时候问题就解决了。

6.3 多协议切换不是免费的

ST25R3916 支持多协议，但多协议轮询的频率和时间是有代价的。每切换一种协议，都需要重新配置射频参数，可能重新调谐天线。轮询列表越长，单轮耗时越长，卡片等待唤醒的时间越长。

实际经验是：先确认项目只需要哪几种协议，把不需要的关闭。比如只读 ISO 14443A 和 ISO 15693，就不要加入 FeliCa 轮询。这样既能提高响应速度，也能减少不必要的复杂错误场景。

6.4 哪些参数不建议一上来就乱调

很多人拿到芯片后喜欢把所有寄存器配置调一遍，结果越调越差。我的建议是：

• 发射功率不要一上来就拉到最高，先按参考配置跑通。
• 调制深度不要随便改，除非确认卡片侧兼容性。
• 自动天线调谐先打开，跑通了再决定是否手动配置。
• 数据速率先按标准速率，等流程稳定后再试验高速率。
• 超时时间先放宽，确认能读到卡后再缩短。

这些参数不是不能调，而是要先有一条稳定基线。没有基线就调参数，出了问题很难判断是哪个修改导致的。

6.5 一个值得养成的调试习惯

最后说一个调试习惯：每次只改一个变量。

不管遇到现象多奇怪的 NFC 读取问题，我都会强迫自己每次只改一个变量，改完记录结果，再改下一个。虽然慢，但能准确找到关联性。

合适的方向不是把 ST25R3916 当普通模块直接调，而是先建立最小可读系统，再逐步扩展。从单卡到批量，从单协议到多协议，从开发板天线到自设计天线，每一步都有明确的验证标准。

ST25R3916 真正落地到产品时，最该盯住的不是它支持多少协议，而是天线匹配、电源稳定、轮询状态机和错误重试逻辑。这几项跑到稳定，NFC 读取这个功能才算真正做完了。