企业官网建设流程全解析

简介：面向Zynq或Xilinx SDK平台的开发者，这份代码说明文档围绕AXI DMA的Loop模式，详细讲解了中断控制器与DMA引擎的配置、初始化以及中断处理流程，帮助理解高效数据传输的实现机制。压缩包内包含1个Word文档，文件体积仅42千字节，内容紧凑实用。文档从main函数入手，逐步拆解初始化子函数的调用关系，深入介绍了XScuGic与XAxiDma这两类关键结构体的成员含义，以及BD环在收发通道中的管理方式。针对DMA Loop操作，文档解释了传输完成后触发中断、重新填充描述符并启动下一轮传输的过程，还重点说明了中断向量表注册、中断优先级设置和DMA中断使能等初始化细节，并配有源码结构图示，便于对照实际工程理解。该资源已有161人学习，适合正在钻研Zynq DMA编程的工程师作为代码解读与故障排查的参考。文档篇幅虽短，但涵盖关键知识点。

1. AXI DMA LOOP 是在测什么：一个数据搬移闭环的起点

AXI DMA LOOP 这个名字，第一次接触的人容易把它理解成一个「回路测试小工具」，实际上它是一条完整的自测链路：处理器把一段数据放到内存里，启动 AXI DMA 的 MM2S 通道把数据搬出去，再通过另一条 S2MM 通道把数据搬回来，最后比对搬回来和搬出去的数据是否一致。这中间任何一个环节出错——地址没对齐、描述符没配好、通道没有按预期触发——都会导致校验失败，所以 LOOP 模式成了验证 AXI DMA IP 配置与驱动代码是否正确的最直接手段。本文围绕「AXI DMA LOOP SDK 代码说明」这个标题，把我自己在调试中实际用过的代码骨架、寄存器配置和踩坑记录整理出来。适合刚接触 AXI DMA 驱动的开发者，也适合那些 LOOP 测试总在某个边界条件下翻车的熟手。

2. 理解 SDK 代码前必须摸清的 IP 配置与地址映射关系

2.1 最小硬件配置与寄存器基地址

写 SDK 代码之前，先得知道硬件上 AXI DMA 核是怎么接出来的。一个能跑通 LOOP 的最小系统，通常包含三个组件：AXI DMA 核本身、一个用来接收 MM2S 写出去数据的 AXI Stream 端设备（常见做法是 FIFO 或者直接让 S2MM 通道回接）、以及 DDR 内存。我遇到过的多数 LOOP 工程里，硬件设计并不是让 MM2S 和 S2MM 直接对接，而是把两个通道挂到同一个 AXI4-Stream 网络上，这样数据从内存出来绕一圈又回到内存，链条长，但也更容易暴露问题。

寄存器基地址这一项，SDK 工程里没得选，只能从硬件地址映射表里读。我一般打开工程的 address map 文档，拿到 AXI DMA 的基地址后，先在头文件里做成宏：

#define AXI_DMA_BASE_ADDR 0x40400000 #define DMA_MM2S_CR 0x00 #define DMA_MM2S_SR 0x04 #define DMA_MM2S_CURDESC 0x08 #define DMA_MM2S_TAILDESC 0x0C #define DMA_S2MM_CR 0x30 #define DMA_S2MM_SR 0x34 #define DMA_S2MM_CURDESC 0x38 #define DMA_S2MM_TAILDESC 0x3C #define DMA_MM2S_SA 0x18 #define DMA_S2MM_DA 0x50

这个基地址 0x40400000 是我常用的例子，实际板卡上可能因为 PL 端地址分配不同而完全两样，不要在别人的例程上直接套用。MM2S 和 S2MM 的寄存器分组在 0x00~0x17 和 0x30~0x47 区间内，中间隔着一块未使用的保留区，初始化时不要往保留地址里写东西。每次配置之前，我都有一个习惯：先读一次对应通道的 SR 寄存器，确认 bit0（halted / idle 状态）是 1，再继续后面的操作。如果这里的值不符合预期，后面所有步骤都建立在错误状态上，排错会非常难受。

2.2 SDK 工程里必须做的三件事：地址表、复位时序、缓冲对齐

SDK 工程里跑 AXI DMA，代码量其实不大，但三个前置动作没做全，后面调起来就是黑匣子。

第一件事是导入地址表。SDK 的 platform 工程会从硬件平台的地址映射里自动生成 xparameters.h，里面会有类似 XPAR_AXIDMA_0_BASEADDR 这样的宏。不要自己写死地址，除非你很清楚板卡上 PL 地址段永远不会变。我习惯在代码里直接用 XPAR_ 开头的宏，这样换板子时只需要重新生成 platform，驱动代码一行都不用动。

第二件事是复位时序。AXI DMA 内部有一个复位过程，软件侧需要做的不是直接往 CR 寄存器里写，而是先确认复位信号已经释放。绝大多数情况下，复位由 PS 端的复位控制器管理，SDK 里要保证复位释放后延时若干微秒再操作 DMA 寄存器。我的做法是放一个毫秒级延时函数，在打开 DMA 句柄之后、配置描述符之前调用一次。

static void dma_reset_delay(void) { volatile int i; for (i = 0; i < 10000; i++) { /* 空循环等待硬件稳定 */ } }

第三件事是缓冲对齐。DMA 要求描述符和缓冲区地址按 8 字节对齐，如果是 64 位地址空间，最好按 8 字节或者更大的边界对齐。SDK 里分配内存用的函数可能只保证 4 字节对齐，我踩过的坑就是缓存区首地址不对齐导致传输地址非对齐，AXI DMA 直接报错。后来统一改成自定义对齐分配，见后面的代码。

2.3 描述符结构与 AXI DMA 的工作机制

AXI DMA 的传输不是处理器一个一个字节地搬，而是通过一串描述符来驱动。每个描述符 64 字节，放在一段连续内存里，描述符里记录着下一次要传输的缓冲区地址、传输长度、控制位和下一个描述符的地址。处理器需要做的只是把这一段描述符链的首地址写到 CURDESC 寄存器，再把尾描述符地址写到 TAILDESC 寄存器，DMA 就会自己沿着指针链表一直搬下去。

描述符里有几个关键位我单独记一下。bit0 是 VALID，描述符是否有效；bit1 是 EOF，这是不是最后一块；bit2 是 SOP，是不是第一块。MM2S 通道里，SOP/EOF 通常用来标记一段完整的流式数据边界，而 S2MM 通道写入时，DMA 会自动根据接收情况把这些状态位更新回来。LOOP 测试的核心，就是让 MM2S 发出一整段数据，S2MM 完整收下，然后代码检查 S2MM 的 SR 寄存器里的完成位和描述符里的状态位。

typedef struct { volatile uint32_t next_desc; volatile uint32_t next_desc_msb; volatile uint32_t buf_addr; volatile uint32_t buf_addr_msb; volatile uint32_t reserved[2]; volatile uint32_t control; volatile uint32_t status; volatile uint32_t app[4]; } axidma_bd_t;

这个结构体在代码里要放到一个 64 字节对齐的内存区，让 SDK 分配时用 cache 对齐或直接声明一个全局数组。描述符里 reserved 字段不要自作聪明去存东西，硬件会忽略，但也不保证它是 0。control 字段的 bit25 和 bit26 分别是 TXSOF 和 TXEOF，MM2S 通道要先设置好这两个位；status 字段是 DMA 完成回写用的，S2MM 通道会在这里反映接收完成状态。

3. 把第一版 LOOP 代码跑通：核心函数与逐段说明

3.1 描述符初始化与 MM2S 通道的启动

第一版 LOOP 代码不需要花哨，目标只有一个：让 MM2S 把一个 buffer 的数据发出去，S2MM 收到后再写回另一个 buffer。我先定义两个缓冲区，一个存发出去的数据，一个存收回来的数据，然后初始化描述符链。描述符数量不要一开始就用复杂的多段链表，先用一个描述符，传输完成与否看 SR 寄存器的 IOC_Irq 位即可。

#define BUF_SIZE 4096 #define BD_COUNT 1 static uint32_t tx_buf[BUF_SIZE / 4]; static uint32_t rx_buf[BUF_SIZE / 4]; __attribute__((aligned(64))) static axidma_bd_t bd[BD_COUNT]; static void init_single_bd(void) { memset((void *)bd, 0, sizeof(bd)); bd[0].buf_addr = (uint32_t)(uintptr_t)tx_buf; bd[0].buf_addr_msb = 0; bd[0].next_desc = 0; bd[0].next_desc_msb = 0; bd[0].control = BUF_SIZE | (1U << 25) | (1U << 26); }

注意第一次配置时，next_desc 如果只有一个描述符，直接填 0，表示这条链表只有一项。如果 BD_COUNT 大于 1，next_desc 要填下一个描述符的物理地址。DMA 本身不知道虚拟地址和物理地址的区别，SDK 在没有 MMU 的情况下两者一致，但如果跑在带虚拟内存的上下文里，就必须用物理地址，否则 DMA 会搬错地方。

MM2S 通道的启动顺序有讲究。先写 CR 寄存器打开通道，这个动作会把 halt 状态置成 run；然后再写 CURDESC 描述符地址；最后写 TAILDESC，告诉 DMA 从这一项开始执行。尾描述符这个寄存器的名字容易引起误会，它不是描述符链的结尾，而是告诉 DMA「从当前指针这个点继续往后的可用描述符到这项为止」。

static void start_mm2s_single_bd(void) { uint32_t cr; Xil_DCacheFlush(); /* 确保描述符和缓冲数据都刷到内存 */ cr = 0x1; /* RS 位：启动通道 */ AXI_DMA_WRITE(AXI_DMA_BASE_ADDR, DMA_MM2S_CR, cr); AXI_DMA_WRITE(AXI_DMA_BASE_ADDR, DMA_MM2S_CURDESC, (uint32_t)(uintptr_t)&bd[0]); AXI_DMA_WRITE(AXI_DMA_BASE_ADDR, DMA_MM2S_TAILDESC, (uint32_t)(uintptr_t)&bd[0]); }

这里的 AXI_DMA_WRITE 是一个读写寄存器宏，实际工程里我用的是某 SDK 自带的函数，本质就是*(volatile uint32_t *)(base + offset) = value。Xil_DCacheFlush 不能省，因为 DMA 读的是内存，如果描述符和缓冲区的数据还在 CPU 的 cache 里没有回写，DMA 搬出去的就是旧数据，这种问题在调试时表现得像「数据偶尔正确偶尔错误」。

static inline void AXI_DMA_WRITE(uint32_t base, uint32_t offset, uint32_t val) { *(volatile uint32_t *)(base + offset) = val; } static inline uint32_t AXI_DMA_READ(uint32_t base, uint32_t offset) { return *(volatile uint32_t *)(base + offset); }

启动完之后，不要立刻去读状态寄存器，DMA 需要若干周期来完成第一个描述符的搬运。我习惯的做法是轮询 SR 寄存器里的 bit12（IOC_Irq），最多等一个超时时间，超时了再去查 CURDESC 和状态位。这个轮询循环是 LOOP 测试里最常用的调试手段。

3.2 检查 S2MM 通道完成状态的几种方式

LOOP 链路中，S2MM 通道负责接收。它的配置和 MM2S 几乎一样，但要注意 CR 寄存器里 bit2 是 IOC_IrqEn，bit0 是 RS 位；接收方向不需要设置 SOP/EOF，因为描述符里要预留足够大的接收长度。我用一个描述符接收 BUF_SIZE 字节，如果硬件发过来的数据比预设的长度多，DMA 会丢掉多余的部分，并在状态里反映出来。

static void start_s2mm_single_bd(void) { uint32_t cr; bd[0].buf_addr = (uint32_t)(uintptr_t)rx_buf; bd[0].buf_addr_msb = 0; bd[0].next_desc = 0; bd[0].next_desc_msb = 0; bd[0].control = BUF_SIZE; /* 接收方向不需要 SOP/EOF */ Xil_DCacheFlush(); cr = 0x1; AXI_DMA_WRITE(AXI_DMA_BASE_ADDR, DMA_S2MM_CR, cr); AXI_DMA_WRITE(AXI_DMA_BASE_ADDR, DMA_S2MM_CURDESC, (uint32_t)(uintptr_t)&bd[0]); AXI_DMA_WRITE(AXI_DMA_BASE_ADDR, DMA_S2MM_TAILDESC, (uint32_t)(uintptr_t)&bd[0]); }

注意这里的技巧：在接收通道启动之前，先复用同一个 bd[0] 把缓冲地址改成 rx_buf。因为 LOOP 场景里收发各占一个方向，用同一个描述符表没问题，两个通道各自维护自己的描述符指针，不会打架。但如果你在代码里看到描述符表被两个通道共用且同时使用，就要注意接收通道可能刚启动就被发送通道的完成状态覆盖，这是并发访问的问题，一会儿在避坑章里展开。

检查是否接收完成，我用的是轮询 S2MM 的 SR 寄存器。SR 的 bit0 表示通道是否 halted，bit12 是 IOC_Irq，这个位置 1 表示传输完成一次。实际代码里我写成这样：

static int wait_s2mm_done(int timeout_ms) { uint32_t sr; volatile int delay; while (timeout_ms-- > 0) { sr = AXI_DMA_READ(AXI_DMA_BASE_ADDR, DMA_S2MM_SR); if (sr & (1U << 12)) { return 0; } for (delay = 0; delay < 1000; delay++) { /* 简易延时 */ } } return -1; }

轮询里还要注意一件事：每次读到的 SR 寄存器如果不是期望值，不要反复往 SR 里写 1 试图清中断位，那样会误清除其他状态。正确做法是先记录当前值，再决定写哪些位去清除。

3.3 数据校验方案：MEMCMP 之外我们还要查什么

LOOP 测试的最终目的是数据一致，但只做一次 memcmp 是不够的。常见做法是把 tx_buf 里填上一组有规律的数据，例如取模递增，这样即使 memcmp 说一致，我们也能判断收到的数据是不是从发送端转过来的，而不是恰好另一段内存本来就是一样的。

static void fill_test_data(uint32_t *buf, int len) { int i; for (i = 0; i < len / 4; i++) { buf[i] = (uint32_t)(i * 7 + 1); } } static int verify_data(uint32_t *tx, uint32_t *rx, int len) { int i; for (i = 0; i < len / 4; i++) { if (tx[i] != rx[i]) { return -1; } } return 0; }

排查时我还会额外看两样东西。第一样是 S2MM 描述符的 status 字段，它回写了实际收到的字节数，如果这个值不等于 BUF_SIZE，说明发生在流层面的截断或溢出，需要回头检查接收侧 IP 的位宽和总线的实际吞吐。第二样是 S2MM SR 的 bit7（SlaveErr），这个位一旦置 1，表示从设备侧的写响应出错，常见原因是时钟或复位没给好。只靠 memcmp 返回不通过，很难定位是通道问题还是数据源问题；加上这两项检查，可定位的范围会小很多。

4. 性能与稳定性：需要根据硬件改的参数在哪里

4.1 传输大小、描述符数量与缓存一致性问题

第一版跑通之后，第二个问题通常是我到底应该把 BUF_SIZE 设为多大，一个描述符够不够用。这里有一个基本权衡：描述符越多，DMA 越能连续搬大块数据，但描述符本身要占用内存，且每次启动都要初始化整条链表。我一般这样定：让单次传输不要超过 1MB，如果数据量大，拆成多个描述符，每个描述符固定 64KB，这样 DMA 每搬完一段就能更新一次状态，进度可见性更好。

缓存一致性在这类场景里是真正让人头疼的地方。处理器在 DDR 里写了数据，不刷 cache，DMA 读到的可能是旧值；DMA 写完接收缓冲，处理器读的时候如果 cache 里还留着脏数据，看到的是旧值。代码里 flush 和 invalidate 的时机必须卡在 DMA 启动前和完成标志置位后。

static void invalidate_rx_cache(void) { Xil_DCacheInvalidateRange((uint32_t)(uintptr_t)rx_buf, BUF_SIZE); }

一定记住 invalidate 是在确认接收完成之后做的，不能提前。提前 invalidate 意味着把当前 cache 里还没有写进内存的内容直接作废，轻则丢数据，重则触发异常。我早期就犯过这个毛病，数据校验一直不过，后来定位到是「先 invalidate 再等 DMA 完成」的顺序错了。

4.2 调整一次突发长度与数据位宽的影响

AXI DMA 的突发长度不是完全由核自己决定的，它受两个条件约束：一是 AXI 总线的最大突发长度，二是你在 IP 配置里指定的地址位宽和流位宽。SDK 代码里能改的是描述符里的 control 字段，其中 bit[13:0] 填的是传输字节数，而突发相关参数通常由 IP 配置决定，软件侧改不了太多。但这不代表软件无事可做。

如果 IP 配置时 Stream 数据位宽是 64 位，而每次传输的缓冲长度不是 8 的倍数，最后一拍的数据就包含无效字节。LOOP 测试里我把 BUF_SIZE 一直保持为 4 的倍数，但严谨来说要按流位宽的整数倍来设。64 位流位宽时建议按 8 的倍数，128 位时按 16 倍。这个细节很多人不看硬件配置就写死在代码里，换一块位宽不同的板子 LOOP 就偶发失败。

/* 实际编写时根据硬件位宽做一次粒度取整 */ #define STREAM_BYTE_WIDTH 8 /* 64-bit AXI-Stream */ #define ALIGN_SIZE 8 #define ROUND_UP(len) (((len) + ALIGN_SIZE - 1) / ALIGN_SIZE * ALIGN_SIZE)

ROUND_UP 宏的内容看起来简单，但作用很大：所有传给描述符的 buffer 长度都经过它处理，避免最后一拍的地址位不对齐。我在一个多通道的项目里多个设备共用同一段缓冲，当时没用这个宏，结果某一个不整除的 buffer 导致 DMA 搬到了错误地址，排查了很久才发现。

4.3 轮询和中断两种模式的选择边界

LOOP 这种验证场景，轮询确实省事，但太耗 CPU，而且如果 DMA 因为异常停下来，轮询会一直忙等。中断模式相对干净：DMA 完成一次传输后，通过中断通知 CPU，CPU 在回调里读取结果。实际数据传输的吞吐差别不大，但代码结构差很多。

LOOP 代码里若用中断，需要注册中断控制器、绑定中断 ID、启用通道的中断使能位。这里最关键的改动是 SR 寄存器读取后要主动清除中断标志，否则中断会永远触发。清标志的方式是向 SR 写入中断源对应的位写 1 清除，其他地方保持 0。

static void dma_isr(void *callback_ref) { uint32_t sr; sr = AXI_DMA_READ(AXI_DMA_BASE_ADDR, DMA_S2MM_SR); AXI_DMA_WRITE(AXI_DMA_BASE_ADDR, DMA_S2MM_SR, sr & 0x0001F000); /* 清除 IOC/Err 等状态位，同时保留 halted 等只读位 */ }

这段代码里只写高 13 位的可清位，不清 bit0 和 bit1，是一个值得保留的习惯。很多 SDK 里的驱动模板会把整片 SR 寄存器写回，遇到某个只读位在硬件上不可写的情况，容易把状态搞乱。

5. AXI DMA LOOP 常见问题排查：5 个踩过的坑

5.1 现象：MM2S 启动后通道立即报错

有一次我启动 MM2S 后，读 SR 寄存器的值直接显示 bit4（DecErr）和 bit5（SlaveErr）同时置 1。代码从启动到报错只有几个周期，连第一个描述符都没有正常处理。

原因是描述符地址没有按 64 字节对齐。当时我定义的是普通全局数组，编译器只保证了 4 字节对齐；AXI DMA 读描述符时一次取的数据位宽很大，非对齐描述符地址会触发 DecErr。解决方式有两个：给结构体数组加__attribute__((aligned(64)))，或者用专门的分配函数。我后来把描述符集中放在一个 DMA 专用内存池里，对齐问题从此再没出现过。

5.2 现象：S2MM 一直处于 busy 且描述符不更新

S2MM 启动后 SR 寄存器显示通道在运行，但描述符里的状态字段迟迟不被 DMA 更新，接收缓冲中永远是旧数据。

这个坑多半出在缓存一致性上：DMA 已经把数据写到了内存，但处理器读的时候 cache 命中旧值。解决方法是接收完成后对接收缓冲做 invalidate，而不是 flush。flush 是把 cache 里的脏数据写回内存，但 DMA 写的数据不在 cache 里，flush 之后处理器读 cache 还是旧值。

5.3 现象：数据偶尔错位、首尾多出几个字节

LOOP 里我最常碰到的校验失败场景，是数据整体往前或往后偏移了几个字节，或者最后一个描述符接收的实际字节数比设置的多。这类问题通常是发送侧和接收侧的 SOP/EOF 控制不一致导致的。

MM2S 描述符里同时设置了 SOP 和 EOF，但 Stream 数据在链路上被某些 IP 插入或消耗了额外的字节。比如某个 FIFO IP 在复位后自动插入了一个前导周期，或下游 IP 把最后一拍的空字节也当有效数据传回。检查时要对比两个方向描述符的 status 字段里实际传输字节数，多出来的几个字节往往能直接定位到下游 IP 的行为。

5.4 现象：中断触发后，读出的数据只有前半段正确

中断模式下出现这种情况，通常是因为接收完成中断触发后，代码立即读取数据，但读出的时刻 DMA 才刚刚写完一部分。中断响应是有延时的，理论上 CPU 读到中断时 DMA 已完成全部写入，但如果描述符数量多于一个，并且代码没有判断当前到底是哪一段描述符完成了，就会读到中间状态。

解决方式：中断回调里先读取所有描述符的状态，确认哪个描述符已置 IOC 位，再做对应的 invalidate 和校验。不要指望中断触发的那一瞬间全部数据都可见，尤其是多通道并发的时候。

5.5 现象：LOOP 单次能过，但连续跑几十次后失败

这种偶发问题最常见的原因就是没有正确处理描述符重用前的复位操作。当一轮 LOOP 完成，描述符 VALID 位和硬件维护的指针还保留着上一轮的残留状态。再次启动前需要把描述符清零、重填缓冲地址和控制位，并且把 S2MM 通道的 CR 寄存器重新写一遍 RS 位。忘掉这一步，第二轮启动时硬件可能从旧位置继续，校验自然失败。

6. 进阶技巧：用一个刷完状态寄存器的方法快速定位超时问题

LOOP 跑久了，我会在等待函数里加一个「快照寄存器」的思路：超时的时候不是只报一个超时错误，而是把 MM2S 和 S2MM 两个通道的 CR、SR、CURDESC、TAILDESC 一次性打印出来。这个习惯帮我解决过不少玄学问题。

static void dump_dma_state(void) { uint32_t cr0, sr0, cur0, tail0; uint32_t cr1, sr1, cur1, tail1; cr0 = AXI_DMA_READ(AXI_DMA_BASE_ADDR, DMA_MM2S_CR); sr0 = AXI_DMA_READ(AXI_DMA_BASE_ADDR, DMA_MM2S_SR); cur0 = AXI_DMA_READ(AXI_DMA_BASE_ADDR, DMA_MM2S_CURDESC); tail0 = AXI_DMA_READ(AXI_DMA_BASE_ADDR, DMA_MM2S_TAILDESC); cr1 = AXI_DMA_READ(AXI_DMA_BASE_ADDR, DMA_S2MM_CR); sr1 = AXI_DMA_READ(AXI_DMA_BASE_ADDR, DMA_S2MM_SR); cur1 = AXI_DMA_READ(AXI_DMA_BASE_ADDR, DMA_S2MM_CURDESC); tail1 = AXI_DMA_READ(AXI_DMA_BASE_ADDR, DMA_S2MM_TAILDESC); xil_printf("MM2S CR=%08x SR=%08x CUR=%08x TAIL=%08x\n", cr0, sr0, cur0, tail0); xil_printf("S2MM CR=%08x SR=%08x CUR=%08x TAIL=%08x\n", cr1, sr1, cur1, tail1); }

如果超时瞬间，CURDESC 已经走到 TAILDESC 指向的描述符之后，说明链已被消费完，问题很可能出在完成标志没被正确判断；如果 CURDESC 根本没动，说明通道没有真正启动。通过把 mm2s 和 s2mm 分开打印，两个通道各自的进度就一目了然。

超时处理还有一个容易被忽略的操作：超时后要把两个通道都停掉，将 CR 寄存器的 RS 位清零，再重新复位，不能直接在超时状态下重新启动。我会在超时分支里先执行halt_dma()，再等几十毫秒让 AXI 总线上残留的事务清空，最后才重新初始化描述符。

static void halt_dma(void) { uint32_t cr; cr = AXI_DMA_READ(AXI_DMA_BASE_ADDR, DMA_MM2S_CR); AXI_DMA_WRITE(AXI_DMA_BASE_ADDR, DMA_MM2S_CR, cr & ~0x1U); cr = AXI_DMA_READ(AXI_DMA_BASE_ADDR, DMA_S2MM_CR); AXI_DMA_WRITE(AXI_DMA_BASE_ADDR, DMA_S2MM_CR, cr & ~0x1U); }

开发调试频次高的时候，我会把 dump_dma_state 直接集成进超时分支，这样每次失败现场都有完整快照。后来几个项目里，这个函数成了所有 DMA 调试的入口，几乎每个定位问题都是从这八个数开始的。一次连续的偶发失败，靠这个快照发现 S2MM 的 SR 里一直带着一个未清除的复位残留位，清掉后连续跑了上万次也没再出问题。以后你接手这类 LOOP 调试，建议先把状态快照放进第一版代码里，它比任何猜测都可靠。希望帮到你。

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