|
|
# GD32H757ZMT6 运行跑飞/锁死问题说明
## 1. 问题概述
芯片型号：GD32H757ZMT6
当前问题表现为：同一硬件、同一工程代码、同一编译环境下，仅因 Flash/Load image 布局变化，程序运行稳定性就出现明显差异。
- 正常版本：程序可以正常运行。
- 异常版本：在正常版本基础上，仅将 `project.sct` 中 flash执行区增加 `ALIGNALL 4`，程序上电运行约十几秒后出现跑飞或系统锁死。
- 两个版本的 RAM 执行地址、RAM 区域大小以及 Total RW 大小在 map 中保持一致。
- 异常版本的主要变化体现在 Flash/Load image 布局上，map 显示 RO/ROM 仅增加 4 字节，后续 load 地址整体后移 4 字节。
换句话说，当前现象不应理解为“去掉 `ALIGNALL 4` 后问题就彻底消失”，而是说明问题本质上是对 Flash/Load image 布局变化敏感。只要后续代码增量导致 Flash 地址分布发生偏移，即使业务逻辑不变，也可能再次触发跑飞；`ALIGNALL 4` 只是当前已复现的一个触发条件，不是唯一根因。
随文档提供的对比文件夹如下：
- 正常版本：`正常的(代码及配置和死机一样 , 这个正常跑)`
- 异常版本：`跑飞的(在正常的基础上 ,仅将sct文件改为4字节对齐),看map只有flash地址有些变动`
每个文件夹中均包含：
- `project.sct`
- `output.map`
- `output.htm`
- `output.hex`
- `output.axf`
## 2. 异常现象
异常版本上电运行后，通常在开机十几秒后出现跑飞或系统锁死。
异常发生后表现如下：
- 程序不进入 HardFault。
- 已使能以下异常后，仍不进入对应异常处理：
- `SCB_SHCSR_MEMFAULTENA_Msk`
- `SCB_SHCSR_BUSFAULTENA_Msk`
- `SCB_SHCSR_USGFAULTENA_Msk`
- 调试器与芯片失联。
- Keil Watch 窗口中的观察值变为 `0xAA`。
- SWD 口完全无法通信。
- J-Link、ST-Link、DAP-Link 都出现相同现象。
- 使用 J-Link Commander 发送 SWD 相关命令也无法通信。
- 无法通过 SWD 命令读取芯片状态或寄存器。
- 软件 reset 或调试器 reset 无法恢复连接。
- 只能通过硬件 RESET 引脚拉低后，芯片才可以重新启动并恢复烧录、调试。
该现象不像普通 HardFault 或可调试状态下的程序跑飞，更像芯片进入了内核、总线或调试口不可访问的严重锁死状态。
## 3. 当前复现条件
当前对比版本的关键复现条件如下：
- 使用同一块硬件板卡。
- 使用同一份工程代码。
- 使用同一套 Keil 编译环境和编译配置。
- 正常版本和异常版本仅 `project.sct` 不同。
- 异常版本只是在正常版本 scatter 文件的Flash执行区增加 `ALIGNALL 4`。
- 未修改 C/汇编源代码。
- 未修改外设初始化代码。
- 未修改全局变量、局部变量或 RAM 分区定义。
- 正常版本可以运行。
- 异常版本运行十几秒后锁死并导致 SWD 失联。
因此，相关芯片级影响集中在 Flash 取指地址、代码布局、对齐、Cache、预取、等待周期、总线矩阵和调试口访问。
## 4. Scatter 文件差异
### 4.1 正常版本 scatter
正常版本 `project.sct` 中各执行区定义如下：
```sct
LR_IROM1 0x08000000 0x003C0000 {
ER_IROM1 0x08000000 0x003C0000 {
}
RW_DTCM 0x20000000 0x00020000 {
}
RW_IRAM1 0x24000000 0x000D0000 {
}
RW_RAM1 0x30000000 0x00004000 {
}
RW_RAM2 0x30004000 0x00004000 {
}
}
```
完整内容见附件：
`正常的(代码及配置和死机一样 , 这个正常跑)\project.sct`
### 4.2 异常版本 scatter
异常版本 `project.sct` 中，各执行区均增加了 `ALIGNALL 4`：
```sct
LR_IROM1 0x08000000 0x003C0000 {
ER_IROM1 0x08000000 ALIGNALL 4 0x003C0000 {
}
RW_DTCM 0x20000000 0x00020000 {
}
RW_IRAM1 0x24000000 0x000D0000 {
}
RW_RAM1 0x30000000 0x00004000 {
}
RW_RAM2 0x30004000 0x00004000 {
}
}
```
完整内容见附件：
`跑飞的(在正常的基础上 ,仅将sct文件改为4字节对齐),看map只有flash地址有些变动\project.sct`
### 4.3 scatter 差异说明
两个 scatter 文件的区域起始地址和区域大小一致：
| 区域 | 起始地址 | 大小 | 正常版本 | 异常版本 |
|---|---:|---:|---|---|
| `ER_IROM1` | `0x08000000` | `0x003C0000` | 无 `ALIGNALL 4` | 有 `ALIGNALL 4` |
| `RW_DTCM` | `0x20000000` | `0x00020000` | 无 `ALIGNALL 4` | 无 `ALIGNALL 4` |
| `RW_IRAM1` | `0x24000000` | `0x000D0000` | 无 `ALIGNALL 4` | 无 `ALIGNALL 4` |
| `RW_RAM1` | `0x30000000` | `0x00004000` | 无 `ALIGNALL 4` | 无 `ALIGNALL 4` |
| `RW_RAM2` | `0x30004000` | `0x00004000` | 无 `ALIGNALL 4` | 无 `ALIGNALL 4` |
也就是说，本次复现中没有改变 RAM 区域起始地址、RAM 区域大小、Flash 起始地址或 Flash 总大小，只改变了 scatter 对输入 section 的对齐放置规则。
## 5. Map 文件对比
以下数据来自当前两个附件文件夹内的 `output.map`。
| 项目 | 正常版本 | 异常版本 | 差异 |
|---|---:|---:|---:|
| `LR_IROM1` Size | `0x000d4188` | `0x000d418c` | `+0x4` |
| `LR_IROM1` Compressed | `0x0005c0c4` | `0x0005c0c8` | `+0x4` |
| `ER_IROM1` Exec base | `0x08000000` | `0x08000000` | 相同 |
| `ER_IROM1` Size | `0x0005b090` | `0x0005b094` | `+0x4` |
| `RW_DTCM` Exec base | `0x20000000` | `0x20000000` | 相同 |
| `RW_DTCM` Load base | `0x0805b090` | `0x0805b094` | `+0x4` |
| `RW_DTCM` Size | `0x0001d9b8` | `0x0001d9b8` | 相同 |
| `RW_IRAM1` Exec base | `0x24000000` | `0x24000000` | 相同 |
| `RW_IRAM1` Load base | `0x0805b3dc` | `0x0805b3e0` | `+0x4` |
| `RW_IRAM1` Size | `0x000b0dfc` | `0x000b0dfc` | 相同 |
| `RW_RAM1` Size | `0x00000000` | `0x00000000` | 相同 |
| `RW_RAM2` Size | `0x00000000` | `0x00000000` | 相同 |
| Total RO Size | `372880` | `372884` | `+4` |
| Total RW Size | `845748` | `845748` | 相同 |
| Total ROM Size | `377028` | `377032` | `+4` |
map 对比结论：
- 两个版本的 RAM 执行地址一致。
- `RW_DTCM`、`RW_IRAM1` 的执行区大小一致。
- `RW_RAM1`、`RW_RAM2` 均没有分配 section。
- Total RW 大小一致。
- 异常版本的 `ER_IROM1` 仅增加 4 字节。
- 异常版本的后续 load 地址相对正常版本后移 4 字节。
- 从当前 map 看，差异主要是 Flash/Load image 布局和对齐变化，而不是 RAM 数据布局变化。
## 6. 当前开启的外设和硬件条件
当前工程中已开启或使用的主要模块如下：
- UART + DMA
- SPI
- IIC
- FDCAN
- FMC：上电后读取内部 Flash
- EXMC：存在 16 位指针对齐取值的访问场景
- 其余大部分为普通 GPIO
- PA15 硬件未实际使用，但程序开机初始化后会将 PA15 拉高
## 7. 工程配置和初始化信息
以下信息来自当前已整理的工程配置和 Keil 配置。
### 7.1 编译和链接条件
- Keil target：`QCD7000_Main`
- 设备：`GD32H757ZM`
- 编译器：ARMCC V5.06 update 7 build 960
- 内核：Cortex-M7
- FPU：double precision FPU
- 使用 scatter 文件：`project.sct`
- 当前工程宏包含：`GD32H7XX`、`USE_HAL_DRIVER`
- C 编译选项中存在 `Optim=2`
### 7.2 内存布局
当前 scatter 中主要区域如下：
- Flash：`0x08000000`，大小 `0x003C0000`
- DTCM：`0x20000000`，大小 `0x00020000`
- AXI/Share SRAM：`0x24000000`，大小 `0x000D0000`
- SRAM1：`0x30000000`，大小 `0x00004000`
- SRAM2：`0x30004000`，大小 `0x00004000`
当前 map 显示 `0x30000000` 和 `0x30004000` 两个区域没有分配 section，主要 RAM 使用集中在 DTCM 和 `0x24000000` 区域。
### 7.3 启动文件行为
启动文件 `startup_gd32h7xx.s` 中：
- Stack size：`0x00003C00`
- Heap size：`0x00002400`
- 向量表位于 Flash 起始区域。
- Reset 后、调用 `SystemInit` 前，会从 `Image$$RW_IRAM1$$RW$$Base` 开始清零 `0x8000` 字节。
- HardFault、NMI 等默认弱定义处理为 `B .` 死循环；当前 C 文件中 HardFault 处理函数是注释状态，MemManage、BusFault、UsageFault 有独立函数但也只是死循环。
启动阶段固定清零 `0x8000` 字节与当前 scatter/RAM 分配相关。
### 7.4 SystemInit、时钟和 Cache 顺序
本节只说明系统初始化和时钟配置顺序。当前代码不是上电后一次性进入最终时钟，而是存在两次系统时钟配置：
1. Reset 后进入 `SystemInit()`，先执行启动阶段的系统初始化和一次时钟配置。
2. 进入应用初始化 `System_Init()` 后，先配置 MPU 和 Cache，再调用 `SystemClock_Config()` 重新配置到最终运行时钟。
当前工程中 `HXTAL_VALUE` 和 `HAL_HXTAL_VALUE` 均为 8MHz。后文频率均按 8MHz HXTAL 推算。
#### 7.4.3 应用层 `SystemClock_Config()` 最终时钟
应用层 `System_Init()` 会调用 `SystemClock_Config()` 重新配置系统时钟。该阶段才是程序稳定运行后的最终时钟配置。
当前配置如下：
| 项目 | 配置 |
|---|---:|
| PLL source | `RCU_PLL_SRC_CK_HXTAL` |
| HXTAL | 8MHz |
| `pll0_psc` | `RCU_PLL_PSC_2` |
| `pll0_n` | `RCU_PLLN_MUL_84` |
| `pll0_p` | `RCU_PLLP_DIV_1` |
| `pll0_q` | `RCU_PLLQ_DIV_16` |
| `pll0_r` | `RCU_PLLR_DIV_2` |
| PLL0 input range | `RCU_PLL0RNG_4M_8M` |
| PLL0 output range | `RCU_PLL0VCO_192M_836M` |
| SYSCLK source | `RCU_SYSCLK_SRC_CK_PLL0P` |
| AHB 分频 | `RCU_SYSCLK_AHBDIV_2` |
| APB1 分频 | `RCU_AHBCLK_APB1DIV_2` |
| APB2 分频 | `RCU_AHBCLK_APB2DIV_1` |
| APB3 分频 | `RCU_AHBCLK_APB3DIV_2` |
| APB4 分频 | `RCU_AHBCLK_APB4DIV_2` |
按 `PLL0P = 8MHz / 2 * 84 / 1` 推算，应用层最终时钟树为：
| 时钟 | 推算频率 |
|---|---:|
| PLL0P / SYSCLK | 336MHz |
| PLL0Q | 21MHz |
| PLL0R | 168MHz |
| AHB / HCLK | 168MHz |
| APB1 | 84MHz |
| APB2 | 168MHz |
| APB3 | 84MHz |
| APB4 | 84MHz |
| EXMC clock source | `CK_AHB`，约 168MHz |
| CAN1 clock source | `CK_APB2 / 2`，约 84MHz |
| SPI2 clock source | `CK_PLL0Q`，约 21MHz |
| SPI3/SPI4 clock source | `CK_APB2`，约 168MHz |
| I2C1/I2C2 clock source | `CK_APB1`，约 84MHz |
| USART0 clock source | `CK_APB` |
#### 7.4.5 本节信息
- 启动阶段 `SystemCoreClock = 336000000` 与寄存器推算 SYSCLK 128MHz 不一致，对 SysTick、HAL timeout、Flash wait state、TCM wait state 的影响。
- MPU/Cache 已开启后，再执行应用层 `SystemClock_Config()` 切换系统时钟的顺序。
- `SystemClock_Config()` 中未看到显式 Flash wait state 配置。
- 最终 EXMC 时钟约 168MHz，与 7.6 中 EXMC 16 位异步访问时序对应。
### 7.5 MPU 配置
当前 `bsp.c` 中启用了 MPU，主要区域如下：
- `0x24000000`，512KB，Cacheable、Bufferable、Non-shareable，允许执行
- `0x30000000`，16KB，Cacheable、Bufferable、Non-shareable，允许执行
- `0x30004000`，16KB，Cacheable、Bufferable、Non-shareable，允许执行
- `0x24080000`，512KB，Cacheable、Bufferable、Non-shareable，允许执行
- `0x60000000`，64MB，Non-cacheable、Non-bufferable、Shareable，允许执行
- `0x68000000`，64MB，Non-cacheable、Non-bufferable、Shareable，允许执行
MPU 相关信息项：
- `0x60000000` 和 `0x68000000` 外部映射区域的指令执行权限。
- Shareable、Non-cacheable、Non-bufferable 组合与当前 EXMC 访问的匹配性。
- `0x24080000` 512KB 区域与 `0x24000000` 512KB 相邻区域和 GD32H757ZMT6 实际 RAM/共享区划分的匹配性。
- PC 跑飞到外部映射区时的取指和非预期总线访问风险。
### 7.6 EXMC 16 位外部访问
当前工程中有两个外部映射地址：
- `0x68000000`
- `0x60000000`
EXMC 配置：
- 存储类型按 SRAM 配置
- 16 位数据总线
- 地址/数据不复用
- 异步访问模式 A
- Burst 关闭
- NWAIT 关闭
- 扩展模式开启
- 异步写模式
- 地址建立时间：20 个 EXMC 时钟
- 地址保持时间：0
- 数据建立时间：20 个 EXMC 时钟
- 总线延迟：0
- 代码中直接使用 `volatile uint16_t *` 对 `0x60000000` / `0x68000000` 进行 16 位读写
- EXMC 相关 GPIO 配置为较高速率输出
- 外部采样触发频率初始化为 6400Hz
EXMC 相关信息项：
- 当前 EXMC 时钟源和真实频率下的时序裕量。
- `asyn_address_holdtime = 0`、`bus_latency = 0` 在 GD32H757ZMT6 上的边界风险。
- 外部映射区 16 位访问在优化、合并、重排或异常取指误访问场景下的总线异常机制。
- 外部设备未响应或时序异常时，SWD 不可访问的关联机制。
### 7.7 内部 Flash 访问
工程中存在内部 Flash 读写库：
- Flash base：`0x08000000`
- Flash size：`0x003C0000`
- Sector size：`0x1000`
- Sector count：960
- 读操作直接使用 `volatile` 指针从 Flash 地址读取。
- 写操作会关闭中断，解锁 FMC/OB，按 sector 擦除，再按 word 编程。
- 写操作前后有 `SCB_CleanInvalidateDCache()`，但未看到对 I-Cache 的同步失效处理。
如果异常版本运行中会访问内部 Flash，相关信息如下：
- 内部 Flash 取指与数据读取并发限制。
- 运行中擦写内部 Flash 时的 I-Cache/D-Cache 和同步序列要求。
- 当前 Flash wait state、Cache、预取和 FMC 状态位处理完整性。
### 7.8 PA15 和复位/调试相关条件
当前代码中 PA15 配置为：
- GPIOA 时钟开启
- 推挽输出
- 上拉
- 速度 `GPIO_OSPEED_85MHZ`
- 初始化后立即输出高电平
PA15 硬件上空置 , 未接出。
### 7.9 已参考官方文档排查和处理的死机相关项
已参考以下两个官方文档中与死机、HardFault、调试口失联、总线卡住、Cache、MPU、EXMC、时钟和复位相关的条目：
- `AN111 GD32H73x_75x 软件开发指南_Rev1.1.pdf`
- `GD32H73x&H75x芯片使用限制_Rev1.7.pdf`
当前已针对这些可能导致死机或调试失联的方向做了处理或排除，信息如下。
| 文档条目 | 可能影响 | 当前处理/排除情况 |
|---|---|---|
| AN111：PMU/SMPS 初始化配置需在 PLL 配置前完成，且必须匹配外部供电电路 | 供电模式配置错误可能导致高主频或高负载下异常，严重时可能损坏芯片 | 当前硬件按不使用 SMPS 的方式处理；工程未启用 `SEL_PMU_SMPS_MODE`，应用层 `SystemClock_Config()` 中 LDO/SMPS 配置代码处于注释状态。 |
| AN111：POR_ON 引脚需接 VDD，否则 POR 后部分寄存器可能不在复位状态 | 上电复位不完整可能导致随机异常或调试困难 | 已检查硬件复位相关设计 POR_ON是接在VDD(3.3V电源)上 |
| AN111：进入睡眠模式后无法通过下载器下载和调试 | 低功耗状态可能导致调试器无法连接 | 当前异常复现不是主动进入睡眠/待机模式导致；已按该方向排除。 |
| AN111：外设时钟切换前需保证目标时钟已开启且稳定 | 外设时钟动态切换不当可能导致外设异常或总线访问异常 | 当前 `SystemClock_Config()` 通过 HAL 配置 PLL 和外设时钟源，配置函数会等待 PLL 稳定；工程存在启动阶段和应用层两次时钟配置。 |
| AN111：高速、高温下监控结温，超过阈值需降频 | 高温高频可能导致性能下降或更严重问题 | 室温 ,且正常代码和异常代码同一温度同一硬件。 |
| AN111：Keil 调试时打开 EXMC 驱动地址的 Memory 窗口，下次打开可能导致 Keil IDE 卡死 | 调试器或 IDE 卡死可能被误认为芯片死机 | 已避免将该现象作为芯片运行异常依据；当前问题是在程序独立运行后 SWD 完全失联，且 J-Link/ST-Link/DAP-Link 均复现，并非单纯 Keil Memory 窗口卡死。 |
| AN111：D-Cache 与 DMA 同时使用需要处理一致性，地址和长度需 32 字节对齐 | DMA 数据不一致可能造成数据异常，进而引发程序异常 | UART0 DMA 收发缓冲区已按 32 字节对齐；相关收发路径中已有 `SCB_CleanDCache_by_Addr()`、`SCB_InvalidateDCache_by_Addr()` 等处理。应用初始化中已开启 I-Cache/D-Cache，并执行 `SCB_CleanInvalidateDCache()`。 |
| AN111：Cache 操作 API 的地址需 32 字节边界对齐，长度需为 32 字节整数倍 | Cache 操作范围不正确可能导致数据一致性问题 | 当前 UART DMA 路径中对长度按 32 字节向上对齐后再执行 Cache 操作。 |
| AN111：EXMC SDRAM 非对齐访问可能进 HardFault，需要用 MPU 修改 SDRAM 属性 | 非对齐外部存储访问可能触发 HardFault 或异常 | 当前工程未使用 SDRAM，EXMC 配置为 SRAM 类型；外部访问地址为 `0x60000000` / `0x68000000`，代码使用 `volatile uint16_t *` 进行 16 位访问。该条目按当前使用方式已规避。 |
| 芯片使用限制：非法地址访问会导致 ECC 错误 | PC 跑飞或非法指针访问可能引发 ECC/总线异常 | 当前业务代码已按合法地址访问排查；但异常表现为不进 fault handler 且 SWD 失联。 |
| 芯片使用限制：高主频、向量表和中断代码均放 ITCM、高频中断时可能导致 ITCM ECC 误报 | 高频中断场景下可能误报 ECC | 当前向量表位于 Flash，未将向量表和中断处理代码同时放入 ITCM；最终 SYSCLK 按代码推算约 336MHz，低于文档举例中高于 350MHz 的条件。 |
| 芯片使用限制：使用低功耗调试功能时，SWD/JTAG 调试功能失效 | 调试接口可能失效 | 当前未使用低功耗调试保持功能，未发现 `STB_HOLD`、`DSLP_HOLD`、`SLP_HOLD` 相关配置。该项已排除。 |
| 芯片使用限制：PA15 为低电平时 SWD 连接失败 | SWD 无法连接 | 当前代码在开机初始化中将 PA15 配置为 GPIO 输出并拉高，已按该条目处理。 |
| 芯片使用限制：EXMC 访问 SDRAM 期间可能出现总线卡住 | 总线卡住可能导致系统不可调试或锁死 | 当前未使用 SDRAM，EXMC SRAM burst 已关闭；外部映射区域 MPU 配置为 Non-cacheable、Non-bufferable，用于避免外部访问出现额外 CS/WE 行为。该 SDRAM 条目不完全适用于当前 SRAM 模式，EXMC 异步 16 位访问风险已放入问题清单。 |
| 芯片使用限制：EXMC 不支持 SDRAM 非对齐地址访问 | 非对齐访问可能异常 | 当前未使用 SDRAM；EXMC 访问按 16 位指针进行，并已避免对外部设备做非对齐宽度访问。该项已按当前使用方式处理。 |
综上，官方文档中已知可能导致死机、HardFault、SWD/JTAG 失效或 EXMC 总线异常的条目均已按当前工程情况做了处理、规避或排除。当前异常仍然只随 `project.sct` 增加 `ALIGNALL 4` 后出现，说明问题本质上与 Flash/Load image 布局变化相关；`ALIGNALL 4` 只是当前已复现的具体触发方式，任何进一步引起 Flash 布局偏移的代码变更都可能再次触发异常。相关信息包括 Flash/Load image 布局变化、取指对齐、Cache/预取、Flash wait state、总线矩阵和 EXMC/FMC 并发访问的芯片级影响。
## 8. 信息摘要
信息如下：
1. 仅在 `project.sct` 中增加 `ALIGNALL 4` 后，Flash/Load image 布局轻微变化即可复现异常；该现象表明问题本质上是对 Flash 布局偏移敏感，后续任何引起布局变化的代码增量都可能触发类似异常。
2. 异常未进入 HardFault / MemManage / BusFault / UsageFault，且 SWD 完全失联。
3. 启动阶段 `SystemInit()` 先配置一次时钟，应用层 `System_Init()` 在 MPU/Cache 后再次切换系统时钟。
4. 最终运行时 EXMC 时钟约 168MHz，外部映射区使用 16 位异步访问 `0x60000000` / `0x68000000`。
5. 内部 Flash 存在读写库，写操作前后有 `SCB_CleanInvalidateDCache()`，未见 I-Cache 同步失效处理。
6. PA15 上电初始化为 GPIO 输出高电平。
|
|
发表于 
楼主
发表于 
