STM32F4 外挂QSPI-PSRAM内存随机锁死故障

知行智造局

304人浏览 · 2026-06-30 08:54:58

知行智造局 · 2026-06-30 08:54:58 发布

嵌入式黑匣子设计：基于 RTC 备份寄存器定位微控制器随机死机 & 解决 QSPI-PSRAM 锁死故障**

1. 前言与硬件背景

在嵌入式系统开发中，设备随机死机与看门狗复位往往是最令人头疼的 Bug。这类故障通常表现为：运行数小时甚至数天后随机发生、复位后“案发现场”丢失、在实验室挂机调试时难以复现。

最近，我们在开发基于 STM32 F4 系列（主频 180MHz） 的产品时遇到了这样一个棘手问题。
系统的核心硬件架构如下：

MCU：STM32F439 (基于 ARM Cortex-M4，运行频率 180MHz)
外部存储：ESP-PSRAM64（64Mbit/8MB 伪静态随机存储器），采用 QSPI 接口进行高速数据存取，主要用于缓存大容量瓦片地图和轨迹数据。
其他外设：SD卡（存储系统文件）、I2C 传感器等。

故障现象：在设备进行高频数据刷新（如频繁擦写轨迹、加载大地图瓦片）的严苛场景下，系统会发生随机复位。经过系统时钟及看门狗分析，确定是被**独立看门狗（IWDG）**强杀。由于复位后寄存器和内存全部初始化，我们很难抓取到卡死的具体代码行。

经过一番探索，我们设计了一套基于 RTC 备份寄存器的嵌入式“黑匣子”追踪系统，成功锁定了死机真凶，并实施了时序加固与状态机自愈方案，最终实现了挂机长跑 16 小时以上零死机。本文将这一调试定位过程和解决方案完整分享。

2. 故障定位利器：基于 RTC 备份寄存器的“黑匣子”诊断

由于硬件没有实时连接 J-Link 等仿真器，要想抓出死机瞬间 CPU 究竟在执行什么，我们必须让 MCU 自己记录“临终遗言”。

2.1 诊断原理

在 STM32 芯片中，RTC 备份寄存器（RTC_BKPxR）是一组特殊的寄存器。它们位于后备电源域，只要 VDD 或后备电池（V_BAT）不断电，即使发生系统复位（NRST 引脚复位、软件复位、独立看门狗 IWDG 复位、窗口看门狗 WWDG 复位），这些寄存器中的数据也会原封不动地保留。

因此，我们可以像设计飞机的“黑匣子”一样：

在执行每一个易卡死的外设操作（如 QSPI 读写、SD卡读写、I2C 传输）前，将操作代码（Magic Code）及上下文参数写入 RTC 备份寄存器。
在外设操作顺利执行完毕后，将该备份寄存器清零。
一旦系统因为看门狗超时而发生复位重启，在初始化阶段，首先检查备份寄存器中的魔数。如果魔数存在，说明系统刚才在卡死在该外设操作的内部。

2.2 诊断系统核心代码

在系统中，我们实现了专门的调试模块 debug_test.c：

#include "debug_test.h"
#include "main.h"
#include <stdio.h>

// 操作类型定义
#define PERIPH_TRACE_MAGIC           0xCAFE1234
#define PERIPH_OP_QSPI_DISABLE_MMAP  0x01
#define PERIPH_OP_QSPI_ENABLE_MMAP   0x02
#define PERIPH_OP_QSPI_ABORT         0x03
#define PERIPH_OP_PSRAM_WRITE        0x04
#define PERIPH_OP_PSRAM_READ         0x05
#define PERIPH_OP_PSRAM_QSPI_CMD     0x06
#define PERIPH_OP_PSRAM_QSPI_TXRX    0x07
#define PERIPH_OP_SD_READ            0x08
#define PERIPH_OP_SD_WRITE           0x09
#define PERIPH_OP_I2C_READ           0x0A
#define PERIPH_OP_I2C_WRITE          0x0B

// 使能备份域写访问 (RTC 寄存器需要开启 DBP 才能写入)
static void Bkp_EnableWrite(void) {
    if (!(PWR->CR & PWR_CR_DBP)) {
        PWR->CR |= PWR_CR_DBP;
    }
}

// 记录：进入外设操作
void DebugTest_PeriphEnter(uint32_t op_type, uint32_t param1, uint32_t param2) {
    Bkp_EnableWrite();
    RTC->BKP2R = PERIPH_TRACE_MAGIC;
    RTC->BKP3R = op_type;
    RTC->BKP4R = param1;
    RTC->BKP5R = param2;
    RTC->BKP6R = HAL_GetTick(); // 记录进入时的系统 tick，复位后可推算死机耗时
}

// 清除：退出外设操作
void DebugTest_PeriphExit(void) {
    Bkp_EnableWrite();
    RTC->BKP2R = 0; // 清除有效标记
}

// 重启时打印诊断信息
void DebugTest_PrintPeriphTrace(void) {
    uint32_t magic = RTC->BKP2R;
    if (magic != PERIPH_TRACE_MAGIC) {
        printf("  -> No stuck peripheral op recorded.\r\n");
        return;
    }
    
    uint32_t op     = RTC->BKP3R;
    uint32_t param1 = RTC->BKP4R;
    uint32_t param2 = RTC->BKP5R;
    uint32_t enter  = RTC->BKP6R;

    printf("\r\n========================================\r\n");
    printf("  *** STUCK IN PERIPHERAL OPERATION! ***\r\n");
    printf("  Operation : %lu (Enter tick: %lu ms)\r\n", op, enter);
    printf("  Param1    : 0x%08lX, Param2: 0x%08lX\r\n", param1, param2);
    printf("========================================\r\n\r\n");

    // 读取后清除，避免下一次普通重启误读
    Bkp_EnableWrite();
    RTC->BKP2R = 0;
}

在外设操作中封装该接口，以 PSRAM 读取为例：

PSRAM_Status PSRAM_ReadPage(uint32_t address, uint8_t *data, uint32_t size) {
    PSRAM_Status status;
    
    // 【记录遗言】
    DebugTest_PeriphEnter(PERIPH_OP_PSRAM_READ, address, size);
    
    // 实际的 QSPI 传输过程
    DebugTest_PeriphEnter(PERIPH_OP_PSRAM_QSPI_CMD, address, size);
    if (HAL_QSPI_Command(&hqspi, &s_command, TIMEOUT) == HAL_OK) {
        DebugTest_PeriphEnter(PERIPH_OP_PSRAM_QSPI_TXRX, address, size);
        HAL_QSPI_Receive(&hqspi, data, TIMEOUT);
    }
    
    // 【顺利退出】
    DebugTest_PeriphExit();
    return status;
}

2.3 揪出真凶

将此“黑匣子”烧录入设备后进行压力测试。数小时后设备如期重启，控制台赫然打印出崩溃时的痕迹：

========================================
  RESET REASON DETECTION
  RCC_CSR = 0x1C000000
  -> IWDG Watchdog Reset ***
========================================

========================================
  PERIPHERAL OPERATION TRACE
  *** STUCK in peripheral operation! ***
  Operation : HAL_QSPI_Transmit/Receive (code 7)
  Param1    : 0x00405200 (4215296)
  Param2    : 0x00000400 (1024)
  Enter tick: 2451200 ms
========================================

黑匣子铁证如山：系统卡死在 QSPI 对 PSRAM 的底层传输 HAL_QSPI_Transmit/Receive 阶段，从而被看门狗复位！

3. 故障原因深度分析

锁定故障在 QSPI-PSRAM 的数据收发环节后，我们结合 STM32 HAL 库源码以及 ESP-PSRAM64 的 Datasheet，从时序、机制、库函数设计三个维度进行了深究，揪出了导致死锁的三个元凶：

3.1 元凶一：片选拉高恢复时间（ $t_{CPH}$ ）不足导致的硬件竞态锁死

ESP-PSRAM64 是一种伪静态随机存储器，虽然接口类似于 SPI/QSPI Flash，但其内部实际上是 DRAM 结构。每一次片选信号拉高（CS High）后，PSRAM 内部的状态机都需要一定的片选高电平恢复时间（即 $t_{CPH}$ ，根据数据手册通常需要至少 50ns）来进行内部的预充电或状态复位。

原有配置：我们原本的 QSPI 配置中片选拉高时间设置为 QSPI_CS_HIGH_TIME_4_CYCLE。在系统主频 180MHz 下，若 QSPI 分频系数为 4（总线频率 36MHz，周期约 27.7ns），4 个时钟周期的 CS 高电平时间理论上足够。然而，在高温、高频连续读写、或频繁在“内存映射模式”和“普通指令模式”之间切换的临界状态下，印制板的寄生电容会导致 CS 信号上升沿变缓，导致 PSRAM 无法获取足够的恢复时间，引发其内部状态机竞态锁死，停止响应任何总线读写，总线被强行挂起。

3.2 元凶二：STM32 HAL 库的“死等”超时机制

如果 PSRAM 发生了硬件级别的状态机锁死，不再响应总线，STM32 的 QSPI 外设状态机会持续检测到 BUSY 标志，或者在等待 FIFO 缓冲区时陷入无限停滞。

HAL 库代码缺陷：在 HAL 库的底层函数中，例如 HAL_QSPI_Transmit，虽然有一个超时参数，但是在许多关键的等待状态中（例如等待总线空闲、等待 FIFO 阀值），如果传入的参数是默认的 HAL_QPSI_TIMEOUT_DEFAULT_VALUE（值为 0xFFFFFFFF，约合 49.7 天），它相当于无限期死等。
一旦发生硬件锁死，CPU 就会在 HAL QSPI 的 while(__HAL_QSPI_GET_FLAG(hqspi, ...)) 中无限循环空转，导致其他优先级低于中断的任务或主循环全部被挂起，最终独立看门狗超时被触发。

3.3 元凶三：内存映射模式（Memory-Mapped）下的刷新冲突

由于 PSRAM 的 DRAM 属性，为了防止数据因电荷泄漏而丢失，它必须定时进行自我刷新（Self-Refresh）。
在 STM32 的内存映射模式下，MCU 将外部 PSRAM 直接映射到 CPU 的寻址空间（例如 0x90000000）。如果 CPU 频繁发起高速总线请求，导致 QSPI 片选信号（CS）长时间被拉低而得不到释放，PSRAM 内部的刷新操作就会被阻塞。

这不仅会造成地图数据乱码、花屏，而且极易由于总线时序冲突导致 QSPI 硬件状态机彻底跑飞，引发死锁。

4. 全方位加固与自愈方法

针对上述问题，我们采取了“放宽硬件时序 + 限制软件超时 + 强制硬件自愈 + 业务层防错退出”的联合闭环解决策略。

4.1 放宽硬件时序：调整分频与最大化 CS 高电平

首先在时序上妥协，降低时钟频率，拉长恢复时间，以获取极高的硬件稳定裕量。

降低总线频率：将 QSPI 时钟分频值 ClockPrescaler 从 4 调整为 5。
在 180MHz 的系统主频下，分频系数为 $P r esc a l er + 1$ ，总线频率由原来的：
$180MHz4+1=36MHz\frac{180\text{MHz}}{4 + 1} = 36\text{MHz}$
降低到了：
$180MHz5+1=30MHz\frac{180\text{MHz}}{5 + 1} = 30\text{MHz}$
虽然极限读写带宽略微减少了 16%，但这使时钟采样和总线信号的时序余量明显增大。
强行拉长片选恢复期：将 ChipSelectHighTime 设定为最大值 QSPI_CS_HIGH_TIME_8_CYCLE（即 8 个时钟周期，在 30MHz 下约 266ns）。这给 PSRAM 内部提供了远远超出手册最小要求的状态复位时间，彻底杜绝了因 CS 恢复太快而产生的竞态锁死。

4.2 超时时间软化（Soft-Timeout）

放弃 HAL 库极其危险的默认无限超时，为不同级别的 QSPI 操作赋予合理的“短超时”。
我们定义了以下常数：

#define PSRAM_QSPI_TIMEOUT_INIT  100   // 初始化阶段超时 100ms
#define PSRAM_QSPI_TIMEOUT_DATA  10    // 读写数据阶段超时 10ms

将所有的 HAL_QSPI_Command、HAL_QSPI_Transmit、HAL_QSPI_Receive 中的超时参数由 HAL_QPSI_TIMEOUT_DEFAULT_VALUE 全部改为上述常数。这样一旦硬件异常，CPU 可以在最多 10ms 内抽身，避免被看门狗复位。

4.3 强行中止自愈机制（HAL_QSPI_Abort）

仅仅做到超时跳出还不够，因为此时 STM32 的 QSPI 外设内部状态机依然处于 Busy 或者 Error 状态，后续的读写请求依然会全部超时。为此我们加入了硬件自愈机制：

如果传输函数返回了 HAL_TIMEOUT 或错误，我们立刻调用 HAL_QSPI_Abort(&hqspi)。

HAL_QSPI_Abort 的作用：它会直接向 QSPI 控制器发送中止命令，强行复位 QSPI 控制器的内部状态机，清除 BUSY 标志，释放总线。
如果超时发生在前文处于内存映射（Memory-Mapped）的间隙，我们在 Abort 之后重新使能内存映射读取，保证后续主程序通过指针对 PSRAM 进行只读访问时能够恢复正常工作。

修改后的写页面（Write Page）自愈代码：

PSRAM_Status PSRAM_WritePage(uint32_t address, uint8_t *data, uint32_t size) {
    // ... 前置状态判断与指令封装 ...

    DebugTest_PeriphEnter(PERIPH_OP_PSRAM_WRITE, address, size);
    DebugTest_PeriphEnter(PERIPH_OP_PSRAM_QSPI_CMD, address, size);
    
    // 1. 发送写指令（使用短数据超时 10ms）
    if (HAL_QSPI_Command(&hqspi, &s_command, PSRAM_QSPI_TIMEOUT_DATA) != HAL_OK) {
        HAL_QSPI_Abort(&hqspi); // 【关键自愈】强行中止并重置 QSPI 状态机，清除忙标志
        if (was_mapped) QSPI_EnableMemoryMappedRead(); // 恢复内存映射模式
        DebugTest_PeriphExit();
        return PSRAM_ERROR_WRITE;
    }

    DebugTest_PeriphEnter(PERIPH_OP_PSRAM_QSPI_TXRX, address, size);
    
    // 2. 传输数据（使用短数据超时 10ms）
    if (HAL_QSPI_Transmit(&hqspi, data, PSRAM_QSPI_TIMEOUT_DATA) != HAL_OK) {
        HAL_QSPI_Abort(&hqspi); // 【关键自愈】强行中止并重置 QSPI 状态机
        if (was_mapped) QSPI_EnableMemoryMappedRead();
        DebugTest_PeriphExit();
        return PSRAM_ERROR_WRITE;
    }

    // 重新开启内存映射模式
    if (was_mapped) {
        QSPI_EnableMemoryMappedRead();
    }
    
    DebugTest_PeriphExit();
    return PSRAM_OK;
}

4.4 优化内存映射的 CS 超时释放

为了兼顾 PSRAM 内部刷新需求和总线读取性能，我们将内存映射的 CS 自动超时释放机制进行了优化：

QSPI_MemoryMappedTypeDef s_mem_mapped_cfg;
s_mem_mapped_cfg.TimeOutActivation = QSPI_TIMEOUT_COUNTER_ENABLE;
s_mem_mapped_cfg.TimeOutPeriod     = 64; // 修改为 64 个时钟周期

当外部 QSPI 控制器在 64 个时钟周期内没有新的读写请求时，会自动拉高片选 CS。这极大地减少了总线连续占用的机会，保障了 PSRAM 极其苛刻的内部刷新周期，彻底消除了由于“刷新被饿死”引发的画面撕裂、花屏及二次锁死。

4.5 业务层保护退出

在应用层（如 Core/Src/APP.c 的地图渲染与裁剪函数 cut_mapdata）中，对 PSRAM 读写函数的返回值进行捕获。一旦捕获到 QSPI 传输超时错误（而非直接卡死），立即退出循环并停止向屏幕发送像素，避免了脏数据（乱码、花屏数据）被写入 LCD 显存，进一步提高了软件的鲁棒性。

5. 测试验证与总结

在应用了上述“软硬件双加固”方案后，我们对设备进行了极限压力测试：

测试用例：控制设备以最高频的速率进行轨迹点的快速渲染，同时多线程持续读取瓦片地图，在 PSRAM 中进行极高频的读写交替测试。
测试结果：
- 改进前：在此压力下，设备基本在运行 20分钟至 1.5小时 内就会因看门狗超时而重启。
- 改进后：设备成功连续稳定运行 16 个小时以上，没有发生过一次死机或复位，且地图画面无任何乱码或撕裂现象。

结论与启示

永远不要信任外设的无限超时：在生产环境的嵌入式代码中，凡是涉及 while 循环等待外设寄存器标志的，必须全部实现限时软超时，并配以自愈（Reset/Abort）代码。
注重硬件时序余量：当通信总线在边界情况下容易死锁时，往往是时序余量不足导致的竞态条件。放宽时钟频率和延长高电平恢复时间，虽然损失了极其微小的理论带宽，换来的却是系统的工业级稳定。
黑匣子调试思维：利用微控制器在复位时不丢失内容的特殊物理存储介质（如 RTC 备份寄存器、外部 EEPROM、内部 Flash 扇区等）进行状态跟踪，对于捕获偶发性死机具有降维打击的效果。