简介：一份面向嵌入式开发者的 STM32H743 基础例程集合，覆盖 GPIO、看门狗、定时器、PWM、PWM 捕获、LCD 与 SRAM 等关键模块，适合刚接触该芯片或需要快速上手外设配置的开发者。压缩包共 2000 个文件，约 382MB，包含大量 C/C++ 源码、头文件、工程配置文件（如 uvprojx、uvoptx、icf、sct）以及说明文档，代码与配置结构清晰，便于直接对照学习。已有 1884 人学习下载。通过例程可掌握中断响应、定时器计数、PWM 输出与捕获测量、LCD 显示驱动以及内部 SRAM 空间分配等实用技能，理解 STM32H743 的硬件架构与寄存器操作方式，为后续项目开发搭建稳定起点。 STM32H743 这颗芯片，我最近半年拿它做了好几个项目，从最基础的 GPIO 点灯、串口打印，到后面接 OV2640 摄像头跑图像采集，一路走下来，最大的感受是：基础例程代码看着简单，但里面藏的东西其实不少。如果你手里已经有一块 H743 开发板，或者正打算从 F103/F407 切过来，这篇文章我建议你认真看看。我会结合自己跑 H743 基础例程的实际经历，把环境搭建、时钟树、串口、定时器、DMA 这些基础模块逐个讲透，最后再聊一下怎么从基础例程平滑过渡到 OV2640 摄像头这种综合项目。内容偏实操，适合正准备入坑或者已经在坑里的朋友。
1. H743 这颗芯片到底适合谁：从 F1/F4 过来的第一课
1.1 H743 和 F407 的差异，不是一个简单的“高配版”
很多从 F407 切过来的朋友，第一反应是：F407 已经 168MHz 了，H743 跑到 480MHz，不就是频率更高、Flash 更大吗？实际用下来你会发现，这颗芯片的复杂度是质的提升，不是量的提升。
F407 的内核是 Cortex-M4，没有 Cache，主频 168MHz，Flash 1MB，RAM 192KB。H743 是 Cortex-M7，带 32KB 的 I-Cache 和 32KB 的 D-Cache，主频 480MHz，Flash 2MB，RAM 更是夸张到了 1MB。这个规格带来的直接好处是：你可以跑一些轻量级的图像处理、音频算法，甚至裸机跑一个简单的 GUI 都不吃力。
但代价也很明显。M7 内核加了 Cache 之后，DMA 和 CPU 之间的数据一致性就成了一个绕不开的问题。你如果还是用 F4 那种“开个数组，往 DMA 里塞地址，完了直接读”的思路，在 H743 上很容易出现诡异的现象：串口 DMA 收到的数据在调试器里看是对的，一全速运行就乱，或者有时候对、有时候不对。这大概率就是 Cache 没处理。
另外，H743 的内存分布也比 F4 复杂。F4 的 SRAM 基本就是一块连续的区域，H743 把 RAM 分成了 AXI SRAM、SRAM1/2/3/4、ITCM、DTCM，有的域 CPU 能访问、DMA 访问不了，有的域 DMA 能访问但注意 Cache 策略不同。这些在基础例程里可能感受不明显，但到了摄像头项目，帧缓冲放哪个域、DMA 怎么搬运，全是这里的知识。
1.2 基础例程的定位：不是玩具，是一套系统级参考实现
很多初学者拿到例程包，习惯是：打开工程，编译下载，灯亮了，下一个。这样其实浪费了这套代码 80% 的价值。
我个人的建议是，把基础例程当成一份“针对当前板卡做过适配的系统级参考实现”来读。比如 GPIO 例程里除了简单的 HAL_GPIO_WritePin，其实能看到板卡 LED 接在哪个引脚、低电平点亮还是高电平点亮、GPIO 速度配置成了哪一档；串口例程里能学到 printf 重定向的方式、串口时钟来自哪条总线、波特率误差是否在合理范围。
这些细节刚看觉得琐碎，但你自己画板子、自己写驱动的时候就知道有多重要。我见过很多人移植例程到自绘板子，灯不亮就先怀疑代码，查了半天发现是引脚都改了，原理图没对应上。
1.3 硬件准备：买板子时最容易忽略的两个配件
准备学 H743 的话，开发板之外有两样东西我强烈建议一次买齐：一个带串口芯片的 USB 转 TTL 模块，和一个支持 SWD 接口的独立 ST-Link/V2 或 DAP 下载器。
开发板板载的 DAP-Link 一般够用，但很多时候你想在板上引线出来调试外部传感器，板载下载器就有点碍事了。独立下载器不仅下载快，关键是排查硬件问题时，可以单独用它测试目标板的 SWD 引脚是否正常。USB 转 TTL 模块则是排查串口问题的基础工具，H743 串口多，你后面接 GPS、接 ESP8266、接各种传感器，都会用到。
2. 跑通第一个例程之前，先把环境里的三个坑填平
2.1 IDE 与 Pack 版本：Keil MDK 搭配 STM32H7xx 器件包
环境这块我直接说结论：用 Keil MDK 的话，先把 Pack Installer 里的STM32H7xx 系列 DFP 器件包更新到较新版本，不要用 Keil 安装包自带的那个旧版本。H743 的 HAL 库更新比较频繁，早期版本在部分外设上确实有 bug，比如 FDCAN 的时钟配置、DCMI 的一些时序参数，新的 DFP 会修复这些问题。
安装完器件包后，建议在魔术棒选项卡里检查一下 "CMSIS" 版本。我之前遇到过一个问题：工程文件是从旧例程拷贝的，CMSIS 核心库版本比较老，编译不报错，但下载后进不了 main 函数，直接在 SystemInit 里面 HardFault。后来把 CMSIS 版本对齐到跟器件包一致才解决。
2.2 下载器连不上目标板的三个排查动作
ST-Link 连不上 H743 是新手遇到最多的一个问题，尤其是第一次接线的场景。我总结了一个排查顺序，基本覆盖了九成的情况：
- 按住开发板的复位键，然后点 Keil 的下载按钮，在松开的瞬间让下载器抢占芯片。H743 上电默认可能会从用户代码启动，如果用户代码里早期就初始化了 SWD 引脚或者进入了低功耗模式，就会出现“连接不上目标”的情况。按住复位再点下载，是绕过这个问题的经典方法。
- 检查 SWDIO、SWCLK、GND 三条线是否接对。很多人会漏 GND，单纯接 SWDIO 和 SWCLK 是连不上的，调试器和目标板必须共地。
- 把下载速度从默认的 4MHz/8MHz 降到 1MHz 甚至 100kHz。线材差、杜邦线过长、接触不良，都会导致高速 SWD 通信失败。降速之后能连上，那基本就是硬件连接问题，而不是芯片坏了。
2.3 工程里默认的 HSE 值必须和板子晶振一致
这个坑我放环境篇里说，因为它炸起来太隐蔽了。
H743 内部有个 64MHz 的 HSI，但默认很多例程用外部高速晶振 HSE 作为 PLL 的参考源。问题在于：不同开发板的 HSE 晶振值不一样，常见的有 8MHz、12MHz、25MHz。正点原子阿波罗 H743 板上用的是 25MHz 晶振，而有些第三方核心板用的是 8MHz。
如果你拿着 25MHz 的例程往 8MHz 的板子上烧，现象就是：串口打印乱码、时钟里系统主频完全不对、定时器时间漂移得离谱，甚至程序跑不起来。排查方法很简单，看板卡原理图的晶振位置标注，然后在stm32h7xx_hal_conf.h或者 CubeMX 的 Clock Configuration 里把 HSE_VALUE 宏改成对应值，重新生成时钟配置。
提示：如果是用 HSI 做时钟源的例程，就没有这个问题。但 HSI 精度不如外部晶振，做串口通信、USB、以太网对时钟精度要求高的项目时，还是建议优先 HSE。
3. 不要跳过时钟框图：H743 基础例程的真正入口
3.1 480MHz 是怎么来的：PLL1 与 VOS 档位
在 F103 上，很多人是“时钟配置代码复制粘贴，能用就行”。到了 H743 这里，这个习惯要改改了，因为 H743 的时钟树比 F1 复杂了一个数量级，不搞清楚，后面所有外设的波特率、频率都会莫名其妙不对。
H743 的 SYSCLK 最高 480MHz，这个频率不是直接用 HSE 倍频就能出来的，要经过一个复杂的 PLL1 链路。以 25MHz HSE 为例，通常先做 1 分频，再乘以 3，得到 75MHz 的中间频率，这个频率作为 PLL1 的输入；PLL1 内部再经过一个大的倍频系数（典型配置是 32），最终输出 480MHz。中间还有个关键的PLL1_VCO范围要求，频率不能超过上限。所以你在例程里看到的那种“一串看起来很随意”的 RCC 配置参数，其实是严格按照芯片手册约束算出来的。
另一个容易被忽视的点是：480MHz 不是喊一句“我要 480”就能稳跑的，必须先把电源调压器的 VOS 档位设到最高等级。F4 上有 VOS 的概念，但 H743 更严格——主频在 400MHz 以上时，VOS 必须设为 Scale 3/最高性能档，否则即使 PLL 配置正确，芯片也无法跑到指定频率，跑起来也会不稳定。基础例程里一般会在SystemClock_Config()里先调用HAL_PWREx_ControlVoltageScaling(PWR_REGULATOR_VOLTAGE_SCALE3)，这行代码别删。
3.2 H743 外设时钟与 F1 的最大区别：APB1/APB2 都能跑到 240MHz
F103 的 APB1 最高 36MHz，APB2 最高 72MHz，所以USART、I2C、SPI 这些外设挂在 APB1 还是 APB2 上，直接影响你能跑多快。很多 F1 转过来的同学，潜意识里觉得 APB1 就是“低速总线”，APB2 才是“高速总线”。
H743 不是这样。它的 APB1 和 APB2 最高都能到240MHz，而且定时器时钟最高可以到 480MHz。所以你在选外设挂载总线时，重点不再是“哪个总线快”，而是“这个外设的时钟源哪路更干净、哪路更符合它的工作频率需求”。
这个认知对调试串口尤其重要。串口挂在不同总线上，波特率计数器的输入时钟来源就不一样，配置不当会出现波特率误差。基础例程里串口初始化看似简单，实际huart1.Init里的每个参数背后都有这么一层逻辑。
3.3 一个经常出问题的定时器时钟倍数逻辑
定时器这部分我多说一句，因为它经常让初学者困惑。
H743 的定时器时钟是这样计算的：如果 APB 预分频系数是 1，那么定时器的输入时钟就等于 APB 时钟；如果 APB 预分频系数大于 1，那么定时器的输入时钟等于 APB 时钟的 2 倍。
F1 上也有这个逻辑，但因为 F1 的 APB 频率低，翻倍了也就是 72MHz，大家没太在意。H743 上 APB1 本身就 240MHz，再翻倍就成了 480MHz。你对定时器做预分频的时候，如果不知道输入时钟是 480MHz，算出来的定时时间就会差一倍。
基础例程里 PWM 的频率计算、输入捕获的时间戳换算，全部依赖这个基准。建议你拿到例程后，先在调试器里看一遍SystemClock_Config()里 AHB/APB 的实际分频值，再对照 Timer 的计数器频率算一遍，确认理解无误，后面写底部代码会轻松很多。
4. GPIO 点灯与串口 printf：例程里藏着的工程素养
4.1 GPIO 速度档位和输出电流：点个灯也有讲究
GPIO 例程大概是所有例程里最不起眼的，但我还是想提一个点：GPIO 输出速度档位的选择。
H743 的 GPIO 输出速度有低速、中速、高速、极高速四档，分别对应不同的压摆率。点 LED 用低速都可以，但如果复用成 SPI、SDIO、DCMI 这样的高速信号，速度档位就必须按外设需求来配。用低速档跑高速通信，波形上升沿不够陡，离得近还能用，线一长就会出现偶发通信失败，在逻辑分析仪上看得特别清楚。
另外提醒一下，H743 部分引脚可以作为“电源输出”给外部传感器供电，但 GPIO 的驱动能力是有限的。我之前在图传模块上犯了错，直接用 GPIO 推挽输出给 OV2640 的 AVDD 引脚供电，结果图像始终有波纹，后来改成板卡 LDO 供电，问题立刻消失。
4.2 printf 重定向的两种写法
串口例程里出镜率最高的就是 printf 重定向。H743 使用 HAL 库的情况下，我整理了两种常见的写法：
写法一：使用微库（MicroLIB），直接重写 fputc：
int fputc(int ch, FILE *f) { HAL_UART_Transmit(&huart1, (uint8_t *)&ch, 1, 0xFFFF); return ch; }这种写法的优点是代码量小，适合调试日志输出。但要注意，HAL_UART_Transmit 是阻塞发送，在中断回调里调用 printf 时，如果串口一直没发完，程序会卡在那里，可能影响实时性。
写法二：不用微库，重写_write函数（适合 GCC/ARMCC 环境）：
int _write(int file, char *ptr, int len) { HAL_UART_Transmit(&huart1, (uint8_t *)ptr, len, 0xFFFF); return len; }我个人的习惯是：调试阶段用阻塞式 printf，项目发布前把调试日志改成 DMA 发送或者直接关掉，避免 stdout 阻塞拖垮实时任务。基础例程里讲的是最简写法，但你要知道它的局限。
4.3 串口乱码的排查方向：先看晶振再看波特率误差
串口打印乱码，很多人第一反应是波特率设错了，其实在 H743 上还有一个更常见的源头：时钟配置和实际晶振不匹配。
我举一个实际场景：某块第三方板卡用的是 12MHz 晶振，但例程里 HSE_VALUE 写的 25MHz。系统时钟配置还是按 25MHz 去算 PLL，最终 SYSCLK 不是 480MHz，而是一个不伦不类的频率。此时串口波特率虽然配置成了 115200，但 USART 的输入时钟源是偏的，算出来的波特率分频系数对应的实际波特率就和 115200 差很多，打印出来就是乱码。
排查顺序我建议这样：
- 先检查 HSE_VALUE 是否和板卡晶振一致；
- 在调试器里读 RCC 相关寄存器，确认 PLL1 输出、AHB/APB 分频是否和配置一致；
- 用示波器或者逻辑分析仪看 TX 引脚的波形，测一下实际波特率；
- 排除以上因素后，再怀疑代码配置和串口助手设置。
5. 中断、定时器和 DMA：把基础例程串成实时系统的关键
5.1 NVIC 优先级分组：先约定好再写代码
H743 的 NVIC 优先级分组我建议在项目一开始就定好，不要在多个模块里各设各的。基础例程里外设初始化时都会涉及中断优先级设置，比如：
HAL_NVIC_SetPriority(USART1_IRQn, 2, 0); HAL_NVIC_EnableIRQ(USART1_IRQn);如果你在一个模块里用了抢占优先级 2、子优先级 0，另一个模块里用了抢占优先级 5、子优先级 2，而优先级分组又是 4 位抢占、0 位子优先级的模式，那第二个参数设置的就是全部优先级，代码逻辑跟你预想的可能完全不同。
我的习惯是：初始化函数最开头先设置一次优先级分组，比如全部用NVIC_PRIORITYGROUP_4（纯抢占优先级），后面所有中断只设抢占优先级，不设子优先级。这样思路清晰，排查也方便。尤其是在做摄像头项目时，DCMI 中断、DMA 中断、定时器中断混在一起，优先级关系不提前规划好，图像数据丢失都不知道是谁打断谁导致的。
5.2 定时器的多通道与 PWM 频率计算
定时器例程里，PWM 是一个绕不开的模块。频率计算公式是：
PWM 频率 = 定时器输入时钟 /（预分频值 + 1）/（自动重载值 + 1）
比如定时器输入时钟是 480MHz，预分频给 47，自动重载给 999，那么 PWM 频率就是：
480MHz / 48 / 1000 = 10kHz
这个计算逻辑在 F1、F4、H7 上是一样的，但 H743 的定时器输入基础频率更高，分频取值范围更大，能输出的 PWM 频率范围也更宽。做电机控制时，20kHz 左右的 PWM 是常见需求；做 LED 呼吸灯时，几百 Hz 就够了。基础例程里一般会用HAL_TIM_PWM_Start和__HAL_TIM_SET_COMPARE调节占空比，这两个函数认识就够了。
有一点我要提醒：H743 的高分辨率定时器（HRTIM）不是普通定时器，它和 TIM1/8 的用法差别很大。基础例程里通常不会涉及 HRTIM，但如果你看到例程包里有 HRTIM 相关例程，先别急着跑，它的初始化参数多且复杂，建议先吃透普通定时器再说。
5.3 H743 的 DMA/BDMA/MDMA：选错 DMA 是很多坑的源头
H743 的 DMA 体系是基础例程里最容易被低估的内容。它一共有三类 DMA：
- DMA1、DMA2：主要服务 D2 域的外设，比如 USART、SPI、I2C、DCMI、SDMMC 等；
- BDMA：服务 D3 域的外设，以及部分低功耗场景；
- MDMA：内存到内存的高速搬运，常用于大块数据转移和内存初始化。
很多 H743 新手在跑“串口 DMA 收发”例程时，以为和 F4 差不多，直接选 DMA1 通道 4 就用了。其实 H743 的 DMA 请求映射比 F4 灵活，但每个 DMA 控制器的通道有限，外设请求的映射关系也不同。选错了，最典型的现象就是 DMA 请求一直不触发，或者触发后数据搬错。
我踩过一次：串口 RX 配成 DMA1，外设请求也是按 CubeMX 自动生成的，但代码里手动初始化时改了 DMA 句柄的实例，结果 DMA 中断一直进不去，找了一晚上才发现是hdma_usart1_rx.Init.Request里映射错了通道。
注意：基础例程里直接用 CubeMX 生成的 DMA 配置是没问题的，但如果你脱离 CubeMX 手写底层，一定要对照参考手册的 DMA 请求映射表逐项核对。
5.4 缓存一致性：DMA 配合 Cache 时的必做动作
这部分是 H743 区别于 F4 的核心知识点，也是基础例程不会明说的隐藏考点。
H743 的 D-Cache 默认是开启的（有些例程会关掉，但我建议开启，性能差距明显）。问题来了：DMA 是直接访问内存的外设，它不经过 Cache。如果 CPU 往一个数组里写了数据，然后让 DMA 把这个数组的内容发出去，此时数据可能还在 Cache 里没刷到内存，DMA 就会把内存里的旧数据发出去，表现为“串口发送的内容不对”。
反过来，DMA 从外设收数据到内存，CPU 读取时可能从 Cache 里读到旧数据，表现为“收到的数据一直是上一次的值”。
解决方法是 DMA 传输前后对缓冲区域做 Cache 清理/无效化：
SCB_CleanDCache_by_Addr((uint32_t *)buffer, size); // DMA 发送前，把 Cache 里新数据刷到内存 SCB_InvalidateDCache_by_Addr((uint32_t *)buffer, size); // DMA 接收后，让 CPU 重新从内存读取基础例程里如果外设和 DMA 配合不多，可能注意不到这个问题。但你一旦开始做 DCMI 摄像头采集、ADC 多通道 DMA 采样、以太网收发，这一步就是每天都会遇到的日常操作了。
6. 从基础例程走到 OV2640 摄像头项目：一条可行的路线
6.1 OV2640 和 H743 的接口关系
搜索热词里有“stm32h743 ov2640”，我猜不少人是冲着摄像头来的。OV2640 是一款 200 万像素的 CMOS 摄像头传感器，输出接口是 DVP（数字并口），数据线 D0-D7，加上 PCLK、HREF、VSYNC，以及一根 SCCB（兼容 I2C）配置总线。
H743 这边对应的外设是DCMI（数字摄像头接口）。DCMI 可以接收 8/10/12/14 位的并行数据，配合 DMA 可以连续采集图像帧，非常适合 OV2640 这种 DVP 接口的传感器。
这里有个概念要理清：OV2640 输出的数据格式可以是 JPEG 压缩后的数据流，也可以是 RGB565/YUV 这样的原始像素格式。JPEG 格式数据量小，但对 MCU 而言解码有额外负担；RGB565 格式数据量大，但可以直接用于显示和简单图像处理。基础例程一般不会直接给 OV2640 的完整驱动，它往往只给到 DCMI、I2C/SCCB、DMA 这些底层外设的例程，你需要自己组合。
6.2 推荐的项目组合：DCMI + DMA + 外部 SDRAM
OV2640 的 320x240 RGB565 一帧大小约 150KB，H743 内部 1MB RAM 完全能放得下；但如果你要做 640x480，一帧就是 600KB，内部 RAM 还剩多少、够不够跑其他逻辑，就要认真计算了。
我的建议是，从 320x240 起步，用内部 RAM 先跑通全流程，再考虑要不要外扩 SDRAM。H743 的 FMC 接口支持 SDRAM，扩展 8MB/16MB 不是难事，但 SDRAM 的时序调试复杂度会上一个台阶，不建议一上来就碰。
DCMI 这边有几件事需要提前做好思想准备：
- SCCB 配置 OV2640 的寄存器非常繁琐，涉及分辨率、输出格式、时钟分频、曝光增益等上百个寄存器。建议先找一个可用的寄存器配置数组，先跑通，再逐项调优。
- DCMI 的时序要求比较严格，VSYNC 和 HREF 的电平极性必须和 OV2640 的实际输出匹配，配置反了会采集不到有效帧。
- DMA 必须双缓冲，一个缓冲在做 DMA 接收时，另一个缓冲供 CPU 做处理和显示，否则帧率上不去，还会出现撕裂感。
6.3 我的建议顺序：先调通 SCCB，再点亮屏幕，最后才碰 DCMI
这条路我帮你规划一下，避免你一头扎进 DCMI 代码里出不来的情况：
第一步：先确认 SCCB（I2C）能读写 OV2640 的寄存器。OV2640 的 SCCB 地址一般是 0x60（写）/0x61（读），用逻辑分析仪抓波形，能读到芯片 ID 寄存器（PID/HID）返回正确的值，比如读回 0x26 0x02 之类的器件号，说明硬件通路没问题。
第二步：把 LCD 或者串口调通，作为图像显示和调试输出的通道。图像最终要让人看到，串口可以打印帧率、分辨率、调试信息，LCD 可以直接显示采集到的画面。
第三步：最后才配置 DCMI 和 DMA。先用最小时钟分频、低分辨率跑通第一帧图像，确认画面方向、颜色格式、帧率，再逐步优化。
这个顺序的好处是：每一步都有明确的可验证节点，出问题时能把范围快速定位到“配置问题”还是“硬件问题”，而不是在一个大杂烩工程里盲目改参数。
7. 我在实测中踩过的几个坑（附排查过程）
7.1 现象：所有例程都能编译，但一上电就死在 HardFault_Handler
某次我把一个 F4 上的低功耗例程移植到 H743 上，下载完程序一复位，直接进 HardFault。第一反应是数组越界，检查一圈没发现。
后来单步调试发现，程序死在SystemClock_Config()里的HAL_RCC_ClockConfig()调用上。排查确认是电源配置的问题——H743 的 VOS 档位没设，PLL1 输出 480MHz 时电压等级撑不住，导致时钟切换失败。
这个坑的教训是：H743 上先调电源、再调时钟，这个顺序千万别颠倒。基础例程里的 SystemClock_Config 是有标准套路的，不要自己随便删减。
7.2 现象：调试模式下正常，拔掉下载器后跑飞
这个现象我遇到的时候也懵了一阵。调试模式下单步、全速都正常，拔掉 ST-Link，重新上电，程序跑飞或者完全没反应。
最后查到原因：程序里用了HAL_Delay()，而它的时基默认依赖 SysTick。调试器在线时，Keil 会接管中断，问题被掩盖了；离线后 SysTick 中断没有正常触发，HAL_Delay()永远等不到时间到，程序卡死。
这类问题的排查思路：先看时基中断是否正常，HAL_GetTick()是否在持续增长。如果HAL_Delay卡住，优先检查 SysTick/定时器时基的初始化，尤其是你在调试模式下改过中断优先级或者屏蔽过中断。
7.3 现象：DMA 搬运串口数据偶尔丢一两个字节
串口 DMA 收发在 F4 上很成熟，在 H743 上我一开始也照着写，结果测试大批量数据时，每传几千字节总会丢几个。
查了很久，最后定位到 Cache 一致性。当时串口 DMA 接收缓冲用的是一块内部 SRAM，CPU 读数据时未做 Cache Invalidate，导致偶尔读到旧数据。严格说这不叫“丢”，而是“读错”。加了SCB_InvalidateDCache_by_Addr之后问题彻底消失。
这个坑想跟你说的是：如果你从 F4 切到 H743，DMA 相关的问题第一优先排查 Cache，第二才是中断、优先级、DMA 配置。
7.4 排查思路总结
H743 这类高性能 MCU，问题往往不是单点原因，而是多个因素叠加。我的习惯是：
- 先确认电源配置（VOS 档位、VCAP 引脚是否按要求接电容）；
- 再确认时钟配置（HSE 值、PLL1、AHB/APB 分频）；
- 然后排查 Cache 策略和 DMA 是否冲突；
- 最后才怀疑具体外设的寄存器配置。
沿着这个顺序，大部分问题都能在一个小时内定位。
这套基础例程跑下来，个人最大的体会是：H743 给了你充足的性能，但也要求你把底层原理吃得更透。建议手上的例程工程别删，后面做项目时反复对照查看，特别是 CubeMX 自动生成的时钟树和 DMA 映射关系，多看几次，绝对没坏处。如果你也在跑 H743 或者踩了类似的坑，欢迎多交流。
本文还有配套的精品资源，点击获取
