求助: GD32H757ZMT6 仅因 Flash/Load image 布局变化，程序运行稳定性就出现明显差异。

让我看看各位

# 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 输出高电平。

让我看看各位

这是PDF格式 的 ,方便查看一下

eric2013

让AI分析这个，AI就是一个一个猜测。

可以考虑笨办法，从main开始所有代码注释掉，逐一开启测试下。

让我看看各位

eric2013 发表于 2026-7-6 15:10
让AI分析这个，AI就是一个一个猜测。

可以考虑笨办法，从main开始所有代码注释掉，逐一开启测试下。

好滴 ,我去试试 ,哪个AI比较专业 ,感觉豆包有点瞎编

eric2013

让我看看各位 发表于 2026-7-6 15:53
好滴 ,我去试试 ,哪个AI比较专业 ,感觉豆包有点瞎编

AI分析这种问题不行，手工排查比较靠谱。

小麦吉

果断用deepseekV4pro，啥问题都能找出来，一步一步给他反馈问题点

yelu

让我看看各位 发表于 2026-7-6 11:30
这是PDF格式 的 ,方便查看一下

我最近调试gd32h759的usb，死机现象和你的一样，jlink断开，断电重启恢复
1、关闭cache正常，开启cache运行一段时间死机
2、打开cache，使用-O0优化正常，-O1优化异常
3、打开cache，-O1优化，把keil rtx的调试事件生成取消勾选，程序正常，对于这个选项，仅仅是多了一点点代码，就死机
mcu的各个错误中断没有一个进入的，我也是第一次遇到这样的问题

让我看看各位

yelu 发表于 2026-7-8 13:04
我最近调试gd32h759的usb，死机现象和你的一样，jlink断开，断电重启恢复
1、关闭cache正常，开启cache ...

对对对 ,现象相同 ,一个现象 ,而且我之前也是O1 O2 O3 来回调 来规避死机 ,但是问题始终未解决

让我看看各位

其他论坛的 , 也有这样的问题 ,但是这个楼主有没有解决问题未知

可乐狂魔

GD32H7需要在MPU配置中添加对0X00000000区域的保护措施，不添加这个保护会出现异常死机现象……

让我看看各位

可乐狂魔 发表于 2026-7-9 16:29
GD32H7需要在MPU配置中添加对0X00000000区域的保护措施，不添加这个保护会出现异常死机现象……

感谢感谢 , 请问原理您知道么 ,或者有相关的资料么

让我看看各位

问题解决了 , 感谢GD原厂的"江将"工程师 , 感谢论坛的 "可乐狂魔"
这个问题在咱们论坛中的:https://forum.anfulai.cn/forum.p ... =1&extra=#pid354786
也是"可乐狂魔"提出的解决方法 ,经过测试确实解决了问题;

解决方法:
配置MPU时 ,先在1组将所有空间都进行保护 ,然后再配置用到的空间 ,将下面代码放到1组 ,且当前的mpu配置从2组开始顺延
mpu_region_init_struct mpu_init_struct;
    /* disable MPU */
    ARM_MPU_Disable();
   
    mpu_init_struct.region_number       = MPU_REGION_NUMBER0;
    mpu_init_struct.region_base_address = 0x00000000U;
    mpu_init_struct.instruction_exec    = MPU_INSTRUCTION_EXEC_NOT_PERMIT;
    mpu_init_struct.access_permission   = MPU_AP_NO_ACCESS;
    mpu_init_struct.tex_type            = MPU_TEX_TYPE0;
    mpu_init_struct.access_shareable    = MPU_ACCESS_SHAREABLE;
    mpu_init_struct.access_cacheable    = MPU_ACCESS_NON_CACHEABLE;
    mpu_init_struct.access_bufferable   = MPU_ACCESS_NON_BUFFERABLE;
    mpu_init_struct.subregion_disable   = 0x87;
    mpu_init_struct.region_size         = MPU_REGION_SIZE_4GB;  
   
    mpu_region_config(&mpu_init_struct);
    mpu_region_enable();
    /* enable MPU */
    ARM_MPU_Enable(MPU_MODE_PRIV_DEFAULT);



针对这个问题 : GD32H7官方的缺陷文档和软件变成手册 没有记录这个问题
ST32H7的官方资料中 ,有这相关的一句话 :STM32H7R7/S7图形处理性能 | TouchGFX Documentation 中的MPU配置中
"MPU 配置

内存保护单元 (MPU) 用于保护存储区域，防止非预期的内存访问和执行操作。
在Arm® Cortex®-M7处理器上，必须防止对外部存储器的推测性访问，否则可能引发高延迟或系统错误。 对于STM32H7R/S，这将影响访问内存的AXI主设备，并显著降低图形性能。
MPU可通过控制可访问的地址范围来防止推测性读取访问。 最简单的方法是使用包含整个内存区域的背景区域，通过将其设置为“强排序，永不执行”来限制访问。

背景区域应定义在默认区域ID-1中，因为所有其他区域的优先级都将高于此区域。 然后，应为需要访问的内存区域定义具有相应设置的其他MPU区域。 在STM32H7R/S上最多可定义16个区域。

"

可乐狂魔

解决了就好，这个问题之前也困扰我很久，我当时的现象的是芯片运行了10几个小时以上必然会出现死机现象，加了MPU保护就好了。

eric2013

让我看看各位 发表于 2026-7-10 09:49
问题解决了 , 感谢GD原厂的"江将"工程师 , 感谢论坛的 "可乐狂魔"
这个问题在咱们论坛中的:https://forum. ...

如果是预测问题导致的，直接关闭预测访问即可，这个在STM32H7的FMC访问静态设置时会有这个问题，出错时会话多次访问。

不希望预测访问的区域直接配置Device或者Strongly order模式即可。我们V7开发板做的FMC扩展32路IO有这个问题，配置这个地址的这个属性可以解决。

STM32H7的M7内核关闭指令预测访问方法
https://forum.anfulai.cn/forum.p ... d=111955&fromuid=58
(出处: 硬汉嵌入式论坛)


而4GB全局的这个设置，是直接防止防止预测访问落到未初始化的外部存储器区域，然后再单独配置外地地址区，我们这边当前基本没用这种设置方法，都是单独设置的。