从一次次读卡失败说起
做门禁、宿舍考勤、智能储物柜这类项目，MFRC522这颗NFC读卡芯片几乎是绕不开的选择。一方面是因为它便宜、资料多、到手即用；另一方面是STM32的生态太成熟，两条线一搭就能跑起来。但我在多个实际项目里踩过不少坑之后发现：真正把MFRC522通过SPI接口稳定跑起来，和“读卡器能亮灯”完全是两码事。很多人拿着例程改几个引脚，发现能读卡就收工了，结果一到现场就频繁掉线、读卡延迟、甚至上电必死。
这篇文章就围绕STM32与MFRC522的SPI通信来展开，重点讲清楚三件事：SPI链路怎么初始化才算正确、哪些硬件细节决定了通信质量、以及一旦出现问题该怎么定位。内容以我实际调项目时的记录为主，适合正在做毕设、DIY门禁、或者第一次把MFRC522接入自己板子的人参考，也适合已经能跑通但想进一步优化通信稳定性的朋友。
1. 整体设计与思路拆解：先把通信模型搞清楚
1.1 MFRC522到底在做什么
MFRC522是一颗13.56MHz的非接触式读写芯片，支持ISO/IEC 14443A标准的MIFARE卡通信。从MCU的角度看，它就是一个从设备，MCU通过SPI、I2C或UART三种接口之一对它发送命令、读写寄存器。MFRC522内部集成了RF模拟前端、发送/接收模块、以及一个8位并行接口，SPI/I2C/UART只是“门卫”，最终都是通过访问寄存器来操作射频收发。
很多人第一次接触时会犯一个认知上的错误：以为MFRC522像W5500那样，把一大包数据扔进去就能自己把活干完。实际上MFRC522的寄存器操作非常底层，比如你要读一张卡，需要自己去控制Request、Anticollision、Select等一系列命令帧，每一步都要等芯片返回状态。所以SPI通信质量直接决定了整条链路的体验——SPI一旦出错，后面所有跟卡的交互都会崩。
1.2 为什么是SPI，而不是I2C或UART
MFRC522同时支持SPI、I2C、UART，而且出厂默认配置不一样。SPI模式是常用选择，原因很朴素：速率更高、时序可控、调试方便。I2C虽然只占两根线，但速率上限和应答机制在干扰环境下容易出问题；UART虽然简单，但需要双方波特率严格匹配，而且MFRC522的UART模式在不少资料里写得比较绕，新手容易卡在初始化上。
SPI模式下，MFRC522的最高SCK时钟为10MHz，这个速率对绝大多数场景都够用。关键的是SPI是主从同步通信，时钟由主机产生，从机不需要精确的时钟源，这就避免了很多“双方速率不匹配”的问题。对STM32来说，硬件SPI外设已经非常成熟，开启SPI后，把NSS引脚拉低、发命令、收数据，整条链路清晰明了。
这里还要提一句：MFRC522的SPI从机模式，数据帧格式是“8位地址+数据”，跟普通存储芯片不太一样。读操作是先发一个字节的地址（最高位为1），然后继续发任意字节来收取数据；写操作则是先发地址（最高位为0），再发数据。很多人第一步就卡在这里，拿示波器一看发现地址对不上、数据全零，就是因为没有按这个帧格式来。
2. 硬件连接与信号完整性：最容易翻车的环节
2.1 引脚映射与电压匹配
STM32和MFRC522模块的连接方式，网上能搜到一堆图，但这里要重点强调两个问题：电平匹配和电源去耦。
MFRC522模块通常工作在3.3V，STM32的SPI引脚如果配置为复用推挽输出，也是3.3V电平，两者是兼容的。但如果你用的是5V供电的STM32开发板，或者某根线不小心接到了5V引脚上，MFRC522大概率当场烧掉。我做过一个项目，就是因为杜邦线插错，把3.3V供电的模块接到了5V，结果芯片直接烫手报废。
所以硬件连接之前务必确认：
- STM32的VDD是不是3.3V，模块供电是不是同一路电源；
- SPI引脚是否被复用，有没有被其它外设占用；
- 杜邦线连接是否牢固，SPI速率较高时杜邦线容易引入噪声。
MFRC522的最小连接一般需要7根线：3.3V、GND、RST、SCK、MOSI、MISO、NSS。其中RST是硬复位引脚，低电平有效。有些模块已经集成RC复位电路，但建议还是由STM32的GPIO控制，方便程序里做“上电后的软复位”。
2.2 上拉电阻和天线区域的布板细节
MFRC522模块的天线区域非常敏感，这是很多人忽略的。SPI的SCK和MOSI如果离天线太近，高频跳变信号容易耦合到天线上，直接影响读写距离和稳定性。我自己画过一版PCB，为了省空间把SPI走线贴着天线铜箔走，结果读卡距离从原来的4cm掉到不足1cm，后来重新布局之后才恢复。
如果你是用现成的MFRC522模块配合STM32开发板，那模块本身的天线布局已经定死了，主要注意的是模块与STM32之间的连线不要过长。实测下来，杜邦线超过20cm后，SPI波形明显出现振铃，读卡成功率大幅下降。建议控制在10cm以内，如果非得很长，可以适当降低SPI速率作为妥协。
MISO、MOSI、SCK的上拉电阻：MFRC522芯片内部已经配置了SPI引脚的上下拉，但模块厂家可能会在板上额外处理，所以一般不需要再外加上拉。但有一种情况例外：如果你用软件模拟SPI（GPIO翻转），MISO脚必须配置为上拉输入，否则读回来的数据不稳定。
2.3 硬件片选与软件片选：选哪个更稳
NSS片选脚有两种处理方式：硬件片选（把STM32的NSS引脚复用为SPI外设的硬件控制）和软件片选（任意GPIO手动拉低/拉高）。网上争论比较多，我实际使用下来的结论是：在MFRC522这个场景下，用软件片选更方便。
原因有两点：第一，MFRC522的SPI通信是按命令帧来切分的，每条命令都需要精确控制片选时序，软件片选更灵活；第二，如果你的SPI总线上还挂了其它设备，软件片选可以避免硬件NSS的自动控制逻辑冲突。硬件NSS一旦配置不好，会出现片选提前释放或者一直拉低的情况。
但软件片选也有讲究：在SPI写命令期间，NSS必须保持低电平，绝对不能中途释放。比如你要写一个寄存器，先写地址字节，再写数据字节，这两个字节之间NSS必须一直为低。有些人的程序里在每发送一个字节后都习惯性地释放一下NSS，读MFRC522就会出现“时好时坏”的诡异现象——因为芯片在片选释放的瞬间把当前命令丢弃了。
3. 软件初始化与驱动实现：从CubeMX到读卡成功
3.1 CubeMX配置要点和时钟计算
STM32CubeMX配置SPI不算复杂，但有几个参数对MFRC522来说必须严格注意。
先看SPI模式：全双工主机模式，8位数据帧，MSB先行。MFRC522不兼容Motorola帧格式，所以必须选SPI Mode 0（CPOL=0，CPHA=0）或者Mode 3（CPOL=1，CPHA=1）。具体用哪个要看模块的相位要求，绝大多数模块默认支持Mode 0，所以我统一用Mode 0。
然后是分频系数。我常用STM32F103C8T6，APB1时钟是36MHz，SPI1挂在APB2上，时钟是72MHz。72MHz的SCK如果分频不设置好，直接满速输出，MFRC522是接受不了的。手册上写的最高是10MHz，但实际工程中我建议保守一点，2MHz到5MHz之间最稳。CubeMX里的分频选项有2、4、8、16、32、64、128、256，对72MHz来说：
| 分频 | SCK实际频率 | 实测效果 |
|---|---|---|
| 2 | 36MHz | MFRC522无法响应 |
| 4 | 18MHz | 不稳定，偶尔能读，容易丢数据 |
| 8 | 9MHz | 能读，但长线场景下行风险高 |
| 16 | 4.5MHz | 稳定，推荐 |
| 32 | 2.25MHz | 很稳，但速率偏慢 |
| 64 | 1.125MHz | 很稳，仅用于调试 |
我自己项目里最终锁定的是4.5MHz这个档位，兼顾了吞吐量和信号完整性。如果现场环境电磁干扰较大，再降到2.25MHz也不迟。不要一味追求高SPI速率，MFRC522的射频读卡过程本身有等待时间，SPI再快也不会把读卡时间压缩多少，稳定才是第一位的。
软件片选时，CubeMX里把NSS引脚配置为GPIO输出即可，不需要选择“Hardware NSS”或“NSS Pulse”。需要说明的是，如果CubeMX自动生成的代码里SPI初始化结构体中NSS设置为SPI_NSS_Soft，那么你只需要把片选引脚当作普通GPIO来控制就行。
3.2 上电复位与唤醒时序
每次操作MFRC522之前，必须保证芯片处于正常的工作状态。很多例程里写了一个MFRC522_Init函数，里面的复位过程大致是：
- 把RST引脚拉低；
- 延时至少10ms（芯片内部复位）；
- 把RST引脚拉高；
- 再延时10ms到20ms；
- 写寄存器
CommandReg = 0x0F（软复位命令）； - 等待
CommandReg的bit4（RcvOff）清除，表示复位完成。
这套流程本身没问题，但踩坑往往在延时上。如果你用的延时函数不准确，比如HAL_Delay被中断频繁打断，或者RTOS环境下任务被抢占，会导致复位时间不够，芯片状态不对。我建议在MFRC522的复位函数里用硬件定时器做延时，或者至少保证复位期间没有高优先级中断在反复触发。
另外一个容易被忽略的操作：软复位之后要写一个关键寄存器TxModeReg（0x12）和RxModeReg（0x13），把发送和接收的模式配置成正确的帧格式。如果这两步漏了，读卡时会发现CRC一直校验错误。
3.3 读卡状态机的核心流程
MFRC522读卡的基本流程，就像跟卡“对话”一样，每一步都有严格顺序。以经典的MIFARE Classic 1K卡为例，读卡过程是：
- 发送
Request命令（PCD_Request），寻找天线场内的卡片； - 如果有卡回应，拿到卡的ATQA值；
- 发送
Anticollision命令（防碰撞），获取4字节的UID序列号； - 发送
Select命令，选中这张卡； - 之后就可以进行认证、读块、写块等操作。
在这整个过程中，每一步都要通过SPI向FIFODataReg写入命令字节，然后写CommandReg启动对应命令，再查询Status2Reg或FIFOLevelReg来判断是否完成。如果SPI通信有问题，最典型的现象就是某一步的返回值全是0xFF或者0x00，状态寄存器永远显示不正常。
关于命令帧，我贴一段简化后的写法（以HAL库为例）：
uint8_t MFRC522_WriteRegister(uint8_t reg, uint8_t value) { uint8_t tx_data[2]; tx_data[0] = (reg << 1) & 0x7E; // 写操作：地址左移一位，最高位为0 tx_data[1] = value; NFC_CS_LOW(); HAL_SPI_Transmit(&hspi1, tx_data, 2, 10); NFC_CS_HIGH(); return 0; } uint8_t MFRC522_ReadRegister(uint8_t reg) { uint8_t tx_data, rx_data; tx_data = ((reg << 1) & 0x7E) | 0x80; // 读操作：地址左移一位，最高位为1 NFC_CS_LOW(); HAL_SPI_Transmit(&hspi1, &tx_data, 1, 10); HAL_SPI_Receive(&hspi1, &rx_data, 1, 10); NFC_CS_HIGH(); return rx_data; }看到这里，有些人会问为什么地址要左移一位。因为MFRC522的SPI地址格式中，最低位是读写标志位。寄存器地址本身是7位有效，bit7是读写控制，所以实际发送的字节是“把寄存器地址放到高7位，最低位为读写方向”。这种细节一旦搞错，你写寄存器时实际上写到了别的地址，读出来的数据自然全乱。
HAL_SPI_Transmit和HAL_SPI_Receive分开调用其实是两次SPI事务，中间片选是拉高的。严格来说，读操作应该是“先发地址字节，然后持续给SCK收数据”的连续过程，片选不能释放。HAL库的方式在大多数情况下能用，但如果你要追求极致稳定，建议自己封装一个：
uint8_t MFRC522_ReadRegister(uint8_t reg) { uint8_t tx_data[2], rx_data[2]; tx_data[0] = ((reg << 1) & 0x7E) | 0x80; tx_data[1] = 0x00; NFC_CS_LOW(); HAL_SPI_TransmitReceive(&hspi1, tx_data, rx_data, 2, 10); NFC_CS_HIGH(); return rx_data[1]; }这样地址字节和数据字节在同一个CS低电平周期内完成，更符合MFRC522的时序要求。
4. SPI通信优化：从“能跑”到“跑得稳”
4.1 速率分级和稳定性取舍
SPI速率不是越高越好，尤其对MFRC522这种内部有射频模拟前端的芯片。除了前面表格里列的速率对比，还有一个因素是STM32的SPI外设在高速模式下的时序可能与芯片的采样点不完全匹配。我实测过，在9MHz下读UID偶尔成功、偶尔失败，用示波器看SCK和MISO的边沿关系，发现MFRC522返回的数据是在SCK下降沿附近变化，而STM32在Mode 0下是在上升沿采样，这个边沿如果错过了，就会采到不稳定的电平。
如果你坚持用较高的SPI速率，可以考虑一个变通方案：在主循环里对同一张卡连续读取多次，如果连续几次拿到的UID完全一致，则判定为有效。这个办法能掩盖一部分偶然性数据错误，但治标不治本，而且增加了系统开销。我的建议还是从根源上把SPI速率控制在4.5MHz以内。
4.2 DMA到底要不要用，看场景说话
STM32的SPI可以配合DMA收发数据，这在很多场景下能大幅降低CPU占用。但对MFRC522来说，DMA的价值并不是特别大，原因是每条命令的字节数很少（通常只有1到3个字节），DMA的初始化开销和中断开销占比反而更高。
我见过有人用SPI+DMA去读MFRC522的FIFO数据，一次DMA搬运几十个字节，表面上看CPU负担降低了，但实际上MFRC522的返回数据何时准备好，是可查询的。如果提前启动DMA，可能读到的是旧数据；等数据好了再启动DMA，又增加了延迟。所以对大多数单片机项目，直接轮询发送、查询状态反而更简单可靠。
但如果你的项目里MFRC522和显示、存储等其它外设同时工作，CPU主频又比较吃紧，可以考虑用中断方式而不是DMA。SPI中断的优先级设置在NFC通信期间要高于其它非紧急任务，避免读卡命令被调度延迟打断。我碰到过一个项目，在RTOS里把SPI中断优先级设置得比节拍定时器还低，结果每次任务切换后SPI发送就超时，换成高优先级后问题解决。
那什么情况下DMA值得用？如果你要连续读取MFRC522的大容量FIFO，比如做MIFARE卡的批量块读取，数据量比较大，DMA确实能减少逐字节查询的耗时。不过在这之前请确保SPI速率稳定、片选时序正确，否则DMA只会更快地把错误数据搬进内存。
4.3 超时和错误重试机制：程序健壮性的关键
很多人的MFRC522驱动里没有超时处理，读卡时一旦芯片没反应，程序就永远卡死在while循环里。这在正式项目里是大忌，因为现场环境不可能每次都能准时读卡。
正确的做法是给每一步操作都加上超时判断。以查询命令执行完成为例：
uint32_t timeout = HAL_GetTick(); while ((MFRC522_ReadRegister(Status2Reg) & 0x08) == 0) { if ((HAL_GetTick() - timeout) > 50) { return MFRC522_ERR_TIMEOUT; } }上面的0x08是Status2Reg的“缓冲中有数据”标志位，不同命令要等的位置不太一样。关键思路是：任何一次等待都不能是死等，超过一定时间就返回错误，然后由上层决定是重新发送命令还是重新复位芯片。
实际项目里我还会加一层“连续错误计数”逻辑：如果连续3次命令都超时或返回错误，就对MFRC522做一次完整的软复位，再重新初始化。这种机制比你无脑重发100次有效得多，因为很多问题是芯片进入了异常状态，必须复位后才能恢复。
另一个容易被忽略的细节是SPI错误标志的处理。HAL库里，如果SPI通信异常，hspi->ErrorCode会被置位，如果不手动清除，后续通信可能一直失败。建议在每次SPI传输前调用__HAL_SPI_CLEAR_OREFLAG之类的宏清除错误标志，或者直接调用HAL_SPI_Init重新初始化外设。
5. 常见问题与排查技巧实录
5.1 首次连接失败：先别急着改代码
如果你刚把MFRC522接好，发现不读卡、没反应，我强烈建议先做三板斧检查：
- 查供电：万用表量模块的3.3V引脚，电压低于3.0V或者波动太大，直接换电源再测；
- 查接线：SCK、MOSI、MISO、NSS四条线用通断档测一遍，杜邦线接触不良是非常常见的问题；
- 查SPI引脚复用：确认GPIO有没有被CubeMX初始化为别的功能。
这三步都过了还不行，再考虑软件问题。最有效的定位手段是拿一个逻辑分析仪或者示波器看SPI波形，重点看片选信号有没有正常拉低、SCK有没有时钟输出、MISO上有没有返回数据。如果你在发送读寄存器命令后，MISO一直保持高电平，说明MFRC522可能没进入SPI模式。
这里有一个冷知识：MFRC522在出厂时，SPI/I2C/UART模式是由引脚电平决定的。模块上通常已经把模式选择引脚接好了，但如果你的模块是散装芯片自己搭的，要检查EA引脚（SPI模式选择）是否拉高。EA=1时选择SPI模式，EA=0时选择I2C模式。我之前帮人排查过一个问题，他自己画板子时把EA引脚悬空了，结果芯片默认进了I2C模式，SPI怎么调都不通，拉高后立刻正常。
| 现象 | 可能原因 | 排查方法 |
|---|---|---|
| 上电后无任何反应 | 电源问题、RST未拉高 | 测量电压，检查复位引脚 |
| SPI读寄存器全FF | MISO没接对、芯片未进入SPI模式 | 测波形，检查EA引脚 |
| SPI读寄存器全00 | MOSI/SCK没接对、片选时序错 | 测波形，检查CS逻辑 |
| 能初始化但读不到卡 | 天线匹配问题、卡片类型不支持 | 检查天线区域，换MIFARE卡测试 |
| 时好时坏、偶尔失败 | 连线过长、SPI速率过高、电源纹波大 | 降速、缩短连线、加去耦电容 |
5.2 读卡距离短或读卡不稳定
MFRC522的有效读卡距离一般在4~6cm，但实际上很多DIY项目连2cm都不到。读卡距离短的原因主要有三类：
第一，天线阻抗不匹配。现成模块还好，如果你自己画天线，天线线圈的匝数、尺寸和匹配电容都影响发射功率。匹配电容的值通常在数据手册里有推荐，比如天线电感对应不同容值的电容，要按实测驻波来微调。没有网络分析仪的话，至少保证线圈形状规则、周围没有大的金属地平面。
第二，卡片类型不兼容。MFRC522只支持ISO/IEC 14443A，像MIFARE Classic、MIFARE Ultralight都在范围内，但MIFARE DESFire的某些型号或者纯NFC Type B卡，是读不了的。测试时尽量用最常见的MIFARE Classic 1K卡，也就是白色那种门禁卡。
第三，SPI通信虽然正常但状态错了。如果天线场没有正确打开，即使卡靠近也没反应。可以读一下TxControlReg寄存器，确认天线驱动位有没有置1。很多初始化代码里会把这个寄存器设置为0x83或者0x80，表示打开天线。如果这一步漏了，芯片只是“活着”，但根本没有能量场发出去。
实际测试中，我发现塑料卡套会明显影响读卡距离，尤其那种厚卡套，衰减有时达到30%以上。如果现场必须隔着卡套读卡，建议把卡片放平、尽量贴近读取区域，然后软件上适当增加轮询重试的次数。
5.3 和同一SPI总线上其它设备共存
如果你的STM32 SPI1上还接了OLED、Flash、SD卡之类的设备，MFRC522和其它设备共用SCK/MOSI/MISO，每个设备只有一个独立的片选脚。这种方案在原理上可行，但要注意几点：
- 不同设备对SPI模式的要求可能不同。OLED驱动芯片比如SSD1306，通常也支持Mode 0，所以可以和MFRC522共用；但SD卡在某些初始化阶段要求Mode 0，读数据时又切到Mode 3，这种切换MFRC522吃不消。建议把要求模式不同的设备拆到不同的SPI总线上。
- MISO是共享线，每个设备在不被选中时，必须让MISO处于高阻态。MFRC522的MISO引脚在片选拉高后是高阻状态，但有些芯片不是这样。如果其它设备在片选释放后仍然驱动MISO，会直接干扰MFRC522的读操作。
- 切换设备之后，要确保当前设备的片选时序完全干净。很多人在代码里快速切换两个设备的CS，没有留出足够的时间间隔，导致SCK上残留了几个时钟，让MFRC522误解。
如果你实在需要共用一个SPI总线，我建议这样处理：在每次切换设备后，先发送一个空操作，把SPI外设的移位寄存器清干净，再开始正式通信。这招对大多数SPI从设备都管用。
5.4 Keil调试时遇到“硬件错误”和延时卡死
这个坑不算MFRC522独有，但经常在调MFRC522项目时集中爆发。现象是程序跑到某个延时函数后突然跳到HardFault_Handler，或者HAL_Delay卡死。
最常见的原因有两个：一是中断优先级配置不当，导致SysTick中断被更高优先级的外设中断阻塞，HAL_GetTick不再更新，所有依赖它的延时全部失效；二是初始化顺序问题，比如在CubeMX生成的HAL_Init之前就调用了HAL_Delay。正确做法是确保HAL_Init和SystemClock_Config先执行，再跑MFRC522的初始化代码。
另外，如果你在定时器中断里做了比较重的任务，频繁打断SPI通信，也会导致MFRC522的命令超时。解决办法是把中断频率降低，或者在SPI传输期间临时挂起非关键中断。我做过一个电子锁项目，屏幕刷新用定时器每10ms刷一次，结果刷屏期间刚好赶上读卡命令，读卡成功率掉了一半。后来把刷屏放到主循环、读卡用中断驱动，问题才解决。
6. 一些用血泪换来的心得体会
调MFRC522的SPI通信，说难不难，但细节特别多。最终把项目稳定交付之后，回头总结最值得记住的几条：第一，SPI速率先保守再激进，能4.5MHz跑通就别上9MHz，现场环境永远比实验室复杂；第二，片选时序是生命线，保证每一条命令都在一段干净的CS低电平里完成；第三，所有等待必须有超时，不要让程序死等在MFRC522上；第四，遇到疑难杂症先查硬件波形，再翻代码逻辑，不要一天到晚怀疑芯片配置。
我后来做其它NFC相关项目，比如把MFRC522接在ESP8266上做DIY门禁（虽然ESP8266也能软件模拟SPI，但稳定性远不如硬件SPI），最终又回到了“硬件SPI+4MHz左右速率+严格片选时序”这套方案上。如果你也准备把MFRC522用在量产或者长期运行的项目上，请务必在硬件设计阶段就考虑天线走线、电源去耦和MCU引脚分配，不要指望软件能弥补硬件的先天缺陷。
最后再免费送一个小技巧：在调试MFRC522时，可以在SPI数据接收之后打印一个调试计数，统计错误字节的比例。如果你发现500次通信里有2~3次数据异常，先不要急着加纠错算法，回到硬件上找原因，这才是治本的路子。
