测试日期：2026-10-13
补充日期：2026-10-14（北京时间）
用途：记录 fio 大容量连续写入和两轮 DDAQ 实际连续采集结果，分析丢点位置，并明确下一步定位计划。连续采集终端时间为 UTC（+0000）；第二轮 16:34:38～16:44:38 UTC 对应北京时间 2026-10-14 00:34:38～00:44:38。
err=0。INCOMPLETE / exit=1 结束，尚未通过 15 分钟连续采集无丢点验证。adc_to_dma 接收新采样的入口。下游瞬时阻塞导致反压是首要排查假设，尚未证实；输入突发仍未排除。不能据此认定 DMA、DDR、SDK 或 SSD 完全没有问题。| 项目 | 本次记录 |
|---|---|
| 平台 | DDAQ Zynq UltraScale+ MPSoC 开发板，PetaLinux 系统 |
| SSD | ZHITAI TiPlus7100s 2TB |
| 设备 | /dev/nvme0n1 |
| 设备容量 | 2,048,408,248,320 字节，lsblk 显示约 1.9T |
| PCIe 链路 | Link UP；5.0GT/s ×4，即 PCIe 2.0 ×4 |
| PCIe 日志带宽 | 16.000 Gb/s available PCIe bandwidth；不是文件写入速度 |
| NVMe 初始化 | 分配 64MiB Host Memory Buffer，4/0/0 default/read/poll queues |
| 文件系统 | 整盘 ext4，不创建分区；块大小 4096 字节 |
| 文件系统标签 | DDAQ_NVME |
| UUID | 6dd81c69-89e5-463b-aa59-c0309137a785 |
| 挂载点 | /mnt/TiPlus7100s |
| 测试前空间 | df -h 显示总量 1.8T、已用 32.0K、可用 1.8T |
| fio | 3.32，支持 libaio |
硬盘此前未挂载，具有 DOS/MBR 签名但未列出分区。确认目标后，直接在整块 NVMe 上建立 ext4 文件系统，格式化输出包含 Discarding device blocks: done，之后完成挂载。系统仍运行在 SD 卡上。
本次未单独记录内核版本、SSD 固件版本、温度、SMART 状态、散热条件及上电前使用历史，不能据此确定掉速的具体原因。
工作负载为单任务、1MiB 大块顺序写入，使用 libaio 异步引擎，队列深度 32。测试按写入量结束，不设置 900 秒时间限制。
FIO_DIR="/mnt/TiPlus7100s/fio_test_$(date +%Y%m%d_%H%M%S)"
sudo mkdir "$FIO_DIR" && sudo fio \
--name=nvme_seq_write \
--filename="$FIO_DIR/write_test.bin" \
--rw=write --bs=1M \
--ioengine=libaio --iodepth=32 --numjobs=1 \
--direct=1 --size=1536G \
--end_fsync=1 --group_reporting \
--write_bw_log="$FIO_DIR/write" --log_avg_msec=1000 \
--output="$FIO_DIR/result.txt" --eta=always
direct=1 绕过 Linux 页缓存，不绕过 SSD 内部缓存。1536G 在本命令的默认单位设置下为 1536GiB，即 1.5TiB；不是十进制 1.5TB。end_fsync=1 在写入阶段结束后同步文件。本次没有启用数据读回校验。log_avg_msec=1000 保存约每秒的平均带宽，不是瞬时最低速度。| 指标 | 结果 |
|---|---|
| 实际写入量（fio 总计） | 1536GiB，约 1649GB |
| fio 运行时间 | 1,079,835ms，即 17 分 59.835 秒 |
| 全程平均写入带宽 | 1457MiB/s，约 1527MB/s |
| 平均 IOPS | 1456；写入块大小为 1MiB |
| fio 带宽统计最低值 | 717MiB/s，约 752MB/s |
| fio 带宽统计最高值 | 报告取整为 1596MiB/s；日志最大约 1596.6MiB/s |
| I/O 完成延迟平均值 | 21.652ms（clat，异步队列下的请求完成延迟） |
| I/O 完成延迟最大值 | 94.219ms |
| 队列深度分布 | 深度 32 占 100.0%（报告四舍五入） |
| 错误 | err=0；short=0、dropped=0 为 fio I/O 统计，不是 DDAQ 丢样计数 |
| 内核日志检查 | 提供的筛选日志中未见 NVMe 超时、链路重置或 I/O error |
Disk stats 中 util=100.00% 表示本次测试期间设备持续繁忙，不应单凭此值认定硬盘发生故障或已达到所有工作负载的性能极限。
下表是同一次连续写入中，累计写入量增长与速度的关系，不是对不同大小文件分别进行独立测速。 本次顺序写入单个文件，因此累计写入量也近似对应文件中已写到的位置；文件可能提前分配空间，不能用 ls -lh 显示的大小判断实时写入进度。
| 累计写入量区间（GiB，估算） | 写入时间区间（秒，约） | 区间平均速度（MiB/s） | 区间平均速度（MB/s） | 状态 |
|---|---|---|---|---|
| 0～256 | 0～168 | 1562.4 | 1638.3 | 高速 |
| 256～512 | 168～336 | 1555.1 | 1630.6 | 高速 |
| 512～768 | 336～505 | 1552.0 | 1627.4 | 高速 |
| 768～1024 | 505～674 | 1551.4 | 1626.8 | 高速 |
| 1024～1280 | 674～842 | 1559.8 | 1635.6 | 高速 |
| 1280～1408 | 842～926 | 1567.1 | 1643.3 | 高速 |
| 1408～1431 | 926～941 | 1567.6 | 1643.8 | 掉速前仍保持高速 |
| 1431～1440 | 941～952 | 825.5 | 865.6 | 包含掉速过渡 |
| 1440～约1536（结束） | 952～1079 | 778.0 | 815.8 | 持续低速，未恢复 |
带宽 × 时间间隔 积分，估算累计写入量。跨越容量分段边界时，在该秒内按平均带宽线性插值。| 日志时间 | 该采样窗口平均速度（MiB/s） |
|---|---|
| 940 秒（15分40秒） | 1570.00 |
| 941 秒（15分41秒） | 1570.57 |
| 942 秒（15分42秒） | 1097.00 |
| 943 秒（15分43秒） | 833.83 |
| 944 秒（15分44秒） | 799.00 |
| 945 秒（15分45秒） | 805.81 |
第 942 秒的平均值已经明显降低，所以转折发生在约 941～942 秒这一采样窗口内，不能定位到更精确的瞬间。
日志能证明持续掉速现象，但不能单独证明 SLC 缓存容量或缓存耗尽，也不能排除温度、后台整理、剩余空间及其他因素。
若采样率为每通道 2MS/s、每个通道样点保存 2 字节，且数据帧没有额外开销，则：
| 有效存盘通道数 | 数据率（MB/s） | 15 分钟数据量（GB） |
|---|---|---|
| 32 | 128 | 115.2 |
| 96（两轮实采 ACTIVE 配置） | 384 | 345.6 |
| 128 | 512 | 460.8 |
| 160 | 640 | 576.0 |
以上是条件计算，实际需求应按 ACTIVE rm_masks 对应的有效存盘通道数及采样率确定，不是只按插入的子卡数量计算。
对于 640MB/s 的假设目标，本次最低统计速度约 752MB/s，吞吐量余量约 18%。但一秒平均值可能掩盖更短的停顿，且本次 libaio、队列深度 32 的工作负载未必等同 SDK 的实际写入方式，不能据此保证 SDK 不丢样。
原定后续验证目标如下；根据第 9～11 节新增的实采结果，当前应先定位丢点，再进行最终长时间验收：
df 再次显示约 1.8T 可用；第二轮前约 226.7G 已用、1.6T 可用，与保留首轮数据相符。后续测试仍需重新检查挂载和空间。开发板测试目录：
/mnt/TiPlus7100s/fio_test_20261013_141643/
├── result.txt fio 统计报告，约 1.8KB
├── write_bw.1.log 每秒平均带宽日志，26,810 字节
└── write_test.bin 写入测试文件，1.5TiB
分析使用的 Windows 日志：C:\Users\Mr.J\Desktop\TMP\write_bw.1.log。result.txt 和内核日志依据开发板终端粘贴输出记录，本次未单独读取其本地副本。
write_bw.1.log 的 SHA-256：
3CD91D0853370646671E68FD071CEA64E675031D709D340281FC52A112897B8B
参数、单位及日志格式参考：fio 3.32 官方使用说明。
| 项目 | 实际配置 |
|---|---|
| SDK 路径 | /opt/DDAQ/software/DDAQ_V1_2_SDK |
| 模式 | capture_mode: stream |
| 每通道采样率 | 2,000,000 次/秒 |
ACTIVE rm_masks |
[ffffffff, 00000000, ffffffff, 00000000, ffffffff]，卡 0、2、4，共 96 通道 |
| 每个采样帧 | 96 通道 × 2 字节 = 192 字节；本文“丢帧”指整组通道采样，不是 DMA 包或 BD |
| 输入数据率 | 384MB/s，约 366.211MiB/s |
| 文件分片 | file_samples: 20000000；每个完整文件 3,840,000,000 字节（3.84GB），约 10 秒数据 |
| DMA 环形缓冲 | 64 个 BD，每个 1,310,720 字节（1.25MiB），总计 80MiB |
| SDK 异步写队列 | 深度 16，主要使用 io_uring 和 O_DIRECT |
| 第 1 轮目录 | /mnt/TiPlus7100s/data/20261013，directory_mode: backup |
| 第 2 轮目录 | /mnt/TiPlus7100s/data/diag_20261013_163359_31914，directory_mode: error |
第 1 轮保留存盘程序终端输出，出现丢点后人工停止。第 2 轮保持采样率、ACTIVE 通道数和分片大小不变，使用新目录；给存盘输出加墙钟时间，另一个终端约每秒执行一次 ddaq_cli debug all，约 600 秒后通过 ddaq_cli stop 正常停止 PL，由存盘程序排空缓冲后退出。额外诊断读取会增加少量控制访问，两轮不是完全相同的观测负载。
配置请求启用全部卡，但 ACTIVE 只启用卡 0、2、4；卡 1、3 的掩码和 PGA 不可用共产生 4 条已知警告。因此不能按请求掩码将本次数据率算成 640MB/s，也不能将该结果作为 160 通道验证。
| 指标 | 第 1 轮 | 第 2 轮 |
|---|---|---|
| 时长口径 | 末次输入计数折算约 633.921 秒；人工停止 | 终端开始/停止约 600 秒；输入计数增量折算约 599.672 秒 |
| 输入采样帧 | 1,267,841,956（末次累计值） | 1,199,343,572（本轮增量） |
| 输出采样帧 | 1,267,563,230（末次累计值） | 1,198,916,516（本轮增量） |
drop_busy_count |
278,726（末次累计值） | 新增 427,056；开始 278,726，结束 705,782 |
| 丢失比例 | 约 0.02198%（末次累计比值） | 约 0.03561%（本轮增量比值） |
| 对应丢失字节 | 53,515,392（按末次丢帧计数计算） | 81,994,752（约 82MB，78.196MiB） |
| SDK 接收／写盘字节 | 243,372,140,160，两者相等 | 230,191,971,072，两者相等 |
| 完整分片数 | 63 | 59 |
| 最后保留文件 | 1_000064.bin，1,452,140,160 字节，complete=no |
1_000060.bin，3,631,971,072 字节，complete=no |
| 结果 | state=ERROR result=INCOMPLETE exit=1 |
state=ERROR result=INCOMPLETE exit=1 |
口径说明：第 1 轮没有在所提供终端记录中保存独立的采集前 PL 计数快照，表中明确使用末次累计计数；其末次 PL 字节计数与该轮接收/写盘字节一致。第 2 轮保存了开始、结束快照，必须用差值，不能把 705,782 全部归为本轮丢失。计数折算时长假设实际采样率为 2MS/s，不替代独立墙钟计时；程序 elapsed 还包含启动后等待 PL 开始的时间。
第 2 轮精确核对：
输入增量 = 2,467,185,528 - 1,267,841,956 = 1,199,343,572 帧
输出增量 = 2,466,479,746 - 1,267,563,230 = 1,198,916,516 帧
输入增量 - 输出增量 = 427,056 帧
丢帧增量 = 705,782 - 278,726 = 427,056 帧
PL 字节增量 = 473,564,111,232 - 243,372,140,160
= 230,191,971,072 字节
输出帧增量 × 192 = DMA actual_bytes = SDK received = SDK written
= 230,191,971,072 字节
59 × 3,840,000,000 + 3,631,971,072 = 230,191,971,072 字节
第 2 轮丢帧折算为 213.528ms 的输入数据量，是分散丢帧的合计，不意味着存在一个连续 213.528ms 的停顿。两轮的字节数量一致均不是读回校验，也不证明信号在帧间连续。
从 593 个诊断快照提取出 7 个丢帧计数增长区间。时间均为日志 UTC；采样间隔约 1 秒，可能有取整和观测延迟，不是精确的硬件丢点时刻，也不等于恰好发生 7 次硬件事件。
| 计数增长区间（UTC） | 新增丢失帧数 | 文件切换关联 | 区间末诊断快照：hardware / done / user BD |
|---|---|---|---|
| 16:40:02～16:40:03 | 8,685 | 文件 33 中段；16:39:58 打开，16:40:08 完成 | 37 / 11 / 16 |
| 16:40:26～16:40:27 | 50,563 | 文件 35 完成前约 1 秒；16:40:28 完成 | 15 / 33 / 16 |
| 16:40:29～16:40:30 | 70,615 | 文件 36 在 16:40:28 打开后的约 2 秒 | 60 / 0 / 4 |
| 16:41:45～16:41:46 | 94,836 | 文件 43 完成前约 2 秒；16:41:48 完成 | 57 / 3 / 4 |
| 16:42:16～16:42:17 | 58,347 | 文件 46 完成前约 1 秒；16:42:18 完成 | 57 / 3 / 4 |
| 16:42:37～16:42:38 | 92,215 | 文件 48→49 切换附近，切换日志时间 16:42:38 | 61 / 0 / 3 |
| 16:43:57～16:43:58 | 51,795 | 文件 56→57 切换附近，切换日志时间 16:43:58 | 40 / 8 / 16 |
| 合计 | 427,056 | 既有文件中段，也有文件尾部／切换附近 | — |
第 1 轮首次告警位于程序 elapsed=329.4～330.4s 的打印区间内，文件 33 当时仍在写入，文件 33→34 切换随后出现在 333.4～334.4s 的打印区间内。第 2 轮首次告警在 UTC 16:40:02、约采集 324 秒后，也在文件 33 中段。两轮都不是仅在切换文件时丢点；首次丢点都在文件 33 是值得复现的线索，不证明文件编号存在逻辑错误。
文件 completed/opened 输出并未给出切换操作的开始时刻，因此“完成前 1～2 秒”不能直接理解为同步或切换尚未开始。存盘日志中的 integrity=WARNING 为保留的告警状态，不是每条状态输出都代表一次新丢点。
hardware_bd=15、done_bd=33、user_bd=16：33 个缓冲已完成 DMA 接收、尚未交给用户程序；16 个缓冲被 SDK 持有，达到写队列上限；仍有 15 个缓冲归硬件使用。说明接收／写盘流水线出现过明显积压，但不能单独确定积压起因。hardware_bd 最低为 15，done_bd 最高 33，user_bd 最高 16；与存盘心跳不同步，不能将不同采样时刻的数值拼接为同一状态。overflow=0、dma_error=0、sequence_error=0、wait_timeout=0。驱动的 overflow 统计的是工作中检测到的硬件描述符耗尽，不是 PL FIFO 满次数，也不覆盖全部瞬时 AXI 停顿。data_path_status 的 FIFO 输入 ready 位均为 1。只能说明快照时刻可接收，不能排除快照间的短时反压；当前没有 FIFO 占用量或连续反压时长记录。short_bd=1、尾部长度 703,232 字节，并有 EOF，符合最后一个不足整 BD 的数据尾部，不直接表示丢失。ARMED；存盘终端于 16:44:39 输出最终结果并退出。该瞬时状态不能认定为 DMA 卡住，程序退出后的最终 DMA 状态尚需补读。ERROR/INCOMPLETE 是存盘程序不能认证本轮完整的结果，不等于 DMA 硬件报错。complete=no 表示最后文件未获完整性认证，不意味着其所列字节没有写入；完整关闭的前序文件也可能包含采样间断。链路：前端 FPGA → Aurora 接收／跨时钟 FIFO → 多卡数据汇合 → adc_to_dma 双缓冲与串行打包 → 64KiB AXIS FIFO → AXI DMA → DDR 环形缓冲 → SDK → NVMe。
当前发布包 adc_to_dma.v 的接收条件为：
debug_accept_sample = sample_valid && !is_stop &&
(!sample_buff_valid || !send_sample_valid);
debug_drop_busy = sample_valid && !debug_accept_sample;
正常采集中，新采样到达而两个采样缓冲均占用时，本帧被拒收并增加 drop_busy_count。两轮输入／输出帧差值均与相应丢帧计数吻合，第二轮又由起止增量精确验证。因此，已计数的丢失位于打包器入口、进入 DMA／DDR 之前。这不排除未被现有计数覆盖的更上游接收或多卡汇合问题。
正常工作时，旧采样从 sample_buff 转入 send_sample_buff 由新采样到达推动，而非发送端一空闲就自动转移；输入端没有通过 ready 握手等待下游。当前卡 0、2、4 的掩码涉及 20 个扫描组，其中 8 个空组仍需遍历，输出存在握手周期开销。简化控制周期计算得到一帧约 320ns，正常 2MS/s 帧间隔为 500ns，余量约 180ns。该计算假定下游一直 ready，仅为源码时序估算，不是完整 RTL 仿真或板上实测最大吞吐。
可能过程：下游短暂阻塞 → AXIS FIFO 积压 → 打包器输出等待 → 两个采样缓冲均占用 → 下一帧输入被拒收。
fdatasync 和目录 fsync；缓冲写完才按顺序归还，某个较早缓冲迟迟未完成会阻碍后续归还。这些均可能造成短暂停顿，但现有日志没有分段耗时。overflow=0 和仍可用的硬件 BD 不支持“SSD 长期带宽不足把 DDR 描述符全部耗尽”的简单解释，但不排除 DDR 仲裁、SG 描述符访问、DMA 内部或共享内存负载造成的瞬时停顿。fio 使用 libaio、深度 32、1MiB 单文件写入；实采使用 io_uring、深度 16、DMA 映射缓冲和周期分片，且包含 PL 写 DDR 与 NVMe 读取内存的同时负载。fio 吞吐足够，不能证明实采中的存储／共享 DDR 路径不存在延迟。实采约 5 分钟后首次丢点，也不能直接等同于 fio 约 942 秒后的掉速现象。
当前未捕获丢点前 FIFO／DMA 的连续握手波形，未记录 AXI 地址、数据、响应或 SG 访问的最长等待，也未记录 SDK 分段延时、块设备请求完成时间、SSD 温度等。第二轮结束后的内核错误日志尚未提供；不能套用此前 fio 的无错误日志结论。
联合分析依据为当前 Windows 发布包中的 RTL／SDK 源码和用户提供的开发板输出，尚未核验运行中的 BOOT.BIN、应用和驱动与这些源码的构建对应关系。目前只更新测试报告，没有实现下面的诊断功能或修改部署软件。
保留两轮采集日志、诊断日志、配置备份及数据；清理或覆盖前先明确保留范围。补读存盘程序退出后的 ddaq_cli debug all，保存内核日志，记录内核／SSD 固件版本、温度及 SMART（工具支持时）。记录运行应用、驱动和启动文件的哈希，确认源码与部署版本。
使用 CLOCK_MONOTONIC，每秒汇总次数、最大值和超阈值次数，丢点时保留邻近统计，避免逐 BD 打印。保持采集算法、通道、采样率、队列和文件大小不变，发布版暂不修改。
| 观测项 | 需要区分的问题 |
|---|---|
| PL 丢帧总数／每秒增量，BD 占用 | 丢点与积压是否同步、先后关系如何 |
| 主循环最长间隔、控制快照耗时 | 主线程是否长时间不处理接收或完成通知 |
DQBUF 耗时及取回后处理耗时 |
等待数据／驱动处理与 SDK 处理慢的区别 |
| 写请求入队、实际提交内核、CQE 取回时间 | 写入链路的整体等待；同时记录未处理 CQE 积压 |
CQE 取回至 QBUF、QBUF 调用耗时 |
已完成缓冲是否被延迟归还，或归还／映射操作慢 |
分片 drain、边界 pwrite、文件 fdatasync、目录 fsync 的开始／结束及耗时 |
切文件具体在哪一步等待 |
提交到 CQE 取回的时间包括主线程没有及时轮询的时间，不能直接标为“SSD 延时”；正常 DQBUF 等待数据也不直接标为故障。必要时使用块设备请求下发／完成跟踪，区分内核／设备延迟与完成通知处理延迟；外部跟踪工具也会增加观测开销。
以下是待开发的测试工具／模式，当前 SDK 没有这些可直接使用的参数，不能通过现有命令凭空开启。
| 测试 | 方法 | 能判断什么／限制 |
|---|---|---|
| 模拟 BD 存盘 | 在板上用独立数据源模拟 64 × 1.25MiB 缓冲、序号及取回／归还行为，复用真实 SDK 分片与写盘逻辑 | 检查 SDK／文件系统／NVMe 能否持续处理目标数据率；不模拟真实 AXI DMA、HP0、驱动缓存维护或全部 DDR 竞争 |
| 真实 DMA 接收、不写盘 | 诊断程序接收真实 DMA 数据，保持必要计数与校验，立即归还缓冲，不提交存盘请求 | 判断丢点是否依赖存储负载；不丢点也不直接证明 SSD 是根因，因为去掉写盘同时减少 NVMe 对 DDR 的访问 |
| 带计时的完整采集 | 保持原配置重测，关联丢帧、AXI 观测和 SDK 等待 | 在真实完整负载中验证关联；不能仅凭秒级相关性认证因果 |
模拟 BD 先使用 384MB/s，约每 3.413ms 完成一个 1,310,720 字节缓冲；可另做 640MB/s（约 2.048ms/BD）压力测试，但这不等于 160 通道真实采集通过。生成器独立按单调时钟控制速率，记录节拍偏差和缓冲耗尽；写完并归还前禁止复用，不让生成速度随写盘阻塞自动降低，从而避免“假通过”。建议做独立用户态测试后端，不直接伪造真实 DMA 的硬件描述符状态。
ad_clk 域以 debug_drop_busy == 1 作为 BASIC 触发条件；Capture Mode 采用 ALWAYS，触发位置初始设在窗口约 80% 处，采集前先启动等待触发。不要仅在丢点周期保存数据，否则丢失触发前原因。sample_valid、两个缓冲 valid、group_cnt、FIFO 输入 TVALID/TREADY；DMA 域另观察 FIFO 输出／DMA 输入握手。按各自时钟采集，跨时钟触发正确同步。TREADY=0 就直接归因于 SSD。ILA 支持条件触发和触发前后采样窗口，参考 AMD Vivado ILA 调试指南 UG908。
每次只改变一个主要因素，不同时调整 FIFO、BD 数量、队列深度和文件大小。定位并修正后，先复现原 96 通道配置，再进行至少 15 分钟、必要时 20 分钟或更长采集：
drop_busy_count=0，无 DMA 溢出、错误或序号异常。分析读取的本地终端附件如下。第 2 轮终端 A 的前半部分还包含第 1 轮诊断历史；分析以新目录和带 UTC 时间的采集输出划分测试，未将旧记录计入第二轮增量。
| 记录 | 本地文件路径 |
|---|---|
| 第 1 轮存盘终端输出 | C:\Users\Mr.J\.codex\attachments\488daa9a-2f57-4118-b52d-8055335c863c\已粘贴的文本.txt |
| 第 2 轮终端 A：配置、存盘与文件切换 | C:\Users\Mr.J\.codex\attachments\5dcc67d9-3348-43fe-ad71-9eb275cf2bf8\已粘贴的文本.txt |
| 第 2 轮终端 B：起止快照与周期诊断 | C:\Users\Mr.J\.codex\attachments\81fb6080-694c-4858-888b-55010679506c\已粘贴的文本.txt |
附件 SHA-256（按上表顺序）：
54582994C4964171D60BD731927F523793EDAE39DBA7112AEAB450AC44BC7068
50E95EDC9866EBC49BE0D1679E8B355F7C1345FAA7373B5778CC1D01BFB7F29E
DFA1D189BEC10BD973C1B6123E572385965DBE09A75DF0B4D1D864618B776940
源代码检查基准：C:\Users\Mr.J\Desktop\Project\DDAQ\Release\DDAQ_V1_2，重点文件为 adc_to_dma.v、ad_to_dma_fifo.xci、aurora_to_module_data.v、aurora_to_b64.v、ddaq_system.bd、Software/source/app/ddaq_dma.c、ddaq_io_ring.h 及 Software/source/driver/dma/ddaq_dma_drv.c。终端附件为粘贴记录，诊断不是连续硬件轨迹；后续应另行归档开发板原始日志和构建版本，避免仅依赖聊天附件路径。
本文章使用limfx的vscode插件快速发布