STM32驱动PN532串口读卡完整指南：从HSU协议到UID解析

简介：面向STM32嵌入式开发者的NFC驱动资源包，以PN532串口驱动为核心，讲解在STM32上实现NFC标签读写的方法。内容涵盖UART引脚选择（如PA9/PA10）、115200bps波特率配置、PN532初始化命令、标准帧结构解析、NDEF数据读写流程以及中断驱动优化；并配有基于STM32F103C8T6与HAL库的示例工程，可直接移植到物联网、移动支付、智能门禁等场景。资源共211个文件，以43个h头文件、41个c源文件及32个s汇编文件为主体，另含工程配置文件、链接脚本、编译产物和少量文档，压缩包约3.7MB，目录结构清晰，便于按模块查看驱动实现与协议封装。已有1804人学习下载。读者可获得可编译的驱动模板、关键数据帧说明及排错思路，减少底层协议开发与调试时间。

1. 这个驱动解决什么问题：串口接PN532为什么不能直接读卡

刚接触STM32和PN532的时候，几乎所有人都会干一件“理所当然”的事：把模块的TXD、RXD直接接到串口上，然后往串口丢一串ASCII命令，指望卡贴上去就能读到卡号。结果往往是串口助手一片空白，或者收到一堆乱码。原因是PN532的串口不是那种“发AT指令”的普通串口，它跑的是HSU协议——所有数据都要按专用帧格式打包，还要先给芯片做SAMConfig配置，它才愿意进入寻卡模式。这套STM32的PN532串口驱动，就是把“组帧、校验、发命令、等待ACK、解析响应”这些脏活全封装好的落地工程。

它的核心能力一句话概括：把PN532接到STM32的任意一个USART上，调用几个API就能完成初始化、寻卡、读UID，并且留好了往Mifare数据块读写、NDEF文本解析方向扩展的接口。适合三类人：正在做门禁/读卡器/智能硬件原型的嵌入式开发者、手头有PN532模块但一直卡在协议细节上的初学者、以及想在项目里快速集成NFC但不想从零啃数据手册的人。

2. 协议与架构：PN532 HSU帧格式与驱动分层设计

2.1 HSU串口协议：每个字节都是算出来的

PN532在HSU模式下默认波特率为115200，8N1，空闲时TXD输出高电平。看起来和普通串口没有任何区别，但通信内容完全不同。主机发给PN532的任何一条指令，都必须按下面的帧结构组织：

举个例子，读固件版本命令GET_FIRMWARE_VERSION的指令码是0x02，没有参数。完整发送帧是00 00 FF 03 FD D4 02 FC。其中LEN=0x03是因为数据区包含D4、02两个字节，但LEN本身不算自身，只算它后面的数据字节数，所以是2个数据字节加1个TFI？这里要特别注意，PN532数据手册里的LEN指的是“从TFI开始到最后一个数据字节的字节数”，也就是说D4、指令、参数都在内，共3个字节，所以LEN=0x03，LCS=0xFD。DCS则是对0xD4和0x02求和取补码，0x100-(0xD4+0x02)=0x100-0xD6=0x2A？不对，我重新算一下。0xD4+0x02=0xD6，0x100-0xD6=0x2A。所以完整帧应该是00 00 FF 03 FD D4 02 2A。但是网上很多参考帧写的是00 00 FF 03 FD D4 02 2A，有一部分人写错了，写成了FC，原因就是把LEN错算成2。按这个帧发出去，PN532也会回ACK，但它会认为帧校验失败而丢弃命令。要验证你的计算对不对，最直接的办法是把帧扔进串口调试助手发给PN532，看它回什么——只要回的是00 00 FF 00 FF 00这种ACK帧，说明帧格式对了一半。

PN532的通信流程是固定的两步：主机发命令帧 → PN532回一个ACK帧表示“收到” → 再回真正的响应帧。ACK帧是固定的6个字节00 00 FF 00 FF 00，没有长度校验和数据校验，因为它是个特殊帧。真正的响应帧结构和请求帧一样，只是TFI变成了0xD5。这个“先ACK再响应”的时序是新手最容易翻车的地方：很多人发了命令就去读串口，结果读到了ACK就以为收到响应了，然后解析出错。

2.2 驱动分层：把协议细节和业务逻辑分开

这套工程在结构上明确分成了三层，目的很实际：以后换了I2C或SPI接口的PN532，或者从HAL库换成标准外设库，都只需要改最底下那层，上面的命令层和应用层一行不动。

命令层是整个驱动的核心，它不关心命令拿去干什么，只负责保证“发出去的帧一定合法，收回来的帧一定被校验过”。应用层则是在命令层基础上做场景封装，比如“上电后初始化NFC”“循环寻卡并把UID打印到串口”，这种代码普通人一读就懂。完整目录结构如下：

project ├─ Core/ │ ├─ main.c │ └─ stm32f1xx_it.c ├─ Drivers/ │ └─ STM32F1xx_HAL_Driver/ ├─ BSP/ │ ├─ pn532.h │ ├─ pn532.c │ ├─ pn532_uart.h │ └─ pn532_uart.c └─ App/ ├─ app_nfc.h ├─ app_nfc.c └─ ndef_parser.c

从依赖关系看，app_nfc.c只调用pn532.h里暴露的API，pn532.c只调用pn532_uart.h里的串口收发函数。这样各层之间是单向依赖，不会出现应用层直接操作寄存器的情况。对于想二次开发的人来说，只需要看懂pn532.c里的3个核心函数，整条NFC链路就通了。

3. 核心代码拆解：从串口发帧到读回UID的完整链路

3.1 发帧封装：组帧、校验、发送一气呵成

所有发给PN532的命令，最终都汇聚到这一个函数。它的输入是命令码和参数数组，函数内部完成LEN、LCS、DCS的计算，最后通过HAL串口发出去。代码如下：

uint8_t PN532_SendCommand(uint8_t cmd, uint8_t *params, uint8_t param_len) { uint8_t frame[258]; uint8_t data_len = param_len + 2; // TFI + cmd + params uint8_t total_len = data_len + 5; // 前导 + 起始 + LEN + LCS + DCS uint8_t dcs = 0xD4 + cmd; frame[0] = 0x00; // 前导码 frame[1] = 0xFF; // 起始码 frame[2] = data_len; // 数据区长度 frame[3] = 0x100 - data_len; // 长度校验 frame[4] = 0xD4; // 主机发往PN532的TFI frame[5] = cmd; // 指令码 if (params != NULL && param_len > 0) { memcpy(&frame[6], params, param_len); for (uint8_t i = 0; i < param_len; i++) { dcs += params[i]; } } frame[total_len - 1] = 0x100 - dcs; // 数据校验 HAL_UART_Transmit(&huart1, frame, total_len, 100); return PN532_STATUS_OK; }

注意data_len = param_len + 2，这2个字节就是TFI和指令码。LCS不是对整个帧求和，而是对LEN本身求补，所以即使前面帧头写错了，只要LEN和LCS不匹配，PN532就会把整帧丢弃。DCS是对TFI、指令码、所有参数加起来求补，注意它不包含LEN和LCS，很多参考代码在这里有误导。

这个函数的参数很好理解：cmd是PN532的指令宏，比如PN532_CMD_SAMCONFIG是0x14，PN532_CMD_INLISTPASSIVETARGET是0x4A；params是命令参数的首地址；param_len是参数个数。使用时的常见坑是忘记把数组长度和实际参数个数对齐，多传一个0x00或少传一个0x00都会导致LEN变长或变短，PN532直接不回帧。

3.2 接收响应：先吃ACK再吃响应帧

发送只是前半程，接收才是判断命令是否成功的依据。接收函数的处理逻辑是：发送完成后，先收6字节的ACK帧，跳过它，然后再收真正的响应帧头，接着根据帧头里的LEN收完剩余数据，最后做一遍DCS校验。代码如下：

static uint8_t PN532_ReadResponse(uint8_t *resp, uint8_t *resp_len) { uint8_t header[6]; uint8_t frame[260]; uint8_t data_len; uint8_t sum = 0; // 第一步：收ACK帧 00 00 FF 00 FF 00 HAL_UART_Receive(&huart1, header, 6, 1000); if (header[0] != 0x00 || header[1] != 0x00 || header[2] != 0xFF || header[3] != 0x00) { return PN532_STATUS_ERR_ACK; } // 第二步：收响应帧头 00 00 FF LEN LCS HAL_UART_Receive(&huart1, header, 5, 1000); if (header[0] != 0x00 || header[1] != 0x00 || header[2] != 0xFF) { return PN532_STATUS_ERR_FRAME; } data_len = header[3]; if (header[4] != (0x100 - data_len)) { return PN532_STATUS_ERR_CHKSUM; } // 第三步：收数据区 + DCS HAL_UART_Receive(&huart1, frame, data_len + 1, 1000); for (uint8_t i = 0; i < data_len; i++) { sum += frame[i]; } sum += frame[data_len]; // 加上DCS if ((sum & 0xFF) != 0x00) { return PN532_STATUS_ERR_CHKSUM; } memcpy(resp, frame, data_len); *resp_len = data_len; return PN532_STATUS_OK; }

这个函数里有几个值得细看的点。第一，ACK帧的校验只检查前4个字节，因为后面FF 00是固定的确认序列，如果前4字节匹配基本可以认定是ACK；第二，响应帧头收了5字节，也就是00 00 FF LEN LCS，这里LEN才是真正要紧的，它决定了后面还要收多少数据；第三，DCS的验算用了一个技巧——把数据区所有字节和DCS求和，正确结果应该等于0x100的整数倍，也就是低8位为0x00，不用再做减法。

有人会问，如果PN532发命令后板子响应太慢，HAL_UART_Receive超时1000ms够不够？实际测试下来，PN532对绝大多数指令的响应时间在10ms以内，只有寻卡命令在卡片不在场时会等到自己内部超时才回帧，这个超时时间由SAMConfig的timeout参数决定，默认1秒。所以接收超时设在1000ms是合理的，短时间内不会误判。

3.3 SAMConfig初始化：让PN532进入正常工作模式

PN532上电后默认处于待机状态，必须发送SAMConfig命令它才进入配置好的工作模式。SAMConfig的指令码是0x14，参数固定为3个字节。代码如下：

uint8_t PN532_SAMConfig(uint8_t mode, uint8_t timeout, uint8_t irq_en) { uint8_t params[3]; uint8_t resp[32]; uint8_t resp_len; params[0] = mode; // 0x01: 正常模式, 0x02: 虚拟卡模式 params[1] = timeout; // 超时时间, 单位 50ms params[2] = irq_en; // IRQ引脚中断使能 if (PN532_SendCommand(PN532_CMD_SAMCONFIG, params, 3) != PN532_STATUS_OK) { return PN532_STATUS_ERR_SEND; } if (PN532_ReadResponse(resp, &resp_len) != PN532_STATUS_OK) { return PN532_STATUS_ERR_RECV; } // 响应数据区第一个字节是0x15表示成功 if (resp[0] != PN532_CMD_SAMCONFIG + 1) { return PN532_STATUS_ERR_NACK; } return PN532_STATUS_OK; }

很多人在这个环节把mode填成0x02，然后发现PN532可以被手机读到、却读不到自己的卡——因为0x02是让PN532模拟一张NFC卡，而不是读卡。正常读卡场景必须填0x01。timeout填0x14，即20个50ms，总共1秒，含义是“寻卡等待超过1秒就返回超时”。IRQ使能这里填0x01，让PN532通过IRQ引脚告诉主机“有响应了”，如果没接IRQ引脚填0x00也行，但要注意读卡响应只能靠串口数据判断。

3.4 寻卡与读UID：InListPassiveTarget完整流程

寻卡指令InListPassiveTarget的命令码是0x4A，参数通常是两个字节：MaxTg=1和BaudRate=0。其中BaudRate为0表示106kbps的NFC-A协议，也就是Mifare Classic和Mifare Ultralight这类最常见的卡。完整代码如下：

uint8_t PN532_InListPassiveTarget(uint8_t *uid, uint8_t *uid_len) { uint8_t params[2] = {0x01, 0x00}; uint8_t resp[64]; uint8_t resp_len; if (PN532_SendCommand(PN532_CMD_INLISTPASSIVETARGET, params, 2) != PN532_STATUS_OK) { return PN532_STATUS_ERR_SEND; } if (PN532_ReadResponse(resp, &resp_len) != PN532_STATUS_OK) { return PN532_STATUS_ERR_RECV; } // 响应格式：D5 4B nbTg Tg ATQA_H ATQA_L SAK UIDlen UID... if (resp[0] != 0xD5 || resp[1] != 0x4B) { return PN532_STATUS_ERR_NACK; } if (resp[2] == 0x00) { return PN532_STATUS_ERR_NOTAG; // 没读到卡 } *uid_len = resp[7]; memcpy(uid, &resp[8], *uid_len); return PN532_STATUS_OK; }

响应帧的解析是整个驱动里最容易算错偏移的地方。响应数据区从resp[0]开始依次是D5 4B nbTg Tg ATQA_H ATQA_L SAK UIDlen UID...。其中resp[2]是找到的目标数量，为0说明没有卡；resp[7]是UID长度，通常是4字节或7字节；UID本体从resp[8]开始。如果代码里写的是resp[6]或者resp[5]，拿到的就是错的UID——这个坑相当隐蔽，因为有时候UID恰好只有4字节，错一位可能也能对上，但换了7字节的卡就全乱了。

4. 环境搭建：CubeMX接线、配置与串口验证

4.1 硬件接线与电平匹配

PN532模块的引脚功能在串口模式下非常简单，但有一个地方必须注意：模块的TXD、RXD是3.3V TTL电平，和STM32的USART引脚电平是一致的，可以直接互联。不过市面上存在两种常见的PN532模块，红色模块带5V稳压芯片，白色模块是3.3V直供，两者串口逻辑电平都是3.3V，直接接STM32没有风险。真正需要警惕的是那些把电平转换芯片焊在板子上的模块，如果模块上有SP232E之类的芯片，串口引脚可能是RS232电平，就不能直连。以下是标准接线表：

重点说下CTS这根线。PN532的HSU模式默认启用硬件流控，CTS输入为低时芯片才允许发送数据。如果模块上的CTS悬空，内部上拉会让它处于高电平，PN532就一直不往外发数据，表现就是“主机发命令没反应，但模块好像也活着”。解决方法是把CTS接到STM32任意一个GPIO，配置为推挽输出并置低，或者直接在模块侧把CTS和GND短接。RTS是输出信号，可以留着不接。

4.2 CubeMX串口配置要点

STM32CubeMX里只需要配置一个USART，参数按下面设置：

• 模式：Asynchronous
• 波特率：115200
• 字长：8 Bit
• 校验：None
• 停止位：1 Bit
• 方向：TX和RX都使能

PB0和PB1配置为GPIO_Output，初始化时PB0输出高电平让PN532退出复位，PB1输出低电平让PN532的CTS有效。生成代码后，在main函数里加初始化调用：

int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_USART1_UART_Init(); // 释放PN532复位：拉高RSTO HAL_GPIO_WritePin(GPIOB, GPIO_PIN_0, GPIO_PIN_SET); HAL_Delay(500); // NFC初始化：进入正常读卡模式 PN532_SAMConfig(0x01, 0x14, 0x01); while (1) { uint8_t uid[8]; uint8_t uid_len = 0; if (PN532_InListPassiveTarget(uid, &uid_len) == PN532_STATUS_OK) { printf("UID[%d]: ", uid_len); for (uint8_t i = 0; i < uid_len; i++) { printf("%02X ", uid[i]); } printf("\r\n"); HAL_Delay(500); // 防止连续读同一张卡刷屏 } HAL_Delay(100); } }

这段代码就是整个工程的骨架：上电先把PN532从复位状态释放，等500ms让它内部固件跑起来，然后SAMConfig进入正常模式，主循环里反复寻卡。HAL_Delay(500)放500ms是为了避免卡一直贴在读写器上时程序疯狂刷日志，这个时间按业务需求随意调。

4.3 用PC串口助手验证模块好坏

如果你发现板子读卡没反应，第一步不是查代码，而是先确认PN532模块本身是好的。把模块的TXD、RXD用USB转串口接到PC，打开串口助手，波特率115200，用HEX发送模式，先发送一帧唤醒帧：55 55 00 00 00 00。注意，PN532在HSU模式下有个特殊行为：连续收到4个以上的0x00会唤醒它。但这帧不是标准命令，发送后PC端不需要期待ACK。

真正的验证是发固件版本命令，发送HEX帧：

00 00 FF 03 FD D4 02 2A

如果模块正常，PC串口助手会先收到00 00 FF 00 FF 00的ACK帧，然后收到响应帧00 00 FF 05 FB D5 03 02 00 06 07。响应帧里D5 03表示“响应的是GET_FIRMWARE_VERSION命令”，后面02 00 06 07是固件信息。如果你收到的是00 00 FF 01 FF D5 03 73之类的NACK帧，说明命令没被正确解析，多半是帧校验码算错了。

用PC验证的好处是把问题边界划清楚：模块没问题，再回头看STM32的串口配置；模块没响应，基本就是接线或供电问题。这套排查顺序能让调试时间省一半。

5. 踩坑排查：5个导致读不到卡的真问题

5.1 上电就发命令，模块完全没有反应

现象：STM32上电后立刻调用PN532_SAMConfig，回包超时，模块指示灯不亮或闪烁异常。

原因：PN532的复位脚RSTO如果悬空，芯片可能一直处于复位态，或者刚从复位释放但内部LDO还没稳定，此时任何串口命令都会被丢弃。很多模块的原理图上RSTO是有上拉电阻的，但如果你用杜邦线连接RSTO到PB0，且PB0初始化时输出低电平，等于把模块按在复位状态。

解决：PB0在初始化阶段先输出低电平，等STM32和串口外设都初始化完成后，再把PB0拉高并延时至少500ms。我一般会拉到1秒，让模块的晶振和内部锁相环完全稳定。从那以后，我接所有NFC模块第一件事就是确认复位引脚的GPIO初值。

5.2 能发命令但收不到ACK，串口示波器能看到波形

现象：用逻辑分析仪抓TXD引脚，能抓到STM32发出的完整帧，但RX引脚一直收不到任何数据。

原因：CTS引脚悬空导致PN532的发送被硬件流控卡死。PN532的HSU默认启用流控，它的CTS输入悬空时内部下拉？实际上很多模块的CTS脚内部没有上下拉，悬空状态不确定，PN532会认为主机未就绪。

解决：把CTS引脚用杜邦线接到GND，或者在CubeMX里配一个GPIO输出低电平接到CTS。如果你用的模块是成品板，板上已经把CTS和GND短接，那这个坑就不会出现。判断方法很简单：用万用表量CTS对GND的电压，如果接近0V就是被拉低了，如果悬空就要手动处理。

5.3 寻卡响应一直是0个目标，但PC端验证模块是好的

现象：固件版本命令能正常响应，SAMConfig也返回成功，但InListPassiveTarget永远返回PN532_STATUS_ERR_NOTAG。

原因：最可能的情况是SAMConfig的mode被填成了0x02。0x02是虚拟卡模式，PN532把自己模拟成一张卡，所以它不会主动寻卡。另一个可能原因是天线线圈没有调谐，卡贴得再近也耦合不到能量。

解决：确认SAMConfig的第一个参数是0x01。如果参数没问题，换一张Mifare Ultralight或者Mifare Classic测试，因为InListPassiveTarget的BaudRate=0只覆盖Type A协议，如果你拿的是Type B的身份证卡，它当然读不到。

5.4 能读到UID，但偶尔读到的UID是乱的

现象：同一张卡反复放上去，大部分时间读到正确UID，偶尔读出来少一个字节或者多两个字节，有时是FF FF FF FF这种非法值。

原因：多半是串口接收和命令发送的竞态问题。当前代码是阻塞式收发，如果主循环里寻卡指令刚发出去，PN532的ACK还没回来，这时候系统又发了一条新指令，会把PN532的状态机搞乱。

解决：给接收加上帧同步逻辑，读到非法帧头就丢弃并重新等待，而不是直接把错误帧返回给上层。更彻底的办法是给PN532的命令发送加一个互斥锁，在响应超时之前不允许再次发送。我在这个工程里用了一个简单的busy标志位，发送前检查，响应完成后才清除。

5.5 连续读卡几次后模块彻底死机，必须断电恢复

现象：读卡前几次正常，第5次或第10次开始无响应，看门狗也没用，只能断电重启。

原因：NFC协议规定，主机在读完卡数据后要主动释放目标。如果每次寻卡成功但没有对卡片做释放操作，PN532会把目标保持在激活状态，内部缓冲区占满后状态机崩溃。

解决：在读完UID或数据后，调用InRelease命令（指令码0x52）释放目标：

uint8_t PN532_InRelease(uint8_t tg) { uint8_t params[1] = {tg}; // 目标编号，通常为0x01 uint8_t resp[16]; uint8_t resp_len; PN532_SendCommand(0x52, params, 1); PN532_ReadResponse(resp, &resp_len); return resp[0] == 0x53 ? PN532_STATUS_OK : PN532_STATUS_ERR_NACK; }

这段代码的坑在于NFC-A目标释放后，PN532返回的响应数据区是D5 53，如果你的判断条件写错，会以为释放失败，但实际已经释放了。另外，如果卡片是被强制拿开的，PN532内部也会自动检测到场强消失并清理目标，所以这个释放不是每次都必须调用，但养成习惯能避免上面的死机问题。

6. 二次开发思路：从读卡号到读写卡片数据块

6.1 把命令层从读UID扩展到Mifare数据读写

读UID只是NFC的最表层，很多实际场景需要进一步读写卡内的数据块。Mifare Classic的数据读写走的是InDataExchange命令，指令码0x40。它和寻卡命令的区别是：必须先通过InListPassiveTarget找到一个目标，然后针对这个目标交换数据。Mifare Classic的认证命令是：

uint8_t PN532_MifareAuth(uint8_t block, uint8_t key_type, uint8_t *key) { uint8_t params[16]; uint8_t resp[32]; uint8_t resp_len; params[0] = 0x01; // 目标编号 params[1] = key_type ? 0x61 : 0x60; // 0x60=A密钥, 0x61=B密钥 params[2] = block; // 要认证的块号 memcpy(&params[3], key, 6); // 6字节密钥 PN532_SendCommand(0x40, params, 9); PN532_ReadResponse(resp, &resp_len); return resp[2] == 0x00 ? PN532_STATUS_OK : PN532_STATUS_ERR_AUTH; }

注意这里InDataExchange的数据区比之前的命令多了目标编号Tg，而且响应数据区的前两个字节是D5 41，第三个字节才是状态字。这个状态字等于0x00才表示认证通过，常见值是0x01表示密钥错误，0x02表示块号不存在。认证通过后，读块数据就是把参数换成{0x01, 0x30, block}，响应区从第三个字节开始就是16字节的块数据。

6.2 NDEF文本解析：往应用层挂一个轻量解析器

Mifare Classic的NDEF文本通常从块4开始，块的前4字节或第1字节是TLV结构标记。解析逻辑很简单：读块4，检查0x03开头的TLV标志位，接着读长度字节，最后把后面的内容按Text记录格式拆出来。我通常会在ndef_parser.c里放一个专门处理NDEF文本的轻量函数，只提取第一条Text Record的UTF-8内容，不做通用NDEF框架。因为电子的项目里百分之八十的需求只是“刷一下卡把字符串读出来”，通用解析器反而增加代码体积和调试成本。

6.3 把阻塞式收发换成中断加状态机

当前驱动用HAL_UART_Transmit和HAL_UART_Receive，在单任务场景下完全够用。但如果你要同时驱动蜂鸣器、数码管甚至蓝牙模块，阻塞式串口会把CPU卡死。我一般的改造套路：发送仍然用阻塞式（命令很短，微秒级），接收改成HAL_UART_Receive_IT配合一个环形缓冲区，在串口中断里把字节塞进队列，命令层从队列里按帧同步解析。这样寻卡期间主循环还能做别的事，响应速度快不少，卡顿感几乎消失。

给新手一个忠告：别一上来就追求非阻塞，先把阻塞式整个链路跑通，再动接收方式。我当年就是直接上手DMA，结果帧边界怎么都对齐不了，最后反过头来用阻塞式逐字节调试才找到问题——从那以后，每次换新NFC模块，我都先用最笨的方式验证硬件链路，再考虑性能优化。希望帮到你。

本文还有配套的精品资源，点击获取