Zynq平台AXI UART Lite配置、驱动与调试实践

做 Zynq 项目的人大多有过这么一段经历PS 端的调试串口已经被命令行、日志、shell 占得满满当当突然还要接一个 GPS 模块、一个扫码枪、一路和外部 MCU 的私有协议或者干脆是想在 PL 侧留一路独立的调试输出口。这时候抬头一看PS 的 UART 就两路一路还已经被占用于是目光就落到了 IP 目录里那个不起眼的AXI UART Lite上。它的确简单四个寄存器、十六字节 FIFO、一个中断输出看起来是入门级外设但真上手调的时候乱码、丢字节、中断进不来、数据发出去对方没反应问题一个接一个往外冒。这篇就把我在 Zynq 平台上折腾 AXI UART Lite 的全过程摊开讲从选型判断、IP 参数、寄存器行为到接线、驱动、回环验证和现场排查尽量把每一个为什么这么设都说透让刚接触 PL 外设的读者也能照着走一遍。1. 先把选型说清楚UART Lite 在 Zynq 里到底站什么位置1.1 PS 硬串口和 PL 软串口的真实差距很多人第一反应是有 PS 串口为什么还要用 PL 的。这个问题必须先回答清楚否则后面调通了也会用错地方。PS 端那两路 UART 是硬核带独立的波特率发生器、可编程的 FIFO 深度一般能到 64 字节、支持硬件流控 RTS/CTS、支持 modem 控制信号、支持 IrDA 和自动流控波特率可以跑到很高而且收发都能挂 DMACPU 几乎不参与。它的问题是数量固定就两路引脚也是固定的 MIO 或者通过 EMIO 引到 PL。AXI UART Lite 完全是另一套逻辑。它是纯逻辑实现的轻量外设挂在 AXI4-Lite 总线上CPU 每收发一个字节基本都要发起一次 32 位读写事务没有 DMA 通道没有硬件流控引脚波特率在综合之前就被定死运行期改不了收发 FIFO 各 16 字节。听起来处处不如人但它有一个无可替代的优势数量自由、位置自由、引脚自由。你想挂八路就例化八路想把这路串口引到任意一个 PL 引脚上就引到任意一个引脚甚至可以把 TX/RX 通过板内走线接到另一个芯片的固定管脚上完全不受 MIO 分配表约束。所以判断标准其实很朴素如果这路串口是给人看的调试口、是低速率115200 及以下、是偶发的短报文交互UART Lite 完全够用而且成本极低如果这路串口要跑 1Mbps 以上、要连续传几 MB 的固件、要做硬件流控防止对端缓冲区爆掉那就别硬上 UART Lite老老实实把 PS UART 腾出来或者用 EMIO 把 PS UART 引到 PL 引脚上性能上差着一个数量级。我还遇到过一个更微妙的场景某项目需要在 PL 侧做一个独立的小状态机这个状态机本身要往外吐调试信息但又不想每次都打断 PS 的 CPU 去处理。这种情况下 UART Lite 反而是好选择因为它的发送只依赖 AXI 总线写操作逻辑侧可以直接挂一个 AXI 主设备或者干脆用 AXI-Stream 转 AXI-Lite 的桥让数据通路自己走PS 侧完全不感知。1.2 什么场景值得多挂一个 UART Lite列举几个我实际做过、也确实跑通了的用法供参考对照。第一类是多路低速采集。某采集板要同时接四路相同的传感器模块每路都是 9600 波特率的问答式协议总共四路 UART Lite 挂在一个 AXI Interconnect 上PS 侧用轮询加状态机轮转处理CPU 占用率低得可以忽略因为每路每秒也就几十个字节。第二类是隔离调试口。主调试口接的是 PS UART用来跑命令行和打印系统日志。但有时候系统会跑飞、PS 侧的中断被关掉这时候如果 PL 侧还有一路独立的 UART Lite就能从逻辑里直接吐心跳或者关键状态位不依赖 PS 的软件状态排查死机问题极其好用。我一般会在 PL 里做一个简单的定时器加 UART Lite周期性输出一个递增计数器和几个关键寄存器快照只要这路还在动就说明 PL 时钟和逻辑没死问题一定在 PS 软件侧。第三类是与外部 MCU 的板内通信。两块芯片在同一块板子上距离几厘米电气环境干净不需要隔离也不需要长线驱动直接用 TTL 电平对接波特率 115200报文短小固定用 UART Lite 是最省事的方案还省下了宝贵的 PS MIO 引脚。第四类是协议转换或者旁路监听。把外部进来的串口数据先接到 UART Lite 的 RX 上PS 读到之后做协议解析、格式转换、加密或者打时间戳再从另一个 UART Lite 的 TX 发出去。这种串口进、串口出的旁路结构用 PL 侧外设做起来非常自然因为两路完全独立互不干扰。需要提醒的是UART Lite 在 Vivado 的 IP 目录里有免费版和需要授权的版本区别吗没有它属于免费 IP任何版本的开发工具都能直接例化这一点对小团队和教学场景很友好。但免费不代表没成本它的资源占用虽然小几十个 LUT 加几个触发器可每一路都要占一个 AXI 从设备地址空间地址译码和 Interconnect 的端口数会跟着涨八路以上就要考虑用 AXI SmartConnect 或者做地址分段否则布线会很痛苦。2. IP 配置阶段的三个参数配错了后面全白干2.1 波特率不是运行期配出来的是综合之前算出来的这是新手最容易栽的第一个坑。PS 端 UART 的波特率是运行时写寄存器算出来的你想改成 9600 就改成 9600。AXI UART Lite 完全不是这个逻辑它的分频系数在 IP 配置界面的那一刻就已经被固化成常数烧进 bitstream运行期没有任何寄存器能改它。你在配置界面里填的Clock Frequency和Baud Rate这两个值工具会拿去做一次除法算出一个整数分频比然后把结果硬编码到逻辑里。具体算法是 16 倍过采样分频系数等于时钟频率除以16 乘以目标波特率结果取整。举个实际数字AXI 时钟配 100MHz目标波特率 115200那么 100000000 / (16 × 115200) 54.25取整得 54。反算实际波特率是 100000000 / (16 × 54) 115740相对误差 0.47%。这个误差在 UART 协议能容忍的范围之内一般要求总误差小于 2% 到 3%因为收发双方都有误差还要算上采样点偏移实际通信是稳的。但如果时钟填错了呢比如实际 AXI 时钟是 50MHz你在 IP 里填了 100MHz工具按 100MHz 算出分频 54实际跑起来波特率就只有 57870正好是目标值的一半接收方看到的全是乱码或者帧错误。这个错误特别隐蔽因为编译不报错、综合不报错、时序也可能过就是通信不通。我见过有人在这个问题上耗了两天最后发现是 IP 配置界面的时钟频率抄错了。所以我的习惯是先确定 AXI 时钟频率再打开 IP 配置且这个数字必须和时钟约束文件、和 PS 侧 FCLK 的实际输出频率三方一致。Zynq 的 FCLK 是可以在 PS 配置里设的常见的有 50MHz、100MHz、150MHz设置完之后要记得在 IP 的时钟频率栏里同步改过来不要用默认值。还有一点如果目标波特率很低比如 9600分频系数会很大100MHz 下是 651这没问题但如果目标波特率很高分频系数会很小小到一定程度就没有余量了。理论上限大致是时钟频率除以 16100MHz 时钟下理论最高 6.25Mbps但实际因为每个字节都要走一次 AXI 事务CPU 根本喂不过来所以别指望跑那么高。2.2 时钟连错后面所有调试都是徒劳AXI UART Lite 只有一个时钟输入就是 s_axi_aclk它既是总线时钟也是串口逻辑的时钟没有独立的 UART 参考时钟。这意味着总线时钟的稳定性直接决定了波特率的准确性两者绑死在一起。在 Block Design 里连线的时候这个时钟必须来自 PS 的 FCLK而且要保证这个 FCLK 真的被使能了。我遇到过一次非常典型的问题Block Design 里连了线综合也过了下载进去之后串口一点反应都没有。查了半天发现 PS 配置里那一路 FCLK 根本没勾选使能工具只是把线连上了实际时钟输出是死的。这种情况下 AXI 总线上的读写会直接挂死CPU 卡在访问外设的那条指令上看门狗都救不回来。另一个常见问题是复位。AXI UART Lite 的复位是低电平有效一般接在 Interconnect 的 peripheral reset 上这个复位信号又来自 PS 的 FCLK_RESET0_N。有些人在手工连的时候把复位接成了高有效或者干脆悬空结果就是外设偶尔能工作偶尔不能看起来像玄学。复位必须和时钟配套即这个外设用的是哪个 FCLK复位就必须用对应的那个 FCLK_RESET不能混用。还有多路 UART Lite 的情况如果它们挂在同一个 Interconnect 下共用同一个时钟和复位是没问题的但如果分属不同的时钟域就必须各自用对应的时钟和复位中间通过 AXI 时钟转换器隔离。这一点在地址分配的时候容易忽略因为地址编辑器只关心地址不关心时钟域。2.3 FIFO 深度、校验位和中断使能要不要动先说 FIFO。AXI UART Lite 的收发 FIFO 固定是 16 字节IP 配置界面里没有深度选项这一点和 PS UART 不同改不了。所以 16 字节就是硬约束软件设计必须围绕这个数字来。16 字节意味着什么按 115200 波特率、每字节 10 位1 起始位 8 数据位 1 停止位算一个字节约 86.8 微秒16 字节大概 1.39 毫秒。也就是说如果接收端连续来数据你的软件必须在 1.39 毫秒之内把 FIFO 读空否则第 17 个字节进来就会触发溢出新数据被丢弃同时状态寄存器里的溢出位被置起来。对于轮询方式1.39 毫秒是个很宽松的窗口只要主循环不是特别卡基本不会溢出。但如果你在中断里做了耗时操作或者系统里有更高级别中断长时间占用 CPU这个窗口就可能被突破。再说校验位。IP 配置里可以选无校验、偶校验、奇校验默认是无校验。这里有个细节校验位的使能是可以在运行期通过控制寄存器改的控制寄存器的 bit4 和 bit5 分别对应偶校验和奇校验使能。但实际项目里我基本不动它因为一旦使能校验收发双方必须严格一致任何一边配错就是全盘乱码而串口通信里校验位能提供的保护其实很有限真有可靠性要求不如在协议层加 CRC。所以我的建议是保持无校验把可靠性做在应用层。中断方面UART Lite 只有一个中断输出触发条件只有一个接收 FIFO 里有有效数据且中断被使能。它没有发送完成中断没有发送 FIFO 空中断没有错误中断的独立输出溢出、帧错误、校验错误只是状态位不会单独拉中断线。这个限制很关键意味着发送侧只能靠轮询或者靠软件定时器去查状态位。理解了这一点很多为什么发送不走中断的困惑就自然解开了。3. 寄存器视角把 UART Lite 拆开看它怎么工作3.1 四个寄存器就能把收发说清楚AXI UART Lite 的寄存器空间只有 16 字节实际用到的就四个 32 位寄存器。地址必须 4 字节对齐访问必须整字访问不能按字节读写这是 AXI4-Lite 的硬性要求也是新手容易犯的错——有人试图用指针强制转换成 8 位去读结果读到的是未对齐访问总线直接返回错误。偏移名称读写作用0x00RX FIFO只读读一次弹出一个接收字节低 8 位有效0x04TX FIFO只写写一次压入一个待发字节低 8 位有效0x08STAT只读状态位见下表0x0CCTRL读写控制位复位 FIFO、使能中断、使能校验状态寄存器的各个位含义需要背下来调试的时候全靠它位名称含义0RX_VALID接收 FIFO 里有数据可读1RX_FULL接收 FIFO 已满16 字节2TX_EMPTY发送 FIFO 为空可以继续写3TX_FULL发送 FIFO 已满此时写入会丢数据4INT_ENABLED中断当前是否被使能5OVERRUN发生过接收溢出6FRAME_ERR帧错误停止位没检测到7PARITY_ERR校验错误控制寄存器里常用的就三位bit0 写 1 复位发送 FIFObit1 写 1 复位接收 FIFObit3 写 1 使能中断。这两个复位位是自清零的写进去之后硬件会自动清掉读回来永远是 0所以不要用读改写的方式去操作它直接整字写就行。复位 FIFO 这个操作在初始化的时候一定要做一次因为上电瞬间 FIFO 里可能有不确定内容不复位的话第一次读可能读到垃圾。3.2 轮询收发最笨但最稳的写法对于大部分低速场景轮询就够了代码简单行为可预测不会因为中断优先级问题引入难以复现的偶发故障。核心就两个函数。#include stdint.h #define UARTL_BASE 0x41200000u #define UARTL_RX (*(volatile uint32_t *)(UARTL_BASE 0x00)) #define UARTL_TX (*(volatile uint32_t *)(UARTL_BASE 0x04)) #define UARTL_STAT (*(volatile uint32_t *)(UARTL_BASE 0x08)) #define UARTL_CTRL (*(volatile uint32_t *)(UARTL_BASE 0x0C)) #define STAT_RX_VALID (1u 0) #define STAT_TX_FULL (1u 3) static void uart_init(void) { UARTL_CTRL 0x03; /* 同时复位收发 FIFO自清零 */ UARTL_CTRL 0x00; /* 不使能中断走纯轮询 */ } static void uart_putc(uint8_t c) { while (UARTL_STAT STAT_TX_FULL) { ; } UARTL_TX (uint32_t)c; } static int uart_getc(uint8_t *c) { if (!(UARTL_STAT STAT_RX_VALID)) { return -1; } *c (uint8_t)(UARTL_RX 0xFFu); return 0; } static void uart_puts(const char *s) { while (*s) { uart_putc((uint8_t)*s); } }这段代码里有几个地方值得多说一句。uart_putc里的等待循环用TX_FULL判断而不是TX_EMPTY是因为TX_FULL为 0 就代表至少还有一个空位可写条件更宽松效率略高。当然用TX_EMPTY判断也对只是每次都要等整个 FIFO 排空反而更慢。uart_getc用返回值区分读到了和没有数据比用特殊字符当哨兵要安全得多因为串口数据里任何字节值都可能出现。这是个很基础但很多人不做的细节用哨兵迟早会被真实数据撞上。还有一个隐藏的坑读 RX FIFO 这个动作本身会弹出数据所以千万不能在判断状态和实际读取之间插入任何可能重复读的操作。有些人在调试的时候习惯在uart_getc里加一句打印状态寄存器结果发现数据少了——因为打印本身耗时而状态在两次读之间可能变化。调试手段要看但不能插入到关键路径里。3.3 中断路径的正确打开方式当波特率提高或者系统里有其他耗时任务轮询可能来不及这时候就要上中断。UART Lite 的中断是电平触发的只要接收 FIFO 里有数据且中断被使能中断线就一直保持有效直到 FIFO 被读空。这个特性决定了中断服务程序必须写成读干净为止的循环#define RX_RING_SIZE 256 static volatile uint8_t ring_buf[RX_RING_SIZE]; static volatile uint32_t ring_head; static volatile uint32_t ring_tail; void uart_isr(void *arg) { (void)arg; uint32_t stat UARTL_STAT; while (stat STAT_RX_VALID) { uint8_t c (uint8_t)(UARTL_RX 0xFFu); uint32_t next (ring_head 1u) % RX_RING_SIZE; if (next ! ring_tail) { ring_buf[ring_head] c; ring_head next; } stat UARTL_STAT; } }关键就在那个while循环。如果只读一个字节就返回中断线因为 FIFO 里还有数据会立刻再次拉高CPU 就会疯狂地反复进中断形成活锁主循环根本跑不动。这个现象在做高波特率接收的时候特别明显表现是系统像死机一样但用调试器暂停又能看到中断在不停触发。另一个容易被忽略的点是中断使能的顺序。正确顺序应该是先配置中断控制器、注册中断服务函数、使能中断控制器的这一路最后再写 UARTL_CTRL 使能外设中断。如果反过来先使能外设中断可能在中断控制器还没准备好的时候就来了一个中断被丢掉或者触发异常。虽然 UART Lite 是电平中断即使一时被丢掉后续读 FIFO 时也会重新触发但养成正确顺序的习惯没坏处。发送侧如果要走中断只能靠软件定时器去轮询状态位或者干脆在中断服务程序里顺带检查TX_FULL如果不满就继续塞数据。这种中断驱动发送是个伪概念本质上还是轮询只是把轮询点放在了别的地方。4. 从空工程到串口吐出第一行字4.1 Block Design 里的连线与地址分配在 Block Design 里例化 UART Lite它只有一个从设备接口 S_AXI一个中断输出还有 UART 和外部信号相连的 TX、RX 两个引脚。这些引脚会变成顶层端口最终约束到具体的 PL 管脚上。连线顺序我一般是这样的先把 PS 的 M_AXI_GP0 引出来接 AXI Interconnect 或者 SmartConnect再把 UART Lite 的 S_AXI 接上去。时钟统一接 FCLK_CLK0复位统一接 FCLK_RESET0_N。中断输出接到 PS 的 pl_ps_irq0 或者经过中断控制器聚合之后再接进去。如果把中断接进 PS 的 IRQ在 PS 配置里必须勾选对应的 IRQ 使能否则中断根本传不过去。UART 的 TX 和 RX 引脚有两种处理方式一是直接引到顶层端口连接到外部的 USB 转串口芯片二是在 Block Design 里接一个 AXI GPIO 或者接一个 ILA 做环回测试。做环回测试的时候最简单粗暴的办法是把 TX 和 RX 在顶层通过一个管脚短接自己在发的同时自己收这能快速验证波特率和收发通路是否正确排除外部设备的干扰。地址分配这一步千万别跳过。在 Address Editor 里点一下 Assign All让工具自动分配然后记下分到的基地址。默认的分配规则是从 0x40000000 往上第一个外设通常是 0x41200000第二个 0x41210000以此类推。这个基地址要原封不动地写进软件里任何一个数字错了总线访问就会返回错误或者走到别的地方去。这里有个细节非常值得说AXI UART Lite 的地址空间大小默认是 64KB虽然它实际只用了 16 字节。这个设计是为了满足 AXI 地址译码的边界要求不是什么冗余浪费。如果在自定义地址分配的时候把它压到 4KB 甚至更小工具可能会报错或者综合出来的译码逻辑有问题建议保持默认。4.2 裸机驱动初始化的顺序如果不想直接操作寄存器用官方提供的驱动也可以代码可读性更好也自带了一些边界检查。典型的初始化顺序如下#include xparameters.h #include xuartlite.h #include xuartlite_l.h static XUartLite uart_inst; int uart_drv_init(uint16_t dev_id) { XUartLite_Config *cfg XUartLite_LookupConfig(dev_id); if (cfg NULL) { return -1; } if (XUartLite_CfgInitialize(uart_inst, cfg, cfg-RegBaseAddr) ! XST_SUCCESS) { return -1; } XUartLite_ResetFifos(uart_inst); return 0; }XUartLite_ResetFifos这一步不能省驱动级的复位比直接写控制寄存器更保险它会同时处理收发两侧。初始化完成之后发送用XUartLite_SendByte接收用XUartLite_RecvByte配合XUartLite_IsReceiveEmpty判断本质还是轮询。如果要用驱动的中断模式就需要多几步通过XUartLite_SetRecvHandler注册回调通过XUartLite_EnableInterrupt使能外设中断同时还要在中断控制器里把对应的中断号接上。驱动自带的中断处理函数XUartLite_Handler会在接收 FIFO 有数据时被调用然后回调你注册的函数。这套机制在接收长度不固定的时候用起来比较顺手但要注意驱动内部的接收缓冲区大小是有限的超长报文会被截断。4.3 printf 重定向和自定义输出裸机环境下用xil_printf打印是最快的调试手段但默认的输出目标是 PS 的串口。如果板上根本没有 PS 串口或者 PS 串口已经被挪作他用就需要重定向。老版本的做法是重定义outbyte和inbyte这两个弱符号函数void outbyte(char c) { uart_putc((uint8_t)c); } char inbyte(void) { uint8_t c 0; while (uart_getc(c) ! 0) { ; } return (char)c; }新版本的 Standalone BSP 里更规范的做法是在 BSP 配置里把 stdin 和 stdout 直接指定成 UART Lite 设备。这样做的好处是不用改代码换个工程只要改配置就行。但要注意一旦指定了 stdout所有xil_printf的输出都会走这路串口包括驱动内部的一些断言信息如果波特率不匹配或者线路有问题这些信息会静默丢弃看起来像是程序没跑。重定向还有个性价比更高的用法在发送函数里加一个缓冲区把多次xil_printf的内容攒起来一次性写进 FIFO。因为每次写 FIFO 都是一次 AXI 事务开销不小如果每个字符都单独写打印一行几十个字符的日志就要发起几十次总线事务在低端配置下会影响实时性。我一般是做一个 128 字节的行缓冲遇到换行或者缓冲区满才真正刷出去。4.4 回环自测最快的验证手段在接入外部设备之前一定要先做自测。最省事的办法是在软件的发送函数里加一个旁路发出去的同时把字节也塞进接收缓冲区这样能验证软件通路。但这只验证了软件验证不了硬件。真正有效的是硬件回环。把 UART Lite 的 TX 和 RX 在 PL 引脚上短接或者通过一个跳线帽短接然后软件发一串已知数据看能不能原样收回来。这个测试通过了说明波特率配置正确、时钟正确、FIFO 工作正常、软件收发逻辑正确剩下的问题就只可能在外部设备或线缆上。回环测试的代码很简单static int uart_loopback_test(void) { const uint8_t pattern[] {0x55, 0xAA, 0x00, 0xFF, 0x5A, 0xA5}; uint8_t rx; uint32_t i; UARTL_CTRL 0x03; UARTL_CTRL 0x00; for (i 0; i sizeof(pattern); i) { uart_putc(pattern[i]); } for (i 0; i sizeof(pattern); i) { uint32_t timeout 100000; while (!(UARTL_STAT STAT_RX_VALID)) { if (--timeout 0) { return -1; } } rx (uint8_t)(UARTL_RX 0xFF); if (rx ! pattern[i]) { return (int)(i 1); } } return 0; }选这组测试数据是有讲究的。0x55 和 0xAA 交替的位模式能暴露波特率偏差导致的采样点偏移如果波特率误差偏大接收到的这两个字节最容易出错。0x00 和 0xFF 是全 0 和全 1能暴露电平极性和驱动能力的问题。返回值设计成错误位置加一是为了区分第几个字节错了和完全没收到调试的时候能快速定位。5. 调试实录乱码、丢包、中断失灵怎么查5.1 满屏乱码时的三条检查线乱码是最高频的问题成因基本集中在三个地方可以按成本从低到高排查。第一条线是波特率不匹配。前面说过UART Lite 的波特率由 IP 配置时的时钟频率决定这个数字必须和实际 AXI 时钟一致。检查方法是打开综合后的报告找到这一路 FCLK 的实际频率和 IP 配置里的数字对比。同时还要确认外接设备的波特率设置是否一致特别是有些模块出厂默认是 9600手册里写的是 115200这种文档和实物不一致的情况很常见。第二条线是帧格式不匹配。UART Lite 固定是 8 位数据位、1 位停止位、无校验除非使能起始位是硬件自动的。如果对接设备配置成了 7 位数据位、2 位停止位、偶校验那就是怎么都对不上。这种问题在接老设备或者工业模块的时候特别多因为那些设备为了兼容性经常用 7E1 或者 7O2。第三条线是电气问题。TX 和 RX 没有交叉、地线没接、电平不匹配都会表现成收到一堆乱码或者完全收不到。AXI UART Lite 输出的是 TTL 电平3.3V绝对不能直接接 RS232 的 ±12V会烧芯片。如果用 USB 转串口模块要确认模块是 3.3V TTL 而不是 RS232 电平接线是 TX 接对方 RX、RX 接对方 TX共地。板子之间通信还容易出现地电位差问题长线的时候必须共地最好加一点保护。还有一个比较隐蔽的情况时钟虽然频率对但抖动大或者不稳定。Zynq 的 FCLK 来自 PLL正常情况下很稳但如果 PS 配置里用了低质量的参考时钟或者 PLL 配置有问题输出可能带很大抖动表现出来就是偶尔错几个字节长期跑会累积错误。这种问题用示波器看 TX 波形最直观波形应该干净、周期均匀如果看到明显的周期抖动或者边沿畸变就要去查时钟源。5.2 数据丢一半怎么定位丢数据的表现是收到的内容里有缺失或者长度不对。排查的核心是搞清楚丢在哪一段是发送侧没发出去还是接收侧没接住。发送侧检查比较简单在发送前读状态寄存器的TX_FULL位如果一直是满的说明前一批数据还没排空就急着写下一批写入被硬件丢弃了。UART Lite 在 TX FIFO 满的时候写入不会阻塞、不会报错直接丢这是设计行为。所以发送循环里的while (TX_FULL)等待是必须的不能省。接收侧的情况复杂一些。最常见的溢出触发条件是关闭了中断、在主循环里做了耗时操作比如读写 Flash、做 CRC 校验、等待某个信号量。这时候 16 字节的 FIFO 很快就被填满后面的字节全丢。解决办法要么是把接收处理放进中断要么在耗时操作前后主动查一下状态位把数据取走要么用 DMA 加双缓冲但 UART Lite 没有 DMA只能靠软件模拟。有一种情况特别迷惑偶尔丢最后几个字节。现象是发 100 字节收到 96 或 97 字节前面的都对就是尾部少了。这通常是因为发送方把数据全塞进 FIFO 之后就认为发送完成了实际上 FIFO 里还有几个字节没移出去此时如果立刻复位 FIFO 或者断电尾巴就丢了。正确做法是在确定不再发送之后等待状态寄存器的TX_EMPTY位变高确认硬件已经把最后一个字节的停止位都移出去了。还有一个容易忽略的点读 FIFO 的时机和状态判断之间的竞争。如果先读状态寄存器看到RX_VALID为 1然后因为某种原因延迟了一段时间才去读 RX FIFO中间可能有新字节进来也可能被别的地方读走了。单核裸机系统里一般不会有并发读的问题但如果中断和主循环都在读同一个 FIFO就很容易出现数据被抢走的情况。我的做法是只在一个地方读 FIFO中断里读就主循环不读主循环读就关中断绝不让两条路径共存。5.3 中断进不来的排查顺序中断不通的排查有一条比较清晰的链路从外设往 CPU 方向逐段确认。第一步确认外设中断确实被使能了。读状态寄存器的 bit4这一位反映当前中断使能状态如果为 0说明控制寄存器的 bit3 没写进去。有时候是写了但被后面的复位操作清掉了检查一下初始化顺序。第二步确认中断线在 PL 侧是否真的连到了 PS。在 Block Design 里看 UART Lite 的 interrupt 端口有没有连线如果经过了中断控制器要看控制器的输出有没有接到 PS 的 pl_ps_irq。第三步确认 PS 侧的 IRQ 使能。PS 配置界面里有一组 IRQ 使能勾选项默认可能只开了几路如果 UART Lite 的中断接到了一个没被使能的 IRQ 号上中断永远进不来。第四步确认软件层面。中断控制器是否初始化、对应的中断号是否被 connect、是否被 enable、异常向量是否打开Xil_ExceptionEnable这几步少任何一步都会导致中断静默丢弃。第五步也是我踩过最多次的坑中断进来了但 handler 里读 FIFO 的方式不对导致看起来像没进来。比如 handler 里用的是驱动的Recv接口而这个接口要求预先指定接收长度长度没到就不回调表现出来就是数据收了一部分之后再也没有回调。改用逐字节轮询状态位的方式就正常了。还有一个非常隐蔽的问题中断服务程序执行时间过长。如果 handler 里做了复杂处理比如协议解析、字符串格式化、甚至调用xil_printf打印中断响应时间会变得很长在这期间新的字节进来可能触发溢出。我的一般原则是 handler 只做搬运把字节从 FIFO 挪到环形缓冲区解析和处理全部放到主循环里做。5.4 现场速查表把上面这些整理成一张可以直接对照的表出问题的时候按表逐行排查比凭感觉猜快得多。现象优先怀疑快速验证手段完全收不到任何字节TX/RX 未交叉、未共地、外部设备未上电短接 TX/RX 做回环能通说明本端正常收到满屏乱码波特率配置与实际时钟不一致核对 FCLK 实际频率与 IP 配置值数据部分正确部分乱帧格式不一致、时钟抖动双方统一为 8N1示波器看波形收到数据但长度变短接收 FIFO 溢出读状态寄存器 bit5 溢出位尾部几个字节丢失未等 TX_EMPTY 就复位或断电发送后等待 TX_EMPTY 变高中断只进一次handler 未读空 FIFO改为 while 循环读至 RX_VALID 为 0中断完全进不来中断未使能、IRQ 未勾选、异常未开逐段读状态位确认系统像死机中断活锁反复进出中断调试器暂停看 PC 是否在 handler 里访问外设时挂死时钟未使能、地址未分配用 ILA 抓 AXI 总线看有无响应长时间运行后出错时钟不稳定、电源纹波示波器长时观察波形质量这张表里最后两行值得单独说一下。用 ILA 抓 AXI 总线是排查总线级问题的终极手段把 AW、W、B 三个通道和 AR、R 两个通道的信号都加上触发条件设在响应通道的 resp 信号上如果看到 SLVERR 或者 DECERR那就是地址错了或者外设没响应。这个手段比盲猜有效得多尤其是在地址分配出错、时钟域不匹配这类问题上。6. 把它用到位性能边界和几个实用扩展6.1 波特率的天花板到底在哪很多人以为 UART Lite 的性能瓶颈在 IP 本身实际上瓶颈在总线和 CPU。每收发一个字节都要发起一次 AXI 读写事务在 100MHz 的 AXI 时钟下一次简单的事务大概几个时钟周期理论上限是几 MB/s但实际受限于 CPU 的指令开销、总线仲裁、缓存行为真实吞吐要低不少。更实际的限制来自 16 字节的 FIFO 和中断响应延迟。假设波特率是 921600每字节约 10.8 微秒16 字节的缓冲只能撑 173 微秒。如果系统里有其他中断或者主循环里有耗时操作这个窗口很容易被突破。所以在 921600 以上必须用中断并且保证 handler 足够短。我实测过的稳定区间是115200 及以下用轮询完全没问题230400 到 460800 建议用中断再往上就要谨慎评估系统负载必要时考虑换 PS UART 或者用 PL 侧的逻辑做硬件收发只把成包的数据交给 CPU。还有一个上限是 IP 配置本身。分频系数是整数目标波特率越高分频系数越小量化误差越大。在 100MHz 时钟下115200 的误差是 0.47%921600 的分频系数是 6实际波特率是 1041666误差高达 13%根本没法通信。所以在高波特率下要么提高 AXI 时钟频率要么换方案。这个计算在做方案设计的时候就要做一遍不能等调不通了才发现。6.2 软件流控和协议层的补丁UART Lite 没有硬件流控引脚但这不意味着不能做流控。最常见的做法是在应用层定义一个简单的握手协议接收方在缓冲区快满的时候发一个 XOFF 字符发送方收到就暂停缓冲区腾出空间之后发 XON发送方继续。这套机制就是软件流控虽然响应慢但对于低速、短报文的场景够用。实现的时候要注意 XOFF 和 XON 这两个字符本身不能出现在正常数据里所以要么在数据里做转义要么用固定的报文头加长度字段让接收方能区分控制帧和数据帧。我一般用后者报文格式是帧头 类型 长度 负载 校验类型字段区分控制帧和数据帧这样不会有字符冲突问题。另一个常见的补丁是超时重传。串口本身没有重传机制一旦数据丢了就是丢了。在协议层加一个序号和确认机制发送方发出去之后等确认超时没收到就重发接收方按序号去重。这套东西在 Modbus 之类的工业协议里已经是标准做法自己实现的话也不复杂几十行代码就够。还有一个值得提的是接收超时判定帧结束。很多串口协议没有明确的帧长度或者结束符靠的是字节间的时间间隔来判断一帧结束。典型的做法是每收到一个字节就重置一个定时器定时器超时比如 3.5 个字符时间就认为一帧结束。这个做法在 UART Lite 上实现起来要注意定时器的精度要足够而且不能在中断里做太重的判断。我个人在实际项目里踩过最深的一个坑是忽略了 PL 侧那一路 UART Lite 的初始化时机。PS 启动很快几毫秒就开始跑代码但 PL 的配置是通过 PCAP 在启动后期完成的如果软件在 PL 还没配置完的时候就去读写 UART Lite 的寄存器总线访问会直接挂死。解决办法是在访问任何 PL 外设之前先检查 PL 是否配置完成或者干脆在软件最前面加一段延时等 PL 稳定之后再初始化。这个坑在没有调试器、只靠串口看日志的时候几乎无法定位因为系统直接卡死什么信息都出不来。后来我的做法是保留 PS 那一路串口专门打早期启动日志PL 侧的 UART Lite 只用于业务数据两条通道各司其职出了问题一眼就能看出卡在哪一段。