STM32H7 TouchGFX 花屏速解：更换 HyperRAM 后 latency 值适配实操

STM32H735DK 开发板更换 HyperRAM 料号后，TouchGFX GUI 出现花屏，核心原因是新旧 HyperRAM 的初始 latency（访问延迟）值不匹配，需将代码中 OCTOSPI 的 AccessTime 参数与新 HyperRAM 的 latency 值同步。本文基于 ST 官方 LAT1403 应用笔记，详解问题根源、1 分钟代码修改方案及选型适配原则，适用于 STM32H7 系列 + TouchGFX+HyperRAM 的 GUI 开发场景。

1. 核心问题与现象

1.1 应用环境

• 硬件：STM32H735DK 开发板，原 HyperRAM 型号 S70KL1281，更换后为 S70KL1282；
• 软件：TouchGFX Designer 4.23.0，基于 STM32H735DK TBS（TouchGFX Board Setup）+ UI 例程开发；
• 显示配置：LCD 分辨率 480x272，HyperRAM 通过 OCTOSPI2 接口连接，用于存储 TouchGFX 帧缓冲数据。

1.2 关键现象

• 更换前（S70KL1281）：TouchGFX 动态图形、UI 界面显示正常，无花屏、错位；
• 更换后（S70KL1282）：屏幕出现花屏、画面撕裂，触控功能正常，排除 LCD 硬件及 TouchGFX 逻辑问题；
• 核心特征：仅更换 HyperRAM 料号后出现异常，无其他硬件或软件改动。

2. 原因解析：HyperRAM 初始 latency 值不匹配

2.1 核心差异：新旧 HyperRAM 的 latency 值

• 旧料号 S70KL1281：初始 latency 值 = 6；
• 新料号 S70KL1282：初始 latency 值 = 7；
• 关键协议要求：HyperBus 协议对 latency 时序匹配度要求极高（参考 AN5050），latency 值与代码配置不一致时，会导致 OCTOSPI 接口读写数据错位，最终表现为 TouchGFX 花屏。

2.2 时序不匹配的直接影响

• 正常逻辑：AccessTime 参数需与 HyperRAM 的 latency 值严格对应，确保 OCTOSPI 在读取数据前等待足够延迟，避免读取未稳定的数据；
• 异常逻辑：更换后 latency 值从 6 升至 7，但代码中 AccessTime 仍为 6，等待时间不足，导致读取的数据出错，TouchGFX 渲染时出现花屏、画面错乱。

3. 解决方案：修改 AccessTime 参数（1 分钟搞定）

3.1 代码修改位置

// 原代码（适配S70KL1281，latency=6）
sHyperBusCfg.RWRecoveryTime = 3;
sHyperBusCfg.AccessTime = 6; // 旧参数，适配latency=6
sHyperBusCfg.WriteZeroLatency = HAL_OSPI_LATENCY_ON_WRITE;
sHyperBusCfg.LatencyMode = HAL_OSPI_FIXED_LATENCY;

3.2 参数修改与验证

// 修改后代码（适配S70KL1282，latency=7）
sHyperBusCfg.RWRecoveryTime = 3;
#if 1
sHyperBusCfg.AccessTime = 7; // 新参数，适配latency=7
#else
sHyperBusCfg.AccessTime = 6; // 旧参数，保留用于回退
#endif
sHyperBusCfg.WriteZeroLatency = HAL_OSPI_LATENCY_ON_WRITE;
sHyperBusCfg.LatencyMode = HAL_OSPI_FIXED_LATENCY;

3.3 验证效果

4. 关键注意事项

1. 更换前必查规格书：新 HyperRAM 料号的初始 latency 值需从其规格书的 “Configuration Register” 章节确认，不可默认沿用旧参数；
2. 参数匹配原则：AccessTime 参数必须等于 HyperRAM 的初始 latency 值，HyperBus 协议不支持自动适配，需手动同步；
3. 其他料号适配：若更换为其他 HyperRAM 型号（如 S70KL256 系列），需按相同逻辑 —— 先查 latency 值，再修改 AccessTime；
4. 协议参考：HyperBus 时序细节可查阅 ST 官方文档 AN5050，避免因其他时序参数（如 RWRecoveryTime）不匹配导致的异常。