8250串口回环测试：从寄存器级验证到压力时序分析

1. 为什么8250串口回环测试不是“点个按钮就完事”的事

在嵌入式Linux开发现场，我见过太多人把“串口回环测试”当成一个验证驱动是否加载成功的仪式性动作——插上USB转串口线，dmesg | grep tty看到ttyUSB0出来了，stty -F /dev/ttyUSB0 115200配一下波特率，再用echo "test" > /dev/ttyUSB0和cat /dev/ttyUSB0对着敲两下，看到字符回显了就拍手：“通了！”然后转身去调应用层逻辑。结果三天后发现设备在高温环境下偶发丢包，日志里全是overrun和frame error，查到最后，问题根源恰恰出在当初那个“通了”的回环测试根本没跑满压力、没覆盖边界条件、更没验证硬件级信号完整性。

8250不是一块抽象的UART IP核，它是一套有血有肉的寄存器交互协议，一套受制于物理层电气特性的通信链路，一套在Linux内核中被serial_core、8250_port、8250_dma多层封装的驱动栈。所谓“软件回环测试”，本质是绕过物理TX/RX引脚，让发送数据直接在驱动内部跳转到接收缓冲区，从而隔离硬件故障，专注验证驱动逻辑、中断响应、FIFO管理、DMA搬运、流控机制这一整条软件路径。它不测线缆质量，不测电平匹配，但必须测清：当每秒涌进10万字节数据时，uart_insert_char()会不会丢帧？当THRE（发送保持寄存器空）中断被延迟3ms触发时，8250_tx_empty()返回值是否仍准确？当IIR（中断识别寄存器）连续两次读取值不一致时，驱动能否正确判别中断源？这些，才是8250回环测试真正的靶心。

你搜到的“串口烧写失败”“串口数据记录仪使用”“linux从串口接收数据丢失”，背后90%都卡在回环测试没做扎实。比如CH340驱动在国产Linux发行版上常因CONFIG_USB_SERIAL_CH341未启用或usbcore.autosuspend=-1未设置导致枚举不稳定；AXU15EGP系列开发板的8250兼容性补丁若未合入内核，回环测试会卡在uart_startup()的serial8250_request_irq()环节；而STM32F103C8T6串口通信调试中，若未关闭RTS/CTS硬件流控，回环模式下MCR寄存器的RTS位状态异常就会引发接收中断紊乱。这些都不是minicom能暴露的问题——它们只在你把回环测试跑成压力测试、边界测试、时序测试时才会浮出水面。

所以，本文不教你怎么用screen /dev/ttyS0 115200连上串口，而是带你亲手编译一个能精准控制8250寄存器、能注入特定错误条件、能采集毫秒级时序数据的回环测试工具。它要能验证：驱动是否真的理解IER（中断使能寄存器）每一位的语义？LSR（线路状态寄存器）的DR（数据就绪）标志是否在数据写入RBR（接收缓冲寄存器）后立即置位？THR（发送保持寄存器）在THRE为1时是否允许写入？这才是嵌入式工程师该有的回环测试深度。

1.1 8250回环模式的两种实现层级：硬件级 vs 软件级

很多人混淆“硬件回环”和“软件回环”。硬件回环是用杜邦线把开发板的TX引脚直连RX引脚，信号真真切切走了一遍RS232/RS485电平转换芯片、经过了ESD保护二极管、穿越了PCB走线阻抗——它测的是整个物理链路，包括电平匹配、共模抑制、信号反射。而软件回环（Software Loopback），是8250 UART IP核内置的一种调试模式，通过向MCR（Modem Control Register）的第4位（LOOP）写1来激活。此时，芯片内部逻辑将THR写入的数据直接路由至RBR，完全绕过TX引脚驱动电路和RX引脚采样电路。它不经过任何外部器件，只验证UART IP核的寄存器逻辑和驱动对LOOP位的控制能力。

提示：MCR寄存器地址为offset 0x04，其bit4（LOOP）置1即开启回环。但注意，某些老旧8250兼容芯片（如部分PL011变种）可能不支持此位，需查阅具体IP手册确认。AXU15EGP系列开发板使用的Synopsys DesignWare UART，其MCR定义与标准8250一致，可放心使用。

软件回环的价值在于“可控性”。你可以精确控制：何时开启回环（避免干扰正常通信）、开启后是否仍响应RTS/CTS（测试流控逻辑）、LSR的OE（溢出错误）位是否被屏蔽（验证错误处理路径）。而硬件回环无法关闭TX驱动，也无法阻止真实信号干扰其他外设。这也是为什么Linux内核的8250驱动在serial8250_start_tx()中会检查up->port.flags & UPF_SOFT_FLOW，并在回环模式下跳过set_mctrl()对MCR的修改——它必须确保软件回环的纯净性。

实测中，我曾用逻辑分析仪对比两种模式：硬件回环下，TX引脚有真实电平翻转，RX引脚在1.2ms后采样到数据；软件回环下，TX引脚电平纹丝不动，RX引脚无任何变化，但RBR在THR写入后23ns内即被更新。这个23ns，就是驱动调用serial_out(up, UART_TX, ch)到serial_in(up, UART_RX)读取的纯软件延迟，它直接反映了ioremap内存映射的效率和spin_lock临界区的长度。这才是回环测试要捕获的核心数据。

1.2 为什么Linux下的8250回环测试必须绕过TTY层

当你执行echo "hello" > /dev/ttyS0时，数据并非直接写入8250的THR寄存器。它要先经过完整的TTY子系统：tty_write()→n_tty_write()→tty_ldisc_receive()→uart_write()→serial8250_tx_chars()→serial_out()。这条路径上，n_tty线路规程会做回车换行转换（\n→\r\n），icanon模式会缓存输入直到回车，OPOST标志会触发输出后处理。这些中间环节，会掩盖底层UART驱动的真实行为。

例如，若8250驱动的tx_fifo_size被错误配置为16（实际硬件FIFO是64字节），在高负载下serial8250_tx_chars()会因uart_circ_chars_pending()返回值不准而频繁触发中断，但echo命令因n_tty的缓冲机制，可能让你误以为“一切正常”。只有绕过TTY层，直接mmapUART寄存器内存空间，用writeb()逐字节写THR、用readb()逐字节读RBR，才能暴露tx_fifo_size配置错误导致的THRE中断抖动问题。

这也是为什么setserial命令虽能设置loopback标志（setserial /dev/ttyS0 loopback），但它只是通知内核驱动进入回环模式，并未提供直接寄存器访问能力。真正的深度测试，需要/dev/mem权限或编写内核模块。考虑到安全性和便捷性，我们选择前者：用mmap()映射/dev/mem中UART控制器的物理地址，这正是嵌入式工程师调试硬件最原始也最有效的方式。AXU15EGP开发板的UART0物理地址为0x80000000，偏移0x1000，这个地址你必须从板级文档《AXU15EGP Hardware Reference Manual》第3.2.1节获取，而非凭经验猜测。

注意：使用/dev/mem需root权限，且现代Linux发行版默认禁用。需在内核启动参数中添加iomem=relaxed，或临时执行echo 0 > /proc/sys/kernel/kptr_restrict。这是安全红线，务必在测试环境操作，生产环境严禁开放/dev/mem。

2. 手把手构建可编程的8250寄存器级回环测试框架

要真正掌控8250回环测试，必须抛弃minicom、screen这类终端模拟器，构建一个能直接读写寄存器、能注入时序扰动、能采集量化指标的C语言测试框架。这个框架不是玩具，它要能跑在ARM64的AXU15EGP开发板上，也能适配x86_64的Ubuntu虚拟机（通过QEMU模拟8250），核心是统一的寄存器访问抽象层。

2.1 寄存器映射与基础访问函数：避开内核API的陷阱

Linux内核提供了serial_in()/serial_out()这样的辅助函数，但它们被封装在drivers/tty/serial/8250/8250_port.c中，用户态不可见。我们必须自己实现。关键在于理解8250的寄存器布局：

注意：RBR和THR共享同一地址0x00，读操作返回RBR，写操作写入THR。IER和DLM共享0x01，但LCR[7]（DLAB位）决定访问哪个——LCR[7]=1时访问DLL/DLM，LCR[7]=0时访问RBR/THR/IER。这是8250最易出错的设计点。

我们的基础访问函数这样设计：

// uart_reg.h #define UART_RBR 0x00 #define UART_THR 0x00 #define UART_IER 0x01 #define UART_IIR 0x02 #define UART_FCR 0x02 #define UART_LCR 0x03 #define UART_MCR 0x04 #define UART_LSR 0x05 #define UART_MSR 0x06 #define UART_SCR 0x07 static inline uint8_t uart_readb(volatile void *base, int offset) { return *(volatile uint8_t *)(base + offset); } static inline void uart_writeb(volatile void *base, int offset, uint8_t val) { *(volatile uint8_t *)(base + offset) = val; }

这里不用ioread8()，因为ioread8()是内核函数。用户态必须用volatile指针强制内存访问，防止编译器优化掉看似“无用”的读写。volatile是铁律——没有它，uart_readb(base, UART_LSR)可能被优化成常量，导致永远读不到实时的LSR状态。

2.2 初始化流程：从波特率计算到回环使能的完整链路

初始化不是简单地写几个寄存器。它是一套严格的时序协议。以AXU15EGP的UART0为例，其输入时钟为50MHz，目标波特率为115200：

1. 计算除数：divisor = clock_rate / (16 * baud_rate) = 50000000 / (16 * 115200) ≈ 27.127→ 取整27。
2. 设置DLAB：先写LCR[7]=1，使能DLL/DLM访问。
3. 写除数：DLL = divisor & 0xFF = 0x1B，DLM = (divisor >> 8) & 0xFF = 0x00。
4. 恢复LCR：写LCR = 0x03（8位数据、1停止位、无校验），此时LCR[7]=0，DLL/DLM锁存。
5. 使能中断：IER = 0x01（仅使能RDI接收数据中断），但回环测试初期可全关IER=0x00，避免中断干扰。
6. 开启回环：MCR = 0x10（仅置位LOOP位，其他位清零）。
7. 验证LSR：读LSR，应为0xC1（DR=1表示RBR有数据，THRE=1表示THR空，TEMT=1表示发送器空）。

这段流程必须严格按顺序执行。我曾因在LCR写入前未清DLAB，导致DLL写入无效，波特率始终是默认的9600。代码实现如下：

// uart_init.c int uart_init(volatile void *base, unsigned int baudrate, unsigned int clock_rate) { uint32_t divisor = clock_rate / (16 * baudrate); uint8_t lcr_val = 0x03; // 8N1 // Step 1: Set DLAB to access DLL/DLM uart_writeb(base, UART_LCR, lcr_val | 0x80); // Step 2: Write DLL and DLM uart_writeb(base, UART_RBR, divisor & 0xFF); // DLL at offset 0x00 uart_writeb(base, UART_IER, (divisor >> 8) & 0xFF); // DLM at offset 0x01 // Step 3: Clear DLAB, set final LCR uart_writeb(base, UART_LCR, lcr_val); // Step 4: Disable all interrupts initially uart_writeb(base, UART_IER, 0x00); // Step 5: Enable loopback mode uart_writeb(base, UART_MCR, 0x10); // LOOP bit only // Step 6: Verify LSR status uint8_t lsr = uart_readb(base, UART_LSR); if ((lsr & 0xC1) != 0xC1) { fprintf(stderr, "UART init failed: LSR=0x%02x\n", lsr); return -1; } return 0; }

提示：LSR的0xC1掩码是关键。0xC0对应DR和THRE，0x01对应TEMT。三者同时为1，证明UART已就绪且回环生效。若DR=0，说明RBR为空，回环未触发；若THRE=0，说明THR未空，发送未完成。

2.3 核心测试逻辑：发送-接收-校验的原子循环

回环测试的原子单元是“发送一字节→等待THRE→读取RBR→比对”。但THRE（发送保持寄存器空）标志的置位时机，取决于THR是否被硬件移入移位寄存器。在回环模式下，这个过程是瞬时的，但驱动必须等待THRE为1才能写入下一字节，否则THR会丢失。

我们的测试循环这样设计：

// loopback_test.c int loopback_test(volatile void *base, const uint8_t *tx_buf, size_t len) { size_t i; uint8_t rx_byte; uint8_t lsr; for (i = 0; i < len; i++) { // Wait for THR to be empty (THRE=1) do { lsr = uart_readb(base, UART_LSR); } while (!(lsr & 0x20)); // LSR[5] = THRE // Write byte to THR uart_writeb(base, UART_THR, tx_buf[i]); // Wait for data to appear in RBR (DR=1) // In loopback, this should be immediate, but poll to be sure do { lsr = uart_readb(base, UART_LSR); } while (!(lsr & 0x01)); // LSR[0] = DR // Read RBR rx_byte = uart_readb(base, UART_RBR); // Compare if (rx_byte != tx_buf[i]) { fprintf(stderr, "Mismatch at pos %zu: expected 0x%02x, got 0x%02x\n", i, tx_buf[i], rx_byte); return -1; } } return 0; }

这个循环的精妙之处在于双重等待：先等THRE，再等DR。它模拟了真实通信中发送与接收的解耦。如果省略THRE等待，连续快速写THR会导致THR被覆盖，数据丢失；如果省略DR等待，RBR可能还未更新就读取，得到旧值。我在STM32F4的UART测试中就遇到过类似问题：HAL_UART_Transmit()内部未严格等待TXE标志，导致高速传输时丢字节。

3. 深度压力测试：用时间戳揭露8250驱动的隐藏缺陷

通过基础回环测试只能证明“能通”，而压力测试才能证明“稳”。我们要用纳秒级时间戳，测量每个字节从写入THR到读取RBR的延迟（thr_to_rbr_latency），并统计其分布。这个延迟直接反映驱动的中断响应、寄存器访问、FIFO管理效率。

3.1 高精度时间戳采集：clock_gettime(CLOCK_MONOTONIC_RAW)的实战应用

gettimeofday()精度只有微秒级，且受系统时间调整影响。CLOCK_MONOTONIC_RAW提供纳秒级精度，且不受NTP调整，是测量硬件延迟的黄金标准。在AXU15EGP上，clock_gettime()调用开销约85ns，远小于UART延迟（典型值200-500ns），可忽略。

测试代码片段：

struct timespec start, end; uint64_t latency_ns; // Before writing THR clock_gettime(CLOCK_MONOTONIC_RAW, &start); uart_writeb(base, UART_THR, tx_byte); // Wait for DR do { lsr = uart_readb(base, UART_LSR); } while (!(lsr & 0x01)); // After reading RBR clock_gettime(CLOCK_MONOTONIC_RAW, &end); latency_ns = (end.tv_sec - start.tv_sec) * 1000000000ULL + (end.tv_nsec - start.tv_nsec);

注意：clock_gettime()必须在uart_writeb()之后、uart_readb()之前调用start，在uart_readb()之后调用end。任何中间操作（如printf）都会污染测量。我曾因在end后加了fprintf()，导致测量值虚高3000ns，误判为DMA延迟过大。

3.2 压力模式设计：三类典型负载场景

我们设计三种压力模式，覆盖嵌入式常见工况：

1. 突发负载（Burst Load）：一次性发送1024字节，测量每个字节的thr_to_rbr_latency。理想情况下，前几字节延迟高（FIFO填充），中间字节延迟稳定（FIFO满速），末尾字节延迟略升（FIFO排空）。若出现“锯齿状”波动，说明8250驱动的tx_empty()判断不准，或IRQ处理有抖动。

2. 持续负载（Sustained Load）：以115200bps速率，连续发送10MB数据，每1000字节统计一次平均延迟和标准差。若标准差>50ns，表明中断响应不均，可能与CONFIG_NO_HZ或irq_affinity配置有关。AXU15EGP开发板上，将UART IRQ绑定到CPU1（echo 2 > /proc/irq/$(cat /sys/class/tty/ttyS0/device/irq)/smp_affinity_list）后，标准差从120ns降至22ns。

3. 混合负载（Mixed Load）：在发送数据的同时，用ioctl(TIOCMGET)频繁读取MSR寄存器（Modem Status）。这模拟了真实场景中，应用层同时进行数据收发和状态查询。若MSR读取导致THR写入延迟突增，说明8250_port的spin_lock粒度太粗，需检查up->port.lock的持有范围。

实测数据表格（AXU15EGP, 115200bps）：

混合负载失败，定位到serial8250_get_mctrl()函数中，spin_lock(&up->port.lock)持有时间过长。解决方案是将MSR读取改为无锁方式，直接serial_in(up, UART_MSR)，因为MSR是只读寄存器，无需互斥。

3.3 错误注入测试：主动制造LSR异常状态

真实世界中，LSR会报告OE（溢出）、PE（奇偶错误）、FE（帧错误）。回环测试必须验证驱动能否正确处理这些错误。我们主动注入：

• 溢出错误（OE）：在RBR满时（LSR[0]=1且RBR有数据），连续写THR而不读RBR，迫使硬件丢弃新数据并置位LSR[1]。
• 帧错误（FE）：修改LCR，设置STOP=0（5位停止位），然后发送标准8N1数据，LSR[4]将置位。
• 奇偶错误（PE）：设置LCR[4]=1（偶校验），发送奇数个1的数据，LSR[2]将置位。

测试代码：

// Inject OE: fill RBR, then write THR uart_writeb(base, UART_THR, 0xAA); usleep(1000); // Let it loop back // Now RBR has 0xAA, but don't read it uart_writeb(base, UART_THR, 0xBB); // This should cause OE usleep(1000); uint8_t lsr = uart_readb(base, UART_LSR); if (lsr & 0x02) { // OE bit printf("OE injected successfully\n"); }

驱动必须在serial8250_interrupt()中检查lsr & UART_LSR_OE，并调用uart_insert_char()传入TTY_OVERRUN标志。若驱动忽略OE，上层应用将永远收不到错误通知，数据完整性无法保障。

4. 实战排错：从“串口烧写失败”到回环测试的根因定位链

当项目中出现“串口烧写失败”这类现象，90%的工程师第一反应是换线、重装CH340驱动、检查stty设置。但真正的根因，往往藏在回环测试的某个细节里。下面是我处理过的三个真实案例，展示如何用回环测试构建完整的排查链路。

4.1 案例一：CH340在国产Linux上“时好时坏”的真相

现象：Ubuntu 22.04上CH340工作正常，但在某国产Linux发行版（基于4.19内核）上，dmesg显示ch341-uart converter now attached to ttyUSB0，但echo "a" > /dev/ttyUSB0无响应，cat /dev/ttyUSB0也无回显。

排查链路：

1. 基础回环验证：setserial /dev/ttyUSB0 loopback，再echo "test" > /dev/ttyUSB0 && cat /dev/ttyUSB0。结果：无回显 → 问题在驱动层，非应用层。
2. 寄存器级测试：用前述C框架，mmapCH340的/dev/bus/usb/001/002（需usbfs挂载），直接读0x02（中断端点）状态。发现urb_submit后，interrupt urb从未完成 → USB底层通信异常。
3. 内核日志深挖：dmesg | grep -i "ch341"，发现ch341_set_baudrate: unsupported baud rate 115200。原来该发行版内核的ch341驱动未合入2019年后的baud rate补丁，115200被拒绝。
4. 终极验证：改用9600波特率运行回环测试，thr_to_rbr_latency稳定在320ns → 确认是波特率支持问题。

解决方案：升级内核或打补丁drivers/usb/serial/ch341.c，添加115200到ch341_baud_rates[]数组。这个补丁在主线内核5.4+已存在，但国产发行版常滞后。

4.2 案例二：AXU15EGP开发板“接收数据丢失”的硬件级定位

现象：AXU15EGP板载UART0，在115200波特率下，cat /dev/ttyS0能收到数据，但用dd if=/dev/urandom of=/dev/ttyS0 bs=1024 count=100发送大数据块时，接收端dd if=/dev/ttyS0 of=recv.bin bs=1024 count=100得到的文件比发送的少3-5KB。

排查链路：

1. 关闭所有上层：systemctl stop serial-getty@ttyS0.service，stty -F /dev/ttyS0 raw -echo，排除getty和n_tty干扰。
2. 寄存器级压力测试：用C框架发送1MB数据，每1000字节校验一次。发现第234000字节开始，thr_to_rbr_latency从320ns骤增至12000ns，且LSR的OE位被频繁置位。
3. 硬件信号抓取：用逻辑分析仪接UART0的TX/RX引脚，发现TX波形在第234000字节处出现严重失真，上升沿变缓。
4. 根因锁定：检查原理图，发现UART0的TX引脚串联了一个10kΩ上拉电阻，而驱动能力不足。更换为1kΩ后，失真消失，OE位不再置位。

回环测试在此案中的价值是：它把“数据丢失”这个模糊现象，精准定位到“第234000字节”，从而将排查范围从软件缩小到硬件信号完整性。

4.3 案例三：STM32F103C8T6“串口通信不稳定”的时序陷阱

现象：STM32F103C8T6的USART1，在FreeRTOS任务中调用HAL_UART_Transmit()发送数据，偶尔出现首字节丢失。

排查链路：

1. 最小化复现：裸机工程，主循环中HAL_UART_Transmit(&huart1, "A", 1, HAL_MAX_DELAY)，用示波器看TX波形。发现每次发送前，TX引脚有约1.5us的低电平毛刺。
2. 回环模式对照：将USART1配置为回环模式（__HAL_USART_ENABLE_IT(&huart1, USART_IT_TC)），发送"A"，读取RDR。毛刺消失 → 问题与物理层无关，是驱动初始化时序问题。
3. 寄存器级审计：查看HAL_UART_Init()源码，发现它在__HAL_UART_ENABLE(&huart1)后，立即调用__HAL_UART_SEND_REQ(&huart1, UART_TX_REQ)。但STM32的参考手册明确要求：UE（USART使能）置位后，需等待TC（传输完成）标志或至少1个APB时钟周期，才能发起发送请求。
4. 修复方案：在HAL_UART_Init()后插入__HAL_UART_CLEAR_FLAG(&huart1, UART_FLAG_TC);，并等待TC置位，再开始发送。

这个案例揭示：回环测试不仅是功能验证，更是时序合规性审计。它强迫你直面芯片手册的每一个时序要求，而不是依赖“大概率能工作”的侥幸。

5. 进阶技巧：让8250回环测试成为你的嵌入式开发“听诊器”

回环测试不应止步于“通”或“不通”，而应成为你诊断整个嵌入式系统健康状况的“听诊器”。以下是我在十年实战中沉淀的三个高阶技巧，它们让回环测试从验证工具升维为系统洞察引擎。

5.1 技巧一：用回环延迟反推CPU负载与调度延迟

thr_to_rbr_latency不仅反映UART性能，更是CPU实时性的晴雨表。在AXU15EGP上，我建立了一套基线模型：空闲状态下，thr_to_rbr_latency均值为320±20ns；当stress-ng --cpu 4 --timeout 60s压满CPU时，均值升至410±180ns。这个180ns的标准差，就是调度抖动的量化体现。

更进一步，我将回环测试集成到系统监控脚本中：

# monitor_uart.sh while true; do latency=$(./uart_test --mode=latency --count=1000 | awk '{sum+=$1} END {print sum/NR}') if (( $(echo "$latency > 500" | bc -l) )); then echo "$(date): UART latency high ($latency ns), triggering full system dump" # Trigger perf record, collect stack traces perf record -e 'sched:sched_switch' -g -o /tmp/perf.data & fi sleep 5 done

当latency持续超过500ns，说明系统存在严重的调度延迟或中断风暴。这比单纯看top的%CPU更有针对性——它告诉你，实时任务的确定性正在崩塌。在一次客户现场，正是这个脚本提前2小时预警了usb-storage驱动的中断风暴，避免了产线设备停机。

5.2 技巧二：回环测试与DMA协同，验证零拷贝路径

现代8250驱动普遍支持DMA（如8250_dw）。回环测试必须验证DMA路径是否真正启用。方法是：在uart_init()后，读取/sys/class/tty/ttyS0/device/dma-status，确认tx_dma和rx_dma为active；然后用perf stat -e dma/dma-write, dma/dma-read/ ./uart_test --mode=dma_burst，观察DMA事务计数。

关键洞察：若DMA启用，thr_to_rbr_latency应显著降低（从320ns降至180ns），且latency分布更集中（标准差<10ns）。若latency未降，说明DMA未生效，可能原因有：CONFIG_SERIAL_8250_DMA=y未配置、dma-ranges在设备树中未正确定义、或dma_slave_config的direction设错（DMA_MEM_TO_DEVvsDMA_DEV_TO_MEM）。

我在移植AXU15EGP的dw-apb-uart驱动时，就因设备树中dma-ranges = <0x00000000 0x00000000 0x40000000>写错为<0x00000000 0x00000000 0x10000000>，导致DMA地址映射失败，回环测试latency毫无改善，perf显示零DMA事务。

5.3 技巧三：构建“回环-硬件”联合测试矩阵

最终极的测试，是让软件回环与硬件回环形成闭环验证。步骤如下：

1. 在开发板上，用跳线将UART0