Petalinux实战：3种方法调试AXI UART Lite设备（含minicom/screen/直接寄存器操作对比）
做嵌入式Linux开发，尤其是Zynq系列平台上用Petalinux构建系统的朋友，十有八九会跟AXI UART Lite这个IP核打交道。它轻量、简单、占用资源少，常用于调试串口、与FPGA逻辑通信或者连接低速外设。但正因为"Lite"，它的调试手段和普通UART不太一样，很多人在设备树配好、驱动加载后，发现串口没反应或者乱码，然后就开始怀疑人生。
这篇文章把我实际调试AXI UART Lite的经验整理一遍，重点讲三种亲测有效的方法：最常用的minicom、适合脚本化和远程场景的screen，以及能让你彻底搞懂硬件工作逻辑的直接寄存器操作。三者各有优劣，我会把每种方法的适用场景、操作步骤、坑和原理都说明白。内容基于Petalinux 2023.2及以上版本，Zynq-7000和Zynq UltraScale+平台均适用。
1. 内容整体设计与思路拆解
1.1 为什么要单独聊AXI UART Lite的调试
用过Vivado里标准UART 16550 IP的人，可能觉得串口调试就是插上线、打开终端、看输出。但AXI UART Lite完全是另一套逻辑。它本质上是一个挂在AXI总线上的寄存器设备，没有中断（除非你单独配置），没有FIFO中断水位线，甚至默认配置下收发缓冲区都小得可怜。更关键的是，它在Petalinux里的设备树节点、驱动绑定方式、控制台映射逻辑都和普通UART有差异。
实际开发中，我见过太多人卡在这么几个问题上：
- Petalinux构建完成后，/dev/ttyUL0不存在，或者存在但无法打开。
- 串口能收到数据，但一收长数据就丢字节。
- 把console=ttyUL0配好后，内核启动日志完全没输出。
- 误以为UART Lite和UART 16550驱动兼容，结果IOCTL调用全部失败。
这些问题的本质，其实是对AXI UART Lite的寄存器模型和驱动工作机制缺乏直观理解。所以这篇文章不只是给三个命令，而是把三条调试路径串起来，从应用层工具到内核驱动再到硬件寄存器，形成一个完整的调试思路。
1.2 三条调试路径的选型逻辑
在讲具体操作前，先说说三条路径各自解决什么问题：
- minicom：最经典的串口终端工具，适合交互式调试、查看启动日志、手动输入命令。它依赖本地物理串口或USB转串口，适合开发板上电阶段的Bring-up。
- screen：终端复用器的串口模式，适合远程调试、脚本化交互、快速连接。它不依赖专门的串口软件，Linux服务器上几乎默认安装。
- 直接寄存器操作：通过devmem或/dev/mem读写UART Lite的寄存器，绕开驱动，直接控制硬件。适合驱动异常、需要验证硬件时序、或者想彻底搞懂IP核工作细节的场景。
这三者是递进关系。先用minicom确认基本通路，再用screen处理更复杂的交互场景，最后用寄存器操作兜底排查驱动和硬件问题。下面从环境准备开始逐步展开。
2. 环境准备：Petalinux侧的关键配置
2.1 Petalinux工程中确认AXI UART Lite已正确使能
很多调试问题其实在Petalinux配置阶段就埋下了。AXI UART Lite在Petalinux里的使能方式比较隐蔽，它不是简单的"设备树里有节点就行"，还涉及内核驱动配置。
在内核配置中，必须确认以下选项已经开启：
petalinux-config -c kernel进入Device Drivers -> Character devices -> Serial drivers，确保以下两项被选中：
CONFIG_SERIAL_XILINX_UARTLITE（Xilinx UART Lite serial port support）CONFIG_SERIAL_XILINX_UARTLITE_CONSOLE（Support for console on Xilinx UART Lite）
第一项是驱动本体，第二项是将UART Lite作为内核控制台。如果你打算把内核启动日志输出到这个串口，第二项必须打开。否则即使驱动加载了，console=ttyUL0也不会生效。
驱动使能后，检查设备树。以Zynq UltraScale+平台为例，典型的AXI UART Lite设备树节点长这样：
axi_uartlite_0: serial@a0000000 { compatible = "xlnx,xps-uartlite-1.0"; reg = <0x0 0xa0000000 0x0 0x10000>; interrupts = <0 25 4>; clock-names = "s_axi_aclk"; clocks = <&zynqmp_clk 71>; current-speed = <115200>; port-number = <0>; };注意port-number = <0>这个属性，它决定了设备注册成ttyUL0还是ttyUL1。如果多个UART Lite设备同时存在，一定要通过这个属性明确指定编号，否则系统按探测顺序分配，容易出现设备节点漂移。
2.2 常见坑：驱动加载了但设备节点没出现
一个高频问题是：内核配置和设备树都正确，但系统起来后/dev/ttyUL0不存在。我遇到过好几次，原因几乎都是设备树中reg地址与Vivado里的地址分配不一致。
排查方法很简单：
cat /proc/device-tree/axi/serial@a0000000/reg看输出的地址是否是预期值。如果地址是0，说明设备树没正确解析，或者petalinux-build时使用的设备树源文件不是你以为的那份。
另外提醒一下，AXI UART Lite的compatible字符串有两种风格：旧版用的是xlnx,xps-uartlite-1.0，新版用的是xlnx,uartlite-1.0。如果你的Petalinux内核版本较老，而Vivado生成的设备树里用了新字符串，驱动可能匹配不上。解决办法是在设备树中同时保留两个compatible值，别问我是怎么知道的。
3. 方法一：minicom调试AXI UART Lite的完整流程
3.1 minicom的安装与基础配置
minicom是串口调试的"老朋友"，几乎所有的嵌入式Linux教程里都会出现。在Ubuntu/Debian主机上安装：
sudo apt-get install minicom安装后先别急着连接开发板，因为minicom默认配置不一定匹配你的串口设备。先查看系统识别的串口设备：
ls /dev/ttyUSB* # 或 ls /dev/ttyACM*USB转串口适配器最常见的设备节点是ttyUSB0，如果使用的是开发板自带的USB调试口，也可能是ttyACM0。确认设备节点后，进入minicom配置界面：
sudo minicom -s选择"Serial port setup"，按A修改串口设备为/dev/ttyUSB0，按E修改波特率为115200（或你的实际配置），8N1数据格式通常无需修改。设置完成后选择"Save setup as df1"，下次启动minicom直接加载默认配置。
3.2 连接开发板并验证UART Lite是否正常
配置完成后，启动minicom：
sudo minicom -D /dev/ttyUSB0 -b 115200此时如果AXI UART Lite已经在内核中注册为控制台，你应该能在minicom窗口中看到内核启动日志。如果没有输出，先按一下开发板的复位键，让内核重新启动，因为UART Lite作为console时只在启动阶段输出日志，系统运行后如果没有应用程序往串口写数据，终端会一直静默。
如果复位后仍然没有任何输出，按下回车键或者发送一个换行符，因为UART Lite默认的回环测试功能可能会吞掉首字符。也可以在minicom中按Ctrl+A然后按Z，打开帮助菜单，确认"Local Echo"（本地回显）是否开启。如果开了本地回显，你在终端输入的内容会先显示在本地，这样即使开发板没有响应，也能判断串口链路是否物理连通。
3.3 minicom场景下的乱码处理实战
乱码是串口调试中最令人抓狂的问题。使用minicom调试AXI UART Lite时，乱码通常有三种原因：
原因一：波特率不匹配。这是最常见的情况。AXI UART Lite的波特率由设备树中的current-speed属性决定，但注意，这个属性只对驱动生效。如果你用minicom设置的波特率与设备树配置不一致，收到的就是乱码。验证方法是查看开发板上电时U-Boot的串口设置，通常U-Boot和内核共用同一个串口时，波特率是一致的。
原因二：电平不匹配。AXI UART Lite通常是1.8V或3.3V LVCMOS电平，而USB转串口适配器大部分是3.3V TTL电平，两者在电压域上存在兼容问题。如果你用5V电平的适配器连接1.8V的UART Lite，轻则乱码，重则烧毁引脚。排查手段是先确认Vivado工程中UART Lite的电平标准，再选择匹配的转接板。
原因三：发送端数据格式异常。UART Lite的寄存器配置中，数据位、停止位、校验位是可以独立配置的。如果驱动配置了8N1（8数据位、无校验、1停止位），而另一端发送的是7E1，自然会出现可读字符夹杂乱码的情况。用minicom时，按Ctrl+A然后按O进入配置菜单，在"Serial port setup"中确认数据位和校验位设置。
我实测下来，minicom调试UART Lite的稳定性在大多数场景下是够用的，但它的缺点是配置项分散，初次使用门槛高。而且minicom对Ctrl+S/Ctrl+Q这类软件流控字符的处理很敏感，如果误开启流控，串口会像"冻住"一样完全无响应。遇到这种情况，先按Ctrl+A然后按Z，再按F关闭流控。
4. 方法二：screen作为轻量级串口调试工具
4.1 为什么我推荐screen
很多人不知道，Linux自带的screen不仅能管理终端会话，还能直接当作串口终端工具使用。相比minicom，screen有三大优势：
第一，依赖极简。上面提到minicom需要单独安装，而screen在绝大多数Linux发行版中默认安装了，或者一条命令就能装完。
第二，脚本化友好。screen可以用命令行参数直接指定串口和波特率，不需要像minicom那样先进配置菜单。这个特性让screen在自动化测试和CI/CD流程中非常有价值。
第三，会话分离能力。用screen连接开发板后，可以脱离当前SSH会话，让串口连接在后台持续运行。等你重新登录后，可以重新附着到之前的screen会话，查看之前的串口输出。这对远程调试来说太重要了。
4.2 screen连接UART Lite的三种方式
最基本的连接方式：
sudo screen /dev/ttyUSB0 115200如果需要指定数据位、停止位和校验位，稍作变通：
sudo screen /dev/ttyUSB0 115200,cs8,-parenb,-cstopb这里cs8表示8位数据位，-parenb表示无校验位，-cstopb表示1位停止位。这些参数对应stty的配置语法，熟悉Linux终端配置的朋友应该不陌生。
第三种方式是通过配置文件挂载串口参数。创建~/.screenrc文件，加入以下内容：
screen /dev/ttyUSB0 115200,cs8,-parenb,-cstopb之后直接执行screen，就会自动打开串口终端。这种方式适合有多个串口需要管理的场景，可以在配置文件中定义多个screen会话。
4.3 screen的退出、分离与重连
screen的交互命令和minicom不同，新手最容易卡在"怎么退出"这个问题上。退出screen会话的标准操作是：按Ctrl+A，然后按K，按Y确认终止。如果你只是想暂时离开，不中断串口连接，按Ctrl+A然后按D分离会话。
重新附着到之前的会话：
screen -r如果有多个screen会话，先用screen -ls查看会话列表，再用screen -r 会话ID附着指定会话。
我在实际调试中有一个习惯：用screen连接开发板，然后分离会话，让开发板持续输出日志。之后用grep或awk实时分析日志内容时，通过screen -X命令向会话发送特殊字符。
screen -S 会话ID -X stuff $'\003'这条命令的作用是向串口会话发送Ctrl+C字符，用于中断开发板上正在运行的前台程序。这种方式在无人值守的自动化测试环境中特别实用。
4.4 screen下发生乱码的排查思路
screen下的乱码排查和minicom基本类似，但有个细节值得单独说。如果你在screen中看到类似^@^@^@的重复字符，这通常意味着UART Lite的发送端时钟配置异常——数据没发出去，但时钟信号的电平翻转被误识别成了数据位。
还有个大坑：screen的转义键Ctrl+A和minicom有细微区别。在minicom中Ctrl+A是转义前缀，在screen中同样是转义前缀，但按两次Ctrl+A会发送真正的Ctrl+A字符。如果你在串口通信中需要发送Ctrl+A（比如进入U-Boot命令行），一定要在screen中按两次Ctrl+A再按一次A，实际操作顺序是：Ctrl+A、A、A。第一次进入转义状态，第二次是重复发送指令，第三次才是目标字符。
5. 方法三：直接寄存器操作——从硬件视角理解UART Lite
5.1 AXI UART Lite的寄存器模型速览
如果前面两种方法都搞不定，或者你想从根源上理解这个设备的行为，直接操作寄存器是最后的兜底方案，也是最能提升内功的方法。
AXI UART Lite的寄存器布局很简洁，核心寄存器只有4个：
| 偏移地址 | 寄存器名 | 功能 |
|---|---|---|
| 0x00 | RX FIFO | 接收数据寄存器，读操作获取一个字节 |
| 0x04 | TX FIFO | 发送数据寄存器，写操作发送一个字节 |
| 0x08 | STAT | 状态寄存器，包含TX FIFO满、RX FIFO空等标志 |
| 0x0C | CTRL | 控制寄存器，配置使能、中断、波特率分频等 |
以0x08偏移的STAT寄存器为例，常用位定义如下：
- bit0：RX FIFO Valid，置1表示RX FIFO中有可读数据
- bit1：RX FIFO Full，置1表示RX FIFO已满
- bit2：TX FIFO Empty，置1表示TX FIFO已空
- bit3：TX FIFO Full，置1表示TX FIFO已满
发送一个字节的流程：先读STAT寄存器，确认TX FIFO Empty或TX FIFO Full为0，然后向TX FIFO寄存器写入数据。
接收一个字节的流程：读STAT寄存器，确认RX FIFO Valid为1，然后读RX FIFO寄存器获取数据。
5.2 使用devmem进行寄存器读写实操
Petalinux默认的内核配置中，devmem工具通常已经包含在busybox中。直接在开发板终端执行：
devmem 0xa0000000这条命令会读取地址0xa0000000处的32位数据，也就是RX FIFO寄存器的值。如果UART Lite接收到数据，这里应该返回非零值。
向UART Lite发送一个字节，比如发送字符'A'（ASCII码0x41）：
devmem 0xa0000004 32 0x41要验证发送是否成功，通常会做一个外部回环测试。将UART Lite的TX引脚和RX引脚用杜邦线短接，然后在开发板上执行：
devmem 0xa0000004 32 0x41 devmem 0xa0000000第一条命令发送字符'A'，第二条命令读取接收寄存器。如果回环正常，第二条命令应该返回0x41。
5.3 一个实用的寄存器测试脚本
为了更高效地验证UART Lite硬件通路，我在项目中写过一个简单的shell脚本，推荐大家参考：
#!/bin/sh # UART Lite register loopback test # Usage: ./uartlite_test.sh <base_addr> BASE=${1:-0xa0000000} TX_REG=$((BASE + 0x4)) STAT_REG=$((BASE + 0x8)) echo "UART Lite loopback test at base ${BASE}" # Test 1: Check TX FIFO ready STAT=$(devmem ${STAT_REG}) echo "STAT register value: ${STAT}" if [ $((STAT & 0x4)) -eq 0 ]; then echo "TX FIFO is not empty, waiting..." sleep 1 fi # Test 2: Send five bytes for ch in 0x48 0x65 0x6C 0x6C 0x6F; do devmem ${TX_REG} 32 ${ch} echo "Sent: ${ch}" done # Test 3: Read back if loopback is connected sleep 1 for i in 1 2 3 4 5; do STAT=$(devmem ${STAT_REG}) if [ $((STAT & 0x1)) -eq 1 ]; then DATA=$(devmem ${BASE}) echo "Received: ${DATA}" else echo "RX FIFO empty, no data received" fi done保存为uartlite_test.sh后，添加可执行权限运行：
chmod +x uartlite_test.sh ./uartlite_test.sh 0xa0000000如果回环未连接，脚本会提示RX FIFO为空；如果发送链路异常，STAT寄存器的TX FIFO标志位会异常。这个脚本在产线测试和硬件Bring-up阶段特别好用。
5.4 寄存器操作时的安全警告
直接操作寄存器是双刃剑，能帮你解决问题，也能帮你烧掉器件。操作前务必注意三点：
第一，确认地址正确性。在对UART Lite基地址下手前，先用cat /proc/iomem | grep uart查看内核实际分配的资源范围，确保没有与其他设备地址冲突。
第二，不要随意改写CTRL寄存器。CTRL寄存器中的位定义在不同版本的Xilinx IP中可能有差异，错误配置可能导致设备永久失效，需要重新烧写FPGA bitstream才能恢复。
第三，devmem操作的是物理地址，不受内核内存管理保护。如果地址写错，最轻的后果是bus error终止进程，最严重的情况是破坏了正在使用的DMA缓冲区或DDR内存区域，导致系统崩溃甚至文件系统损坏。
我个人的习惯是，不到万不得已不凭记忆操作寄存器。操作前一定先看Vivado工程中UART Lite的Datasheet（PG142），确认寄存器地址和位域定义。
6. 三种方法的综合对比与选型建议
6.1 minicom、screen、寄存器操作对比表
从实际工程应用角度，我把这三者的差异整理成下表：
| 对比维度 | minicom | screen | 寄存器操作 |
|---|---|---|---|
| 安装便利性 | 需单独安装 | 系统自带率高 | devmem通常在busybox中 |
| 交互体验 | 功能全、配置复杂 | 简洁、上手快 | 无交互界面 |
| 脚本化能力 | 弱，适合人工交互 | 强，支持会话管理和指令注入 | 极强，完全可自动化 |
| 硬件故障判断 | 间接判断 | 间接判断 | 直接判断 |
| 调试内核/驱动问题 | 一般 | 一般 | 非常有效 |
| 适用场景 | 上电调试、手动交互 | 远程调试、无人值守 | 硬件验证、驱动排障 |
| 学习门槛 | 中等 | 低 | 较高 |
总结下来，如果你是第一次接触AXI UART Lite，用minicom把基础通路跑通；如果你的调试环境在远程服务器上，或者需要长时间不间断记录日志，用screen；如果你怀疑驱动配置有问题，或者需要验证硬件设计是否OK，直接上寄存器操作。
6.2 实际项目中的组合打法
在一套完整的调试流程中，这三种方法往往会组合使用。
项目初期，我会在Vivado中确认UART Lite的基地址和中断号，然后配置Petalinux，构建系统，烧录SD卡。开发板上电后，先用minicom连接查看启动日志，确认内核是否识别到ttyUL0设备。
启动日志正常后，切换到screen方式，建立串口会话并分离，让开发板跑压力测试。测试期间用脚本定期检查screen日志文件，自动抓取异常字符。
如果压力测试不通过，或者出现数据丢失，我会用devmem直接操作寄存器，对比实际硬件状态和驱动行为，快速定位是驱动FIFO管理问题还是硬件设计问题。
这种组合打法在多个项目里实测下来，排查效率比单一工具高很多。
7. 常见问题与排查技巧实录
7.1 高频问题速查表
把我在社区和各种项目群看到的、以及亲身踩过的高频问题汇总成一张速查表，方便大家按图索骥：
| 现象 | 可能原因 | 解决方向 |
|---|---|---|
| /dev/ttyUL0不存在 | 设备树地址错误 | 检查设备树reg与Vivado地址 |
| 打开串口报Permission denied | 用户不在dialout组 | sudo usermod -aG dialout $USER |
| 能收到数据但全乱码 | 波特率不匹配 | 核对设备树current-speed与终端设置 |
| 数据输出正常但无法输入 | 流控被误开启 | 关闭minicom/screen软件流控 |
| 发送大数据时丢字节 | TX FIFO满，驱动未等待 | 检查驱动FIFO管理逻辑 |
| devmem读寄存器报bus error | 地址超出资源映射范围 | 检查iomem分配的地址区域 |
| 控制台无输出但ttyUL0存在 | console参数未生效 | 检查内核启动参数console=ttyUL0 |
| 间歇性无响应 | 中断配置错误 | 对比Vivado中断号与设备树interrupts属性 |
7.2 两个容易忽视的细节
第一个细节是权限问题。在Ubuntu桌面版上，普通用户默认不在dialout组中，直接打开串口会报"Permission denied"。看似是软件问题，实则是系统权限控制。
sudo usermod -aG dialout $USER执行完需要重新登录才能生效。如果是远程调试，记得在写完这个命令后重新建立SSH会话，或者使用newgrp dialout临时切换用户组。
第二个细节是UART Lite与标准UART的设备树回调差异。标准UART驱动通常会自动设置termios参数，而UART Lite驱动在某些内核版本上存在"写寄存器前未等待TX FIFO空"的竞态。如果遇到高波特率下的数据丢失，先在设备树中降低波特率验证，如果降速后问题消失，基本可以确定是驱动的FIFO等待逻辑问题，而不是硬件问题。
7.3 我的几点实操心得
文章写到这里，想分享几个用真金白银换来的经验。
第一，调试AXI UART Lite时，永远先确认物理链路，再排查软件。我见过太多人花几个小时调设备树、改驱动，最后发现是杜邦线接触不良。最简单的做法是用万用表量一下TX/RX引脚的电压电平，确认TX引脚在空闲状态时是高电平（通常3.3V或1.8V）。如果空闲时是低电平，那不管软件怎么调都是徒劳。
第二，设备树里的clock属性一定要认真核对。AXI UART Lite的波特率发生器依赖s_axi_aclk时钟，如果这个时钟频率设置不对，即使驱动和设备树波特率一致，实际通信波特率也是错误的。UART Lite的波特率计算方式是时钟频率/分频系数，分频系数写死在IP配置里。你只能在Vivado中修改IP的波特率配置，然后重新生成设备树和PetaLinux工程，运行时通过软件改波特率是改不了硬件分频的。这是UART Lite和标准UART的又一个重要区别。
第三，如果开发环境允许，芯片原厂提供的"Virtual IO"调试方式值得研究。在Vivado的硬件管理器里，可以通过JTAG虚拟一个UART终端来调试UART Lite，完全不占用物理串口资源。虽然这个方法不在本文三种方法范围内，但在板卡无法连接物理串口时是个绝佳的备用方案。
8. 从最小系统到规模化调试的进阶思路
8.1 制作SD卡启动镜像时的调试准备
很多人在Petalinux构建阶段就会遇到问题，根本走不到串口调试那一步。这里补充一个与调试强相关的实战细节：制作SD卡启动镜像时，提前把调试工具打包进rootfs。
在petalinux-config的Filesystem packages配置中，确认以下工具被选中：
- devmem2或devmem（注意busybox中可能只有devmem，没有devmem2）
- minicom或screen（根据个人习惯）
- nano或vi（修改配置文件）
如果你的调试场景涉及多块开发板，强烈建议把SSH服务也加进去。这样就不需要每次插拔串口线，直接通过网络登录开发板调试UART Lite，然后把串口工具作为辅助手段。具体配置方法：
petalinux-config -c rootfs进入Image Features，勾选ssh-server-openssh，然后重新构建。
这个技巧在批量调试时特别有用。我之前调试4块板卡时，4条串口线加一堆杜邦线，桌面乱成一团。换成SSH后，一个终端窗口全搞定，串口线只留了一条作为备用。
8.2 AXI UART Lite的中断驱动模式与轮询模式
在Petalinux默认配置中，UART Lite驱动会在两种模式间自动切换：如果设备树中定义了interrupts属性，驱动使用中断模式；否则使用轮询模式。
两种模式在调试时的表现差异很大。中断模式下，串口接收数据时CPU利用率很低，适合高吞吐场景。但中断模式下，如果中断号配置错误，会导致数据完全无法接收。轮询模式下，驱动会忙等STAT寄存器的状态位，CPU占用率偏高，但即使中断系统异常也能正常工作。
调试过程中，如果你看到数据接收正常但CPU占用率高达50%以上，可以查一下设备树中是否配置了interrupts属性。如果没有，说明驱动运行在轮询模式。这种情况下，性能瓶颈不在硬件，而在驱动设计。
反过来，如果你配置了中断但完全收不到数据，先用devmem手动操作确认硬件通路，再用cat /proc/interrupts查看中断计数是否增加。如果中断计数不增加，先检查Vivado里UART Lite的中断是否连接到了PS的中断控制器，再看设备树中interrupts属性的第一个字段（中断类型）是否写错。Zynq的GIC中断号是从32开始编号的私有外设中断（PPI），共享外设中断（SPI）从32开始，但设备树中通常直接从32开始写，所以确认Vivado里分配的SPI ID和设备树中的值差32或0，是一个容易出错的细节。
8.3 调试信息打到UART Lite上的最佳实践
最后分享一个把内核调试信息输出到UART Lite的配置方法，这套方法在定位内核崩溃问题时非常高效。
在petalinux-config的Kernel bootargs中，设置完整的console参数：
console=ttyUL0,115200 earlycon=uartlite,0xa0000000其中earlycon=uartlite,0xa0000000是早期控制台参数，让内核在正式驱动加载前就能通过UART Lite输出早期启动信息。这里有一个注意事项：earlycon参数中的地址必须与设备树中reg属性一致，否则早期启动阶段不会有任何输出。
另外，如果同时存在标准UART和UART Lite，建议把调试信息输出到UART Lite，把应用程序数据留在标准UART。这样可以避免调试日志和应用数据混在一起互相干扰。
实际的做法是在Petalinux配置中设置：
petalinux-config在Subsystem AUTO Hardware Settings -> Serial Settings中，把Console device设置为uartlite0，同时把Application data device保持为psu_uart_0（或你的标准UART）。
这样配置后，系统启动日志走UART Lite，应用数据走标准UART，两者完全隔离。调试时只需要盯着UART Lite的终端窗口，干净利落。但要注意，在这种配置下，UART Lite的RX路径只在内核真正激活串口驱动后才可用，早期启动阶段只能用来看输出，不能输入交互。如果需要在内核启动早期输入命令（比如修改启动参数），还是得用标准UART做console。
这篇文章写到这里基本把AXI UART Lite调试的主要方法和思路都覆盖了。最后再分享一个小技巧：调试UART Lite时，手上常备一根短接杜邦线和一个USB转串口模块，前者用来做回环测试，后者用来排除板载串口芯片故障。这两样东西加起来不到二十元，但每次都能在关键时刻帮我快速缩小问题范围，强烈建议常备。
