STM32N657 LTDC花屏排查：framebuffer写外部PSRAM跳字节根因与修复

各位做显示相关开发的朋友，如果你们正在调 STM32N657 这颗带 NPU 的新一代 MCU，大概率会遇到一个非常磨人的问题：LTDC 在把 framebuffer 写到外部内存时，数据会莫名奇妙地跳字节。现象就是屏幕画面出现规律性的花屏、条纹错位、或者某个颜色分量的数据串位，你用调试器看内存，发现 framebuffer 里的数据本身就不对——每隔几个字节就少一截。这篇文章就把我在 STM32N657X0H32Q 上排查这个问题的完整过程、根因分析和最终的修复方案一次讲清楚，给正在或者即将踩这个坑的朋友一个参照。

这个问题的本质，其实并不在 LTDC 本身，而是它背后的 AXI 总线访问方式、外部存储控制器的突发传输配置、以及 framebuffer 的地址对齐这三者之间的匹配关系出了问题。LTDC 只是“受害者”，真正埋雷的是存储侧的总线配置。下面我从现象到根因，一条条拆开说。

1. 症状复现与问题定性：先把“跳字节”的三个典型特征摸清楚

先说结论：这种“写跳过字节”的问题，绝大多数时候不是随机性的数据损坏，而是有规律的、跟地址线有强相关性的字节丢失。我在调试时最先做的，不是去看 LTDC 的初始化代码，而是把外部内存里的 framebuffer 数据 dump 出来，用十六进制编辑器逐行比对。只有把症状的特征定义清楚，后面才能有的放矢。

1.1 条纹与色偏：跳字节在画面上的三种表现形态

第一种形态是水平条纹中的有色竖线。如果你往 framebuffer 里填充的是纯色，比如 0xFFFF0000（ARGB8888 格式下的纯红色），而外部内存里实际写入的数据变成了 0xFFFF00 00 00 00 这种错位排列，屏幕上就会出现一条细细的暗线或亮线，位置正好对应跳变发生的那个像素点。这种问题最容易让人误判成 LTDC 的同步时序参数没配好，但实际上同步参数错了通常是整屏撕裂或整体偏移，不会有这种“每 N 个像素就错一个”的周期性错位。

第二种形态是颜色分量串位。比如你本来写的是 RGB565 格式的像素，0xF800 是红色，结果写到内存里变成了 0x00F8，那么屏幕上的红色区域就会呈现出青绿色调，因为高低字节被拆开了。这种现象在调试时特别迷惑人——你会发现屏幕整体色调完全不对，像是颜色空间转换出错了，于是去翻 LTDC 的像素格式配置，却查不出任何问题。

第三种形态是行尾多出来的杂散像素。如果你的 framebuffer 行宽是 320 像素（每像素 2 字节，行宽 640 字节），但在内存里每行实际只写入了 638 字节的正确数据，剩下 2 个字节被跳过，那么下一行数据就整体往前移位了 2 字节。最终画面上每一行都会有一条从上一行“继承”过来的杂色像素点，看起来像是行同步信号出了问题，但调 LPW（Line Pulse Width）和 BP（Back Porch）都无效。

我把这三种形态也整理成一个表，方便后面排查时对照：

1.2 用调试器定位：跳过字节的地址规律才是关键线索

光看画面还不够，我必须看到内存里的实际数据。在 STM32N657 这样的芯片上，我用 ST-LINK 的调试接口，配合 IDE 的内存查看窗口，把 framebuffer 所在的外部 PSRAM 地址段整体 dump 出来。注意，这里的外部内存我用的不是 SDRAM，而是 OctoSPI 接口的 PSRAM，因为 N657 的评估板上比较常用的就是这类存储器。

dump 出来的数据会呈现出非常强的规律性。假设我申请了一块 320x240 的 RGB565 framebuffer，总共 153600 字节，填充 0x00FF（绿色），那么内存里看到的应该是连续不断的 0xFF00 0xFF00 0xFF00。实际情况是：前 8 个 0xFF00 是连续的，第 9 个 0xFF00 的第二个字节（0xFF）丢失了，变成了 0xFF00 0xFF00 ... 0xFF 00 00 0xFF00 0xFF00，即每 16 个字节里只丢 1 个字节，丢的位置非常固定。

这个“每 16 字节丢 1 字节”的规律太关键了。它直接指向了 AXI 总线的写突发（write burst）长度配置。AXI 协议本身是支持 burst 传输的，一次写操作可以连续传输多个数据（beat）。如果外部存储控制器配置的最大写突发长度是 8 beats，而 LTDC 侧请求发起的是 16 beats 的数据传输，那么存储控制器一次只能响应前 8 个 beats，后面的 8 个 beats 要么被直接丢弃，要么被错误地拆分到别的地址。

提示：如果你的数据规律是“每 32 字节丢 2 字节”或者“每 64 字节丢 4 字节”，那大概率是同样的病因，只是具体的突发长度配置不同。关注丢字节的周期和位置，比关注丢了几个字节更重要。

2. STM32N657 的显示通路架构：为什么外置内存的写路径容易出问题

在深入修 bug 之前，先花点时间把 STM32N657 的显示相关架构搞清楚。这个芯片不是传统的单核 Cortex-M 那么简单，它内部有一个 6400 万像素级配置的 DSI/LTDC 管线，还集成了一颗用于图形加速的 Neural-ART 加速器。显示数据从 GPU 或者 CPU 写入 framebuffer，再到 LTDC 读取 framebuffer 输出到屏幕，这条通路跨越了好几个总线和时钟域。

2.1 LTDC、GPU 与外部内存之间的总线拓扑

STM32N657 的内部总线是 AXI 互联矩阵，主设备（Master）包括 Cortex-M55 内核、Neural-ART 图形加速器、DMA 等，从设备（Slave）包括内部 SRAM、外部存储控制器、以及各种外设。LTDC 本身在大多数 STM32 芯片上是作为 AXI 主机存在的，它的职责是从系统内存中读取 framebuffer 数据，然后经过内部的像素处理管线，最终在 RGB 或者 DSI 接口上输出。

这里就出现了一个关键不对称：写 framebuffer和读 framebuffer走的是两条完全不同的路径。CPU 或 GPU 写 framebuffer 时，数据先经过 AXI 写通道，再进入外部存储控制器的写缓冲；LTDC 读 framebuffer 时，数据从外部存储器出来，经过 AXI 读通道，再进入 LTDC 的 FIFO。如果你只是单纯用 LTDC 把一个静态图片显示出来，读路径是正常的，问题往往不会暴露；但一旦涉及图形渲染、动态更新 framebuffer 的内容，写路径的隐患就会被触发。

2.2 N657 与老一代芯片的关键差异：多了 Cache 和更复杂的存储控制

N657 相比 F429、H743 这些老将，最大的变化是引入了 Cortex-M55 以及完整的 D-Cache/I-Cache 体系。Cache 的引入让 CPU 写外部内存的行为变得更加“诡异”。

在 F429 这类没有 Cache 的芯片上，CPU 直接写外部 SDRAM 的某个地址，会真的产生一次总线写操作，存储控制器老老实实地把数据写进去。但在 N657 上，CPU 写外部 PSRAM 的某个地址，数据可能先被缓存在 D-Cache 里，不会立刻到达 AXI 总线。如果你用了 DMA 或者图形加速器去读取同一块内存，CPU 还没来得及回写 Cache，读取侧看到的就是旧数据——这虽然不完全是“跳过字节”，但会造成类似的花屏现象。

我这次的调试目标也分成了两层：第一层，确认数据最终有没有真正写进外部 PSRAM；第二层，如果写进了，是不是有字节被跳过。这两个现象的处理方式是截然不同的，前者是 Cache 一致性问题，后者才是总线突发配置问题。在 N657 上，强烈建议先把 Cache 问题排除掉，否则后续的排查方向很容易被带偏。

注意：N657 上如果使用了外部 PSRAM 作为 framebuffer，务必确认是否需要关闭 framebuffer 地址段的 Cache，或者使用 Clean/Invalidate 操作来保证一致性。这一步不做，后面出现的任何花屏问题都会让你怀疑人生。

2.3 外部存储控制器：OctoSPI PSRAM 与 SDRAM 的行为差异

外部存储这一侧，N657 通常搭配的是 PSRAM 或 SDRAM，这两种器件的访问特性非常不一样。SDRAM 有行激活、列访问、预充电这些开销，对突发长度的要求很高，必须是 2/4/8 这样的整数倍才能发挥带宽。PSRAM 是基于 SPI 接口的伪静态随机存储器，虽然内部也有刷新逻辑，但外部接口是一种串行总线——OctoSPI 接口，数据位宽是 8 位或 16 位（DTR 模式下）。

我在 N657 的评估板上用的是 APMemory 的 64Mbit PSRAM，通过 OctoSPI 接口连接。这类 PSRAM 支持的最大突发访问长度通常是 32 字节或 64 字节，而 AXI 总线的写突发在配置不当的情况下会拆分成更小的片段。这就导致了一个结果：AXI 侧想一次性写 16 字节，但 OctoSPI 控制器内部可能只接受 8 字节的突发，剩下的 8 字节如何处理就完全取决于控制器的实现了。有些控制器会把这 8 字节缓存下来，凑齐下一次突发；有些控制器则直接丢弃——后者就是我遇到的“跳过字节”问题。

如果你用的是 SDRAM，情况会好一些，因为标准的 SDRAM 控制器都会对 AXI 突发做完整的缓冲和拆解。但 PSRAM 的串行特性天然更容易出现这种“数据在转换层被吞掉”的局面。

3. 逐层排查：从 LTDC 配置到存储控制器时序的完整链路

有了前面的定性分析，我的排查路径就很清晰了。整个过程我分成了五个步骤，每一步都可以独立验证。这些步骤按照从软件层到硬件层的顺序排列：先检查 LTDC 的初始化，再检查 framebuffer 地址配置，然后是存储控制器参数，最后是总线层面的配置。大部分情况下，问题就藏在其中某一层的配置疏忽里。

3.1 第一步：确认 framebuffer 地址对齐

这是最容易做也最容易被忽略的一步。LTDC 读取 framebuffer 时，要求 framebuffer 的起始地址和行字节数必须满足总线对齐条件。具体来说，AXI 总线的突发传输是固定长度的，地址必须按照突发长度对齐。如果你的 framebuffer 起始地址是 0x70000001（即 4K 对齐之外），那么第一次总线读请求就会出现从非对齐地址开始的突发，存储控制器不得不做额外的对准操作。这种对准操作在某些实现里会导致开头几个字节被跳过。

N657 的外部 PSRAM 起始地址通常是 0x70000000，但你在分配 framebuffer 时不一定能拿到从 0 偏移开始的地址。比如你先分配了别的缓冲区，framebuffer 被分配到了 0x70001000 + 4 的地址，偏移了 4 字节。这 4 字节的偏置在 L1 Cache 的按行缓存下可能没影响，但在 Write-Back 模式下会引发总线写入不对齐，最终让我在内存里看到跳字节的现象。

解决之道：给 framebuffer 分配内存时，强制做 64 字节对齐（甚至 4K 对齐）。对于 N657 上跑 Metal 框架或者直接用 malloc 的情况，你的堆管理器不一定能保证这一点，所以更稳妥的做法是直接配置一个专属于 framebuffer 的静态内存池，并显式指定对齐属性。

3.2 第二步：检查 LTDC 的像素格式与行配置

LTDC 的初始化结构体里，最关键的两个字段是PixelFormat和AccumulatedActiveW/AccumulatedActiveH。在 STM32 的 HAL 库里，有一个LTDC_ConfigLayer函数负责设置图层的 framebuffer 地址和像素格式。如果这里配置的像素格式和实际 framebuffer 的数据格式不一致，比如 framebuffer 里存的是 ARGB8888，但层被配置成 RGB565，LTDC 在读取时就会按错误的格式解析数据。

不过要注意，这种错误通常不会造成地址层面的跳字节——它只是解析错了。所以我把这一步定位为“排除项”，确认不是格式错配。在 N657 上，我建议把像素格式的验证做成一个原子操作：用纯色填充 framebuffer，然后用调试器读回正确的数据，同时检查 LTDC 产生的帧中断标志。如果读回数据正确，但屏幕显示依旧花屏，那基本可以断定问题出在读取侧的颜色格式转换，或者后端 DSI 接口的配置上。

3.3 第三步：检查存储控制器的时序参数

OctoSPI PSRAM 的时序参数配置在 N657 的 XSPI（OctoSPI 控制器）外设里。需要重点检查的是Write Latency、Read Latency和Recovery Time。PSRAM 不同于普通 NOR Flash，它内部的刷新操作会不定期地打断外部访问，因此它的时序参数非常严格。如果 Write Latency 配置得太短，控制器在 PSRAM 还没准备好接收数据时就发起写操作，数据就可能被 PSRAM 内部的写缓冲区丢弃。

这一步有个很实用的调试技巧：把 OctoSPI 的频率降下来，比如从默认的 100MHz 降到 50MHz，看看跳字节的现象是否消失。如果频率降下来之后现象消失，说明时序参数存在临界风险，而不是配置错误。这种情况可以用更保守的时序参数来修复。如果降频后现象依旧，说明问题不在 PSRAM 时序而在于总线突发层。

3.4 第四步：检查 AXI 突发长度的配置

N657 的 AXI 互联矩阵允许对每个主设备端口设置最大突发长度。在老的 STM32 系列上，这个配置通常在 AXI-to-AHB 桥或存储器控制器里。在 N657 上，这部分配置分布在 XSPI 控制器和 AXI 互联的 QoS 寄存器里。

重点说一下 XSPI 控制器的突发配置。XSPI 外设支持可配置的最大读/写请求长度，单位是字节。如果你把最大写请求长度配置成了 16 字节，但是 AXI 侧的主设备（比如 CPU 的写请求经过 L1/L2 Cache 的合并之后）发出的是 32 字节的写突发，XSPI 控制器需要把 32 字节拆成两个 16 字节的突发来处理。拆分的动作本身没问题，但如果 XSPI 内部没有缓存 32 字节的临时缓冲区，拆分就会丢失数据。这就是我遇到“每 16 字节丢 1 字节”的直接原因。

提示：检查一下 AXI 主设备侧的最大突发长度，是否和 XSPI 控制器侧的最大请求长度一致。不一致的情况下，无论你调多少时序参数都是白搭，因为数据在总线协议转换层就丢了。

3.5 第五步：用 DMA 写测试反推问题层

如果你和我一样，已经排除了前面四项，那么走到这里你可能会问：怎么定位到到底是哪一层丢的数据？我的做法是：写一个最小化复现程序，用 DMA 从内部 SRAM 搬运一个 4KB 的数据块到外部 PSRAM，然后再搬运回来，比对源数据与回读数据。

这个实验的妙处在于：DMA 不经过 CPU 的 Cache，它发出的是直接的 AXI 写请求。如果 DMA 写外部 PSRAM 时也出现了跳字节，那问题就彻底跟 LTDC 无关了，纯粹是存储控制器或者 AXI 配置的锅。如果 DMA 写是正常的，只有 GPU（或 CPU 通过 Cache）写 framebuffer 时跳字节，那问题就更可能出在 Cache 的高速缓存行合并机制或者 GPU 的 AXI 端口配置上。

我在 N657 上做这个测试时，发现 DMA 直写是正常的，这让我把重点从存储控制器时序转移到了总线主设备的突发长度配置上。这是一个很好的分流手段，能帮你省下大把时间。

4. 字节跳写的真正元凶：AXI 突发长度与存储控制器配置失配，以及 Cache 行的暗坑

经过前面一轮排查，最终的根因水落石出——不是 PSRAM 坏了，不是 LTDC 时序错了，也不是像素格式配错了，而是CPU 写路径经过 Cache 合并后的突发长度与 XSPI 控制器的最大可接受突发长度不匹配。下面把这层机制彻底拆开。

4.1 CPU 写回（Write-Back）模式下的 Cache 行合并机制

在 Cortex-M55 上，D-Cache 的缓存行（Cache Line）大小是 32 字节（有的配置是 64 字节）。当 CPU 执行一条普通的 32 位写指令（STR）时，数据不是立刻发送到 AXI 总线上，而是写入了 Cache 行对应的 SRAM 中。只有当 Cache 行被替换出去（eviction）或者被显式 Clean 操作触发时，整个 Cache 行（32 字节）才会作为一个整体的写请求发送到 AXI 总线。

这就意味着：CPU 每产生一次对外部 PSRAM 的写回操作，AXI 总线上就会出现一次 32 字节的写突发。如果 XSPI 控制器一次最多只能接受 16 字节的写突发，这 32 字节的数据就需要被拆分成两次传输。问题就出在这次拆分上——拆分之后，如果第二个 16 字节的突发因为地址对齐问题或者缓冲区不足被丢弃，数据就丢了。

那为什么会出现跨越缓存行边界时丢数据的情况呢？这是因为 Cache 行的写回虽然按 32 字节对齐，但如果你在分配 framebuffer 时没有保证 32 字节对齐（比如地址是 0x70001020），那么 Cache 行写回时会产生跨越两个 32 字节边界的不对齐写操作。XSPI 控制器处理这种不对齐写操作时，需要读取-修改-写回（Read-Modify-Write）来保留端部的字节，而某些实现里这种 RMW 操作会因为 PSRAM 的读延迟导致数据丢失。

4.2 XSPI 控制器的写缓冲：为什么它吞掉了多余的数据

XSPI 控制器的内部有一个写缓冲（Write Buffer），它的大小通常等于一次突发请求的最大字节数。如果这个缓冲是 16 字节，那么当 AXI 侧发来 32 字节的写突发时，控制器会先把前 16 字节放进缓冲，发送到 PSRAM，然后再处理后 16 字节。但在某些实现中，AXI 互联矩阵在把 32 字节突发拆分成两个 16 字节突发时，会强制对地址做对齐处理。如果第二个 16 字节的首地址不是 16 字节对齐的（比如它恰好落在地址 0x70001010），控制器就会产生一个非对齐突发，而这个非对齐突发在 PSRAM 的串行协议中是不被支持的，于是数据就被丢弃了。

这种问题的隐蔽性在于：它看起来是随机丢字节，但实际上丢字节的位置完全由 Cache 行的替换顺序和 framebuffer 的地址偏置共同决定。我最后通过调整 framebuffer 的分配策略，把它强制放到 32 字节对齐的地址上，丢字节现象就消失了。

4.3 验证：通过配置修改确认根因

为了确认这个判断，我做了两组对比实验。第一组维持 framebuffer 地址不变，只修改 XSPI 控制器的最大写请求长度，从 16 字节改成 32 字节。重启后，跳字节现象完全消失。第二组把 XSPI 配置恢复成 16 字节，但把 framebuffer 地址从 0x70001020 改成 0x70001040（32 字节对齐），跳字节现象同样消失。

这两组实验的结果非常一致地指向了同一个根因：AXI 写突发长度与 XSPI 控制器的处理能力不匹配，加上 framebuffer 地址不对齐，两者共同导致了写路径上的字节丢失。只要修复任意一个变量，问题就能解决。最稳妥的方案是两者同时修复，既能保证稳定性，又能保留足够的性能余量。

5. 修复方案与实测验证：配置代码级别的具体操作

如果只是定位问题，这篇博文的价值就缺了一半。真正对你们有帮助的是下面这一套可以照着改的方案。我在 N657 上实测过，效果稳定，耗时好几天反复验证，没有再出现跳字节。

5.1 修改 XSPI 控制器的最大写突发长度

在 N657 的 XSPI 初始化结构体中，有一个XSPI_InitTypeDef里的FifoThreshold和MemoryType字段，不过真正决定突发拆分行为的是 NOR 配置中的WriteLatency和MaxWrite相关的参数。我这里给出的是基于 HAL 库的配置示例（伪代码风格，实际使用时要替换成你真实的 PSRAM 型号参数）：

XSPI_MemoryMappedTypeDef memMappedCfg = {0}; memMappedCfg.TimeBase = XSPI_TIMEBASE_1_CLK_CYCLE; memMappedCfg.WriteLatency = 2; // 根据 PSARM 数据手册调整 memMappedCfg.WriteBurstLen = XSPI_BURST_LENGTH_32_BYTES; // 关键：把突发长度改成 32 字节 HAL_XSPI_MemoryMapped(&hxspi, &memMappedCfg);

注意，不同的 PSRAM 型号支持的突发长度上限不同。APMemory 的 APS256XXN 系列最高支持 64 字节突发，而一些老款 PSRAM 只支持 32 字节。务必先查你手里那颗 PSRAM 的数据手册，不要无脑改到最大。

5.2 强制 framebuffer 的 32 字节甚至 1024 字节对齐

仅仅改 XSPI 突发长度还不够保险。正如前面分析的，Cache 行写回天然以 32 字节为粒度，所以 framebuffer 的起始地址必须至少 32 字节对齐。但更稳妥的做法是直接按 AXI 总线带宽的整倍数对齐，比如 1024 字节。这样即使后续增加了其他总线上主设备（比如图形加速器的位块传输）也不会因为对齐问题触发新的异常。

如果你用的是链接脚本（Linker Script）来分配内存，可以使用__attribute__((aligned(32)))或者直接定义到独立的 Section 里：

__attribute__((section(".framebuffer"), aligned(1024))) uint8_t framebuffer[320 * 240 * 2];

然后在链接脚本中把.framebuffer段放到外部 PSRAM 的起始地址之后偏移 0 的位置：

.framebuffer (NOLOAD) : { . = ALIGN(1024); *(.framebuffer) . = ALIGN(1024); } > EXTERNAL_PSRAM

5.3 屏蔽 framebuffer 地址段的 Cache 或执行 Clean 操作

有些场景下，你没法保证 framebuffer 的地址对齐（比如使用了第三方库的内存池），这时候最直接的做法是把该地址段配置为非 Cache 属性。在 N657 上，需要操作 Cortex-M55 的 MAIR 寄存器和页表描述符。这在裸机环境下稍微有点麻烦，但 CubeMX 生成的代码里已经带了MPU_Config的函数，你可以在里面添加一个 Region，把 framebuffer 地址段设置成Device或Non-Cacheable属性。

但要注意，完全屏蔽 Cache 会显著降低 CPU 写 framebuffer 的性能，因为每次写入都要穿透到外部 PSRAM，访问延迟可能高达几十纳秒。对于需要高效渲染的场景，我推荐一个更好的折中方案：保持 Cache 开启，但每次 GPU 或 CPU 写完一帧数据后，执行一次SCB_CleanDCache_by_Addr（或者 HAL 里的HAL_DCACHE_CleanByAddr）来把脏数据强制回写到 PSRAM。这样既保留了 Cache 在写入过程中的缓冲优势，又保证了外部内存中的数据是完整的。

// 在帧渲染完成之后，提交到 LTDC 之前调用 SCB_CleanDCache_by_Addr((uint32_t *)framebuffer, sizeof(framebuffer)); __DSB(); // 等待 Clean 完成

这个修改的量虽然小，但对问题的影响是决定性的。实测下，加上这一行代码之后，即使 XSPI 的突发长度维持在原配置，跳字节现象也不复存在，代价只是每帧渲染结束后多了一点回写时间。

5.4 验证：连续跑 10 万帧渲染压力测试

修复之后，不能只看一张静态图正常就收工。我写了一个压力测试脚本：让 GPU 以每帧 2ms 的速度往 framebuffer 里写入随机色块，同时启动 LTDC 实时显示，总共跑 10 万帧。每帧结束时都做一次 DMA 回读校验，比对 framebuffer 里是否有多字节、漏字节、错字节。

结果如下表：

从表里可以清楚看到，修复后的问题得到的是质变，而不是仅仅缓解了概率。

6. 这类问题的通用排查思路：别只盯着 LTDC，总线配置才是大户

通过这次调试，我的一个深刻体会是：当显示出现花屏、跳字节这类问题的时候，第一反应不要总想着调 LTDC 的时序参数或者换一种像素格式。LTDC 本身是一个非常“被动”的外设，它只是从内存里取数据，按固定的时序发送出去。真正决定数据会不会正确到达内存的，是存储控制器和总线互联层的配置。下面这套排查思路是我总结出来的，适用于 N657 以及所有带外部内存和 LTDC/DSI 的 STM32MP1 和 H7 系列芯片。

6.1 从画面症状快速锁定排查方向的检查表

我整理了一个排查检查表，按优先级排序，你拿到问题后可以按这个顺序逐项排查：

1. 先把画面截图或者拍照，确认是规律性错位还是随机性花屏。
2. 直接 dump 内存里的 framebuffer 数据，对比源数据，确认是否是写侧的问题。这一步能区分到底是“没写进去”还是“写错了”。
3. 确认 framebuffer 地址是否对齐：32 字节起步，推荐 1024 字节。
4. 确认 Cache 配置：framebuffer 区域是否被 Cache 缓存？写完后是否有 Clean 操作？
5. 确认 XSPI/SDRAM 控制器的突发长度配置是否和 AXI 主设备匹配。
6. 降频测试：把存储控制器频率降低一半，看现象是否消失。如果消失，大概率是时序余量不足。
7. 用 DMA 直写做隔离测试，判断问题在 CPU/Cache 侧还是存储控制器侧。

6.2 为什么不要一上来就调 LTDC 时序参数

很多工程师（包括早期的我）遇到显示问题时，第一反应是去调整 LTDC 的 HSW（Horizontal Sync Width）、VBP（Vertical Back Porch）参数。但实际上，这些参数只影响显示时序，不影响数据内容。如果你的数据写错了，再怎么调时序也只是把错误的内容更稳定地显示出来，不可能修好。

从效率角度看，先确认内存数据是否正确，是排除“数据源问题”的高效手段。只要在内存层面确认 framebuffer 里的数据和预期一致，剩下的问题才可能属于 LTDC 读取端的时序、图层混合或者后端接口。

提示：如果你在开发板上反复调 LTDC 参数但花屏依旧，马上停下来，去检查 framebuffer 内容是不是干净的。这一步能帮你省下至少一整天。

6.3 存储控制器 vs. Cache 一致性：两大类问题的倾向性判断

最后说一下我在这类问题排查中的一个倾向性判断方法。当你遇到写数据丢失时，可以先用一个简单的问题来定方向：丢数据是不是和 Cache 行边界强相关？

• 如果丢数据的位置总是出现在 32 字节边界的附近，大概率是 Cache 写回和总线突发拆分的兼容性问题。
• 如果丢数据是完全随机的，和地址强相关但和边界无关，那更可能是存储控制器时序不稳定（温度、电压、频率变化触发）。
• 如果丢数据频率很低，但每隔几个 MB 才出现一次，多半和 PSRAM 的刷新操作冲突有关，需要调整刷新调度优先级。

这套判断方法不是绝对真理，但它能帮你快速避免在错误的方向上浪费好几个小时。

7. 后续扩展：从裸机到带操作系统的显示栈移植

既然已经在 N657 上解决了裸机环境下的 LTDC framebuffer 写跳过问题，下一个更实际的问题是：如果你后续要上 RTOS 或者 Linux（这个芯片在 STM32 家族里算比较强，有 MMU 加持），这套修复方案怎么迁移？

这里分享几个实际建议。

第一，DSI/LTDC 驱动层的 framebuffer 分配策略需要同步修改。在 Linux 里，DRM/KMS 的 framebuffer 分配通常由 CMA 机制管理，CMA 分配的物理内存可以指定对齐。你可以通过设备树里的alignment属性来设置成 32 字节或者更大。如果没有对齐参数，CMA 也会默认按页对齐（4K），所以 Linux 下的地址对齐问题不如裸机严重。但 XSPI 控制器的突发长度配置依然需要手动检查和修改，Linux 的 XSPI 驱动框架里通常有spi-nor或者spi-psram的控制器配置节点，需要确认写请求长度参数。

第二，Cache 一致性在 Linux 下的处理比裸机复杂。Linux 的 DMA API 提供了dma_map_single和dma_unmap_single来保证缓冲区和设备的 Cache 一致性。如果你用 GPU 渲染 framebuffer，渲染完直接交给 LTDC 显示，中间是不经过 CPU 的，所以 Cache 一致性问题反而不大。但如果你用 CPU 做软件渲染，写完 framebuffer 再交给 LTDC，就必须调用dma_sync_single_for_device来 Ensure 数据被写回内存。

第三，多核场景下的地址空间问题。N657 的 NPU、GPU 和 CPU 可能访问同一块外部 PSRAM，它们各自有各自的缓存层级和总线访问属性。在多主设备并发访问外部内存时，总线仲裁策略也是影响数据完整性的一个重要变量。N657 的 AXI 互联 QoS 配置里，可以给 GPU 设置更高的优先级，避免 CPU 的 Cache 写回和 GPU 的突发读写发生冲突。

这一块我没法在裸机环境里一一验证，但要提醒你的是：把一套裸机上验证过的 framebuffer 写保护策略搬进操作系统里，不能只改驱动代码，还要考虑操作系统的内存管理和设备树配置。

8. 最后总结与经验分享

这篇文章不知不觉写了很多，但核心其实就一句话：LTDC framebuffer 写外部内存时跳字节，先把矛头指向存储控制器和总线突发配置，而不是 LTDC 本身。我在 N657 上花了不少时间才绕出这个弯，希望你能直接用我这条经验跳过去。

最后的最后，根据我这次的调试过程，再浓缩三条实操建议：

1. 遇到花屏先 dump framebuffer 数据再动代码。把内存里的数据当成第一现场，任何画面上的异常都可以追溯到数据层面。数据没问题再去查时序，数据有问题就别碰 LTDC 配置，只管总线、Cache 和存储控制器。
2. framebuffer 对齐和 Cache Clean 是零成本保险。哪怕你把 XSPI 突发长度改对了，我也建议你保留 framebuffer 的 1024 字节对齐和每帧渲染后的SCB_CleanDCache_by_Addr调用。这两招就算在你的项目里不是解决当前问题的关键，也能帮你防住未来一堆潜在的总线问题。
3. 善用 DMA 回读做自动化验证。手动画屏幕看花屏太累，写一个回读校验脚本，让数据自己说话。在 N657 的调试过程中，每次修改配置后跑一遍全量回读测试，比肉眼盯着屏幕看一整天可靠得多。

如果这篇文帮你解决了问题，或者你试了这套方案之后发现了不一样的坑，欢迎在评论区交流。显示链路的调试确实需要耐心，但一旦把整条数据通路吃透，后面再做 DSI 多图层、GPU 加速这些功能就会顺手很多。