NFC调试：NFC HAL、LLCP协议、卡模拟问题、标签读写
NFC调试，说实话，是Android系统调试里比较"玄学"的一块。为什么这么说？因为NFC涉及硬件、固件、驱动、协议栈、应用层，任何一个环节出问题，表现都是"刷不上"、"读不到"、"没反应"。我这些年踩过的坑，十个手指头数不过来。今天咱们就把NFC调试的四个核心模块——HAL层、LLCP协议、卡模拟、标签读写——掰开揉碎了讲清楚。
一、NFC HAL层调试：从驱动到框架的桥梁
NFC HAL（Hardware Abstraction Layer）是Android NFC架构中最关键的一层。它位于Linux内核驱动和Java框架层之间，说白了就是NFC芯片厂商（NXP、ST、Broadcom等）提供的适配层。
我个人习惯，遇到NFC完全无法打开的情况，第一件事就是看HAL层日志。怎么抓？用这个命令：
adb logcat -b all | grep -E "(NFC|Nxp|NfcHal|nfc@)"为什么是all？因为NFC HAL的日志可能出现在main、system、events多个缓冲区里。我曾经遇到过一个案子，HAL层初始化失败，但main log里完全看不到错误，最后在events log里找到了关键线索——NFC_ENABLE_FAILED。
HAL层调试核心检查点：
- 固件版本：检查NFC芯片固件是否匹配。我遇到过某款手机升级Android版本后，旧固件不兼容新HAL，导致NFC间歇性死机。
- I2C/SPI通信：HAL层通过I2C或SPI与NFC芯片通信。用
i2cdetect或cat /sys/bus/i2c/devices/.../name确认设备节点存在。 - 中断检测：NFC芯片通过GPIO中断通知HAL层有数据到达。用
cat /proc/interrupts | grep nfc看中断计数是否增长。 - EEPROM/配置加载：很多NFC芯片需要从EEPROM加载配置。如果配置损坏，HAL层会报
NFC_CONFIG_FAILURE。
嗯，这里要注意一个坑：有些厂商的HAL层实现里，固件下载是在HAL初始化阶段完成的。如果固件下载失败，HAL会直接返回false，上层就会认为NFC硬件不存在。我曾经在调试一款NXP PN553芯片时，发现固件下载总是超时，最后定位到是SPI时钟频率设置太高，降频后问题解决。
二、LLCP协议调试：点对点通信的"隐形杀手"
LLCP（Logical Link Control Protocol）是NFC点对点通信的核心协议。Android Beam、文件传输、甚至某些支付场景都依赖它。LLCP调试的难点在于——它太底层了，上层应用根本感知不到它的存在，出了问题只会告诉你"传输失败"。
LLCP协议栈在Android中位于system/nfc/src/nfc/llcp/目录下。调试LLCP，我一般关注三个层面：
| 层面 | 关键日志标签 | 常见问题 |
|---|---|---|
| LLCP链路建立 | NFC_LLCP | SYMM超时、参数协商失败 |
| LLCP数据传输 | NFC_LLCP_DATA | 序列号错乱、窗口溢出 |
| LLCP断开 | NFC_LLCP_DISC | 异常断开、残留连接 |
举个例子，两台手机互相碰一下，A手机显示"已连接"，B手机也显示"已连接"，但就是传不了文件。这种情况，十有八九是LLCP的参数协商出了问题。LLCP在建立连接时会交换MIU（最大信息单元）和RW（接收窗口大小）。如果一方MIU设置过大，另一方缓冲区不够，就会丢包。
我的调试技巧：
在nfc_nci.c或nfc_llcp_main.c中增加日志，打印LLCP连接建立时的MIU和RW协商值。我曾经在Nexus 5X上遇到过，某次OTA后LLCP的MIU从默认的198字节变成了1024字节，导致与旧设备通信失败。加一行LLCP_TRACE_DEBUG1("MIU=%d, RW=%d", miu, rw);就定位到了。
还有一个坑：LLCP的SYMM包。SYMM是LLCP的心跳包，用于维持连接。如果SYMM包丢失，LLCP会认为连接断开。我遇到过一种情况，两台手机距离很近（<1cm），但SYMM包反而丢失了——因为NFC天线耦合过强，信号饱和了。拉开到2-3cm，问题消失。
三、卡模拟问题：为什么我的手机刷不上闸机？
卡模拟（Card Emulation）是NFC最常用的功能之一——手机模拟成一张公交卡、门禁卡、银行卡。卡模拟调试的难点在于：你没法直接看到NFC芯片和读卡器之间交换了什么数据。
Android的卡模拟分为两种模式：
- 基于HCE（Host-based Card Emulation）：数据通过NFC控制器转发到AP（应用处理器），由Android应用处理。Android 4.4+支持。
- 基于SE（Secure Element）：数据直接在NFC控制器和SE芯片之间传输，AP不参与。安全性更高，但需要硬件SE。
调试卡模拟问题，我建议按这个顺序排查：
- 确认NFC控制器处于卡模拟模式：用
adb shell dumpsys nfc查看当前NFC状态。如果显示mState=RF_STATE_LISTEN，说明处于监听（卡模拟）模式。 - 检查路由表：卡模拟依赖路由表（Routing Table）来决定哪个应用处理哪个AID。用
adb shell dumpsys nfc | grep -A 20 "Routing Table"查看。 - 抓取NCI日志：NCI（NFC Controller Interface）是NFC控制器和AP之间的通信协议。在
/data/vendor/nfc/或/data/misc/nfc/下找nci日志文件。
警告：卡模拟调试中最容易忽略的是射频参数。NFC读卡器（比如地铁闸机）对射频信号的调制深度、负载调制幅度有严格要求。如果手机NFC天线的匹配电路设计不好，或者外壳金属件影响了天线性能，就会出现"有的闸机能刷，有的刷不了"的情况。这种问题，软件层面基本无解，只能改硬件。
我记得有一次，某款手机在深圳地铁刷不了，但在北京地铁可以。最后发现是深圳地铁的读卡器对射频信号的上升时间要求更严格，而该手机的NFC天线匹配电容偏大，导致信号上升沿变缓。换了一颗电容就好了。
四、标签读写：为什么读不到？为什么写不进去？
标签读写是NFC最基础的功能，但也是最容易出问题的。标签类型五花八门——NFC Type 1/2/3/4/5，MIFARE Classic，FeliCa……每种标签的协议栈都不一样。
调试标签读写，我总结了一个"三板斧"：
- 看标签发现日志：当手机靠近标签时，NFC控制器会发送
RF_DISCOVERY_NOTIFICATION事件。日志里会显示标签的UID、协议类型（ISO-DEP、NFC-DEP等）、速率（106kbps、212kbps、424kbps）。如果连这个事件都没有，说明NFC天线或射频部分有问题。 - 检查标签协议栈：不同的标签类型，Android使用不同的协议栈。MIFARE Classic走的是
NfcA+MifareClassic，ISO-DEP（Type 4）走的是IsoDep。如果协议栈不匹配，会报TAG_LOST或IO_EXCEPTION。 - 验证读写命令：用
adb shell dumpsys nfc | grep -A 10 "Tag"查看应用发送的读写命令。比如读MIFARE Classic的块数据，命令格式是0x30 + 块号。如果命令格式不对，标签会返回NAK。
标签读写常见错误码：
0x01：命令不支持（比如对Type 2标签发Type 4命令）0x04：认证失败（MIFARE Classic需要先认证）0x0A：写保护（标签被锁定）0x14：内存不足（写操作超出标签容量）
我遇到过最奇葩的一个问题：某款手机读MIFARE Classic标签，第一次读正常，第二次读就报TAG_LOST。折腾了两天，最后发现是NFC控制器的防冲突（Anti-collision）算法有问题。当手机离开标签再靠近时，防冲突算法没有正确重置，导致UID校验失败。升级NFC固件后解决。
五、NFC调试知识体系总览
下面这张图，是我自己整理的NFC调试知识体系。每次遇到NFC问题，我都会先看这张图，定位问题属于哪个层面，再针对性排查。
这张图把NFC调试分成了四个层面。从上到下，每个层面都有对应的日志标签和调试工具。我个人习惯，遇到NFC问题，先看问题出在哪个层面——是应用层报错？还是HAL层初始化失败？还是硬件层根本没响应？定位到层面之后，再用对应的工具深入排查。
好了，NFC调试的四个核心模块就讲到这里。说实话，NFC调试没有银弹，每个问题都得结合具体的芯片、固件、应用场景来分析。但只要你掌握了HAL层、LLCP、卡模拟、标签读写这四个维度的调试方法，大部分问题都能找到方向。剩下的，就是耐心和细心了。
公众号:蓝海资料掘金营，微信deep3321