STM32嵌入式黑匣子：崩溃日志记录与调试方案

1. 项目概述：嵌入式黑匣子的必要性

在嵌入式系统开发中，最令人头疼的问题莫过于设备在现场运行一段时间后突然崩溃或重启。想象一下这样的场景：你的STM32设备已经在客户现场稳定运行了72小时，突然毫无征兆地死机了。当你赶到现场连接调试器时，设备又神奇地恢复正常运行。这种偶发性故障就像幽灵一样难以捕捉，传统的调试手段在这种场景下几乎束手无策。

这就是为什么我们需要为STM32设计一个"黑匣子"系统。就像飞机上的黑匣子记录飞行数据一样，我们的嵌入式黑匣子会在系统崩溃前的最后一刻，将关键信息（包括文件名、行号和时间戳）保存到Flash中。当下次上电时，系统会自动通过串口打印出这些"临终遗言"，帮助我们快速定位问题根源。

2. 核心方案设计

2.1 Flash空间规划与选择

选择合适的Flash存储区域是整个方案的基础。我们需要考虑以下几个关键因素：

1. 避开程序存储区：绝对不能覆盖正在执行的代码区域
2. 考虑Flash扇区结构：不同型号STM32的Flash扇区大小不同
3. 预留足够空间：既要满足存储需求，又要避免浪费

以STM32F407为例，它的Flash被划分为多个扇区，其中最后一个扇区（Sector 11）通常不会被程序占用，是理想的日志存储位置。我们可以这样定义：

c复制// CrashLog_Config.h
#if defined(STM32F103xB)  // F103C8T6 (64K)
    #define CRASH_LOG_ADDR 0x0800FC00  // 最后1KB空间
#elif defined(STM32F103xE) // F103RCT6 (256K)
    #define CRASH_LOG_ADDR 0x0803F800  // 最后2KB空间
#elif defined(STM32F407xx) // F407 (Sector 11)
    #define CRASH_LOG_ADDR 0x080E0000  // 整个128KB扇区
#endif

提示：在实际项目中，建议在链接脚本中明确保留这块区域，防止编译器将变量或代码放在这个区域。

2.2 日志数据结构设计

一个设计良好的日志结构应该包含足够的信息，同时保持紧凑。我们