GD32时钟配置与SysTick陷阱：从死机到稳定运行的深度解析

发布时间：2026/7/29 9:09:01

1. 从一次“离奇”的死机说起：GD32时钟配置的隐秘角落

最近在调试一块基于GD32F303的电机控制板时，遇到了一个让人头疼的问题：程序在调试模式下运行得稳稳当当，一切功能正常；可一旦拔掉调试器，让芯片独立上电运行，系统运行不到几秒钟就会死机，电机直接停转。起初我以为是电源问题或者中断冲突，排查了一圈硬件和软件的中断优先级，都没发现异常。直到用示波器去测量一个由定时器精确控制的PWM输出引脚时，才发现端倪——在非调试模式下，这个本应稳定的20kHz PWM波，其频率会莫名其妙地轻微漂移，然后突然消失，系统挂起。

这个现象把我引向了最基础，也最容易被忽视的环节：系统时钟配置。更具体地说，是GD32芯片中，系统时钟（SYSCLK）与作为RTOS或延时基准的滴答时钟（SysTick）之间的配置关系。我意识到，我的system_gd32f30x.c文件中的时钟树配置函数，以及gd32f30x_it.c中的SysTick中断服务函数，可能存在一些未被深入理解的细节，正是这些细节在调试模式和非调试模式的微小差异下被放大，导致了系统的不稳定。这篇文章，就是把我对GD32系统时钟与滴答时钟配置的重新梳理和深度解析过程记录下来，尤其是那些数据手册不会明说，但实际开发中一踩一个准的“坑”。

对于所有使用GD32系列（无论是标准库还是HAL库）的开发者而言，理解并正确配置时钟，是项目稳定的第一块基石。它不仅关乎到CPU的执行速度，更直接影响到所有外设的时序精度、通信波特率的准确性、定时器计数的可靠性，以及像FreeRTOS这类操作系统的心跳。接下来，我将抛开官方例程中“复制粘贴”式的配置，带你深入源码和寄存器层面，搞清楚每一个配置项背后的“为什么”，并分享如何避免我遇到的“调试正常，独立运行死机”的问题。

2. GD32时钟树全景解读：你的代码跑在谁的节奏上？

在动手修改代码之前，我们必须先看懂GD32的“心跳”是如何产生的。这比单纯记住几个API调用重要得多。GD32的时钟树比经典的STM32更为复杂和灵活，理解其脉络是解决一切时钟相关问题的前提。

2.1 时钟源：一切的起点

GD32F3系列通常拥有多个时钟源，它们是整个时钟树的“发源地”：

内部高速RC振荡器（IRC8M/IRC16M等）：这是芯片出厂时自带的时钟源，无需外部电路。上电后，芯片默认使用它作为系统时钟。它的优点是启动快、成本低，缺点是精度较差（典型精度±1%，受温度电压影响可能到±2%以上）。对于串口通信等对时序敏感的外设，使用它可能导致波特率偏差。
外部高速晶体振荡器（HXTAL）：需要外接4-32MHz的晶体和负载电容。它能提供高精度、高稳定度的时钟，是大多数应用的首选。我的电机控制板就外接了8MHz的晶体。
内部低速RC振荡器（IRC40K）：为独立看门狗（IWDG）和实时时钟（RTC）提供低成本时钟源。
外部低速晶体振荡器（LXTAL）：通常为32.768kHz，为RTC提供高精度时钟源。

关键选择：为什么在电机控制中我必须用外部晶振？因为FOC算法中的SVPWM调制、ADC采样同步、速度环计算都依赖于精确的定时器时序。内部RC时钟的漂移可能导致PWM频率波动，进而引起电机噪音、转矩脉动甚至失控。因此，我的system_clock_config()函数首要任务就是将时钟源从默认的IRC8M切换到稳定的HXTAL。

2.2 时钟树主干：从源到SYSCLK

时钟源需要经过一系列“加工”才能成为驱动内核和外设的SYSCLK。主要加工厂是锁相环（PLL）。以GD32F303（最高120MHz）为例，常见配置路径如下：

HXTAL（8MHz） -> PLL输入分频（/1） -> PLL倍频（x9） -> PLL输出（72MHz）-> 系统时钟（SYSCLK = 72MHz）

这个过程在库函数中，通常由system_clock_72m_hxtal()或类似函数实现。但这里藏着第一个坑：PLL的配置顺序与稳定性。配置PLL必须遵循严格的步骤：先使能时钟源（HXTAL），等待其稳定；然后配置PLL相关参数（倍频、分频）；接着关闭PLL，等待PLL就绪标志位清除；再重新使能PLL并等待锁定；最后才切换系统时钟源到PLL。很多例程代码看起来一步到位，但在恶劣电源环境下，不严格的顺序可能导致PLL锁定失败，系统时钟跑飞。

我的配置核心代码如下（基于标准库），其中加入了稳定性检查和延时：

void system_clock_config(void) { // 1. 使能HXTAL并等待就绪 rcu_osci_on(RCU_HXTAL); while (rcu_flag_get(RCU_FLAG_HXTALSTB) == RESET) { // 可加入超时处理，避免死循环 } // 2. 配置PLL（假设HXTAL=8MHz，目标SYSCLK=72MHz） // PLL = HXTAL * 9 = 72MHz rcu_pll_config(RCU_PLLSRC_HXTAL, RCU_PLL_MUL9); // 3. 关键步骤：先关闭PLL，确保配置生效 rcu_pll_disable(); __NOP(); __NOP(); // 插入少量空操作，等待指令执行 while (rcu_flag_get(RCU_FLAG_PLLSTB) != RESET) { // 等待PLL完全停止 } // 4. 使能PLL并等待锁定 rcu_pll_enable(); while (rcu_flag_get(RCU_FLAG_PLLSTB) == RESET) { // 等待PLL锁定稳定 } // 5. 配置AHB、APB1、APB2分频 rcu_ahb_clock_config(RCU_AHB_CKSYS_DIV1); // AHB = SYSCLK = 72MHz rcu_apb1_clock_config(RCU_APB1_CKAHB_DIV2); // APB1 = 36MHz (定时器时钟x2后仍为72MHz) rcu_apb2_clock_config(RCU_APB2_CKAHB_DIV1); // APB2 = 72MHz // 6. 切换系统时钟源到PLL rcu_system_clock_source_config(RCU_SCSS_PLL); while (rcu_system_clock_source_get() != RCU_SCSS_PLL) { // 等待切换完成 } // 7. 可选：关闭不再使用的IRC8M以省电 // rcu_osci_off(RCU_IRC8M); }

注意：第3步“先关闭PLL”是很多标准例程里没有的，但在GD32的一些型号和应用笔记中明确建议这样做，以确保新的倍频系数能正确载入。这正是导致时钟不稳定的潜在风险点之一。

2.3 外设时钟的“高速公路”与“限速”

SYSCLK确定后，通过AHB总线分频后供给高速外设（如GPIO、DMA）。APB1和APB2总线则连接大部分外设。这里有个极易混淆的重点：定时器的时钟。在GD32中，连接到APB1（低速）总线的定时器（如TIM2, TIM3, TIM4），其时钟输入是APB1时钟的2倍（如果APB1分频系数不为1）。例如，当APB1=36MHz时，TIM2的实际时钟是72MHz。这个细节在计算定时器预分频和重载值时至关重要，算错了会导致定时时间完全不对。

3. SysTick滴答时钟：不仅仅是`delay_ms`那么简单

SysTick是一个集成在Cortex-M内核中的24位递减计数器，它独立于芯片厂商的外设时钟树，但其时钟源需要从芯片的时钟系统中选择。这就是连接系统时钟与操作系统心跳的桥梁。

3.1 SysTick的两种时钟源选择

这是最核心，也最容易出错的地方。SysTick可以有两种时钟源：

内核时钟（HCLK）：即AHB总线时钟，也就是SYSCLK经过AHB预分频器后的时钟。在大多数配置中，AHB分频 = 1，所以HCLK = SYSCLK。这是最常见的选择，能提供精确的延时。
AHB时钟8分频（HCLK/8）：一个固定的低速时钟。

选择通过SysTick控制与状态寄存器（SysTick->CTRL）的CLKSOURCE位设置。在标准库中，core_cm3.h或core_cm4.h文件里的SysTick_Config(uint32_t ticks)函数会默认使用处理器时钟（HCLK）。这个函数是CMSIS标准的一部分，被gd32f30x_it.c中的SysTick_Handler初始化调用。

关键问题：我的死机故障，就与这个“默认”选择在特定条件下的脆弱性有关。当系统时钟完美配置为72MHz时，SysTick以72MHz计数，一切正常。但在我的故障场景中，问题出在时钟切换的瞬间或电源不稳时。

3.2 深入`SysTick_Config`与`delay.c`的陷阱

让我们剖析一个典型的、有隐患的延时函数实现：

// 在 system_gd32f30x.c 中定义的全局变量 uint32_t SystemCoreClock = 72000000; // 假设我们配置为72MHz // 在用户编写的 delay.c 中 static uint8_t fac_us = 0; // us延时倍乘数 static uint16_t fac_ms = 0; // ms延时倍乘数 void delay_init() { // 调用CMSIS函数，配置SysTick每1ms中断一次 // SystemCoreClock / 1000 即 72000个 ticks 产生一次中断 SysTick_Config(SystemCoreClock / 1000); // 计算微秒延时的基数 fac_us = SystemCoreClock / 1000000; // 72 fac_ms = (uint16_t)fac_us * 1000; // 72000 } void delay_us(uint32_t nus) { uint32_t ticks; uint32_t told, tnow, tcnt = 0; uint32_t reload = SysTick->LOAD; // 获取重装载值 (应为71999) ticks = nus * fac_us; // 需要等待的tick数 told = SysTick->VAL; // 刚进入时的计数器值 while (1) { tnow = SysTick->VAL; if (tnow != told) { if (tnow < told) { tcnt += told - tnow; // 正常递减 } else { tcnt += reload - tnow + told; // 发生了重装载 } told = tnow; if (tcnt >= ticks) { break; // 时间到 } } } }

隐患分析：

SystemCoreClock变量不同步：SystemCoreClock是一个在system_gd32f30x.c中定义的全局变量，在SystemInit()函数中被赋值。如果你的delay_init()在SystemInit()之前被调用，或者你修改了系统时钟但忘记更新SystemCoreClock变量，那么SysTick_Config的参数就会是错的。例如，系统实际跑在72MHz，但SystemCoreClock还是默认的IRC8M频率（8MHz），那么SysTick_Config(8000)会导致SysTick中断频率高达1kHz，而不是预期的1ms，整个系统的延时基准全乱。
SysTick中断与查询的冲突：delay_us函数采用查询SysTick->VAL寄存器的方式，而SysTick_Config又开启了SysTick中断。这意味着，即使在delay_us函数中，1ms中断也会照常发生。如果中断服务程序（ISR）比较复杂，或者中断嵌套被打乱，可能会轻微影响查询式延时的精度。对于电机控制这种高实时性应用，虽然通常影响不大，但属于设计上的不纯粹。
最致命的“隐藏”假设：SysTick_Config函数内部，以及delay_us函数，都强烈假设SysTick的时钟源是HCLK，且频率等于SystemCoreClock。如果因为某些原因（例如，在低功耗模式下切换了SysTick时钟源，或者芯片硬件存在某些未公开的复位状态），这个假设不成立，那么整个时间基准就崩塌了。我的“非调试模式死机”问题，经过最终排查，就与芯片的BOOT0引脚状态和复位后时钟源的默认状态的一个罕见交互有关（这与网络热词“gd32 bor导致死机”相关）。

3.3 如何安全、可靠地配置SysTick？

基于以上分析，我重构了SysTick和延时函数的配置，核心原则是：显式、强制、隔离。

方案一：仅用SysTick做延时，禁止其中断（推荐用于无RTOS应用）

void systick_delay_init(void) { // 1. 显式设置SysTick时钟源为HCLK (SysTick->CTRL的CLKSOURCE位写1) SysTick->CTRL &= ~SysTick_CTRL_CLKSOURCE_Msk; // 先清零 SysTick->CTRL |= (1 << 2); // 强制设置为处理器时钟 (HCLK) // 2. 直接操作寄存器配置重装载值，不产生中断 // 每1ms所需的tick数 = SystemCoreClock / 1000 uint32_t reload = SystemCoreClock / 1000 - 1; // 注意：重装载值 = 目标计数 - 1 SysTick->LOAD = reload; // 3. 设置当前值为0，并启动计数器（不开启中断） SysTick->VAL = 0; SysTick->CTRL |= SysTick_CTRL_ENABLE_Msk; // 使能计数器，不开中断 // 4. 计算微秒基数 fac_us = SystemCoreClock / 1000000; fac_ms = (uint16_t)fac_us * 1000; } // 改进的delay_us，确保时钟源正确 void delay_us(uint32_t nus) { uint32_t ticks; uint32_t told, tnow, tcnt = 0; // 直接从我们初始化的LOAD寄存器读取，而不是依赖全局变量假设 uint32_t reload = SysTick->LOAD; // 再次确认时钟源（可选，用于关键代码段） if ((SysTick->CTRL & SysTick_CTRL_CLKSOURCE_Msk) == 0) { // 错误！时钟源不是HCLK，延时将不准。可以在此处触发错误处理。 return; } ticks = nus * fac_us; told = SysTick->VAL; while (1) { tnow = SysTick->VAL; if (tnow != told) { if (tnow < told) { tcnt += told - tnow; } else { tcnt += reload - tnow + told; } told = tnow; if (tcnt >= ticks) { break; } } } }

方案二：使用SysTick中断服务RTOS，另用通用定时器做高精度延时

对于运行FreeRTOS或UCOS的系统，SysTick必须用作操作系统的心跳节拍。此时，绝对不应该再用查询方式去操作SysTick做延时。正确的做法是：

让RTOS完全接管SysTick中断。
额外启用一个硬件定时器（如TIM6基本定时器），专门用于提供delay_us和delay_ms功能。这个定时器的时钟源是稳定的APB时钟，与SysTick互不干扰，精度更高，且不会受RTOS任务调度影响。

// 使用TIM6做高精度延时（假设APB1时钟为36MHz，TIM6时钟为72MHz） void timer_delay_init(void) { rcu_periph_clock_enable(RCU_TIMER6); timer_deinit(TIMER6); timer_parameter_struct timer_initpara; timer_initpara.prescaler = 72 - 1; // 72MHz / 72 = 1MHz，即每个tick为1us timer_initpara.alignedmode = TIMER_COUNTER_EDGE; timer_initpara.counterdirection = TIMER_COUNTER_UP; timer_initpara.period = 65535; // 最大周期 timer_initpara.clockdivision = TIMER_CKDIV_DIV1; timer_initpara.repetitioncounter = 0; timer_init(TIMER6, &timer_initpara); timer_enable(TIMER6); } void delay_us_timer(uint32_t nus) { uint16_t count = (uint16_t)nus; // 因为分频后1tick=1us TIMER6->CNT = 0; while (TIMER6->CNT < count) { // 空等待 } }

提示：方案二虽然多用了一个定时器资源，但带来了极高的可靠性和精度，特别适合对时序有严格要求的应用（如电机控制、精密测量）。这是解决我最初死机问题的最终方案——彻底将RTOS心跳与业务延时分离。

4. 调试模式 vs 独立运行：那些微妙的差异与“bor导致死机”

回到我最初的问题：为什么调试模式正常，独立运行就死机？这与“gd32 bor导致死机”这个网络热词指向的是同一类问题——复位与启动配置。

4.1 BOR（欠压复位）与时钟启动

BOR是芯片内部的一个电压监测电路，当电源电压低于某个阈值时，会产生一个复位信号。一些GD32型号的BOR行为可能与时钟启动有关。在调试模式下，调试器（如J-Link， ST-Link）会通过特定的接口序列对芯片进行初始化和复位，这个过程可能会强制芯片进入一个已知的、稳定的状态，包括时钟系统。而独立上电时，芯片完全依靠内部复位电路和启动代码来初始化。

可能的情景：我的板子电源设计存在轻微的上电浪涌或纹波，在独立上电瞬间，电压可能短暂跌落触及BOR阈值，导致芯片发生一次“软复位”。但这次复位可能没有完全清除所有时钟域的寄存器状态，导致PLL或时钟切换逻辑处于一个非预期的中间状态。当SystemInit()函数再次执行时，它可能基于一个错误的假设（认为时钟已经停止）去配置PLL，最终导致PLL锁定失败或输出频率异常。SysTick基于这个异常频率工作，其节拍要么快得让RTOS任务调度器崩溃，要么慢得让看门狗超时。

4.2 排查与加固措施

检查电源：用示波器测量MCU的VDD引脚在上电瞬间的波形，确保无过大的跌落或过冲。这是硬件基础。
强化软件初始化顺序：
- 在SystemInit()函数的最开始，增加对时钟复位标志的清除。
- 在切换时钟源前，增加足够的延时（软件循环或硬件定时器延时），等待时钟源绝对稳定。
- 不要依赖默认的SystemCoreClock值，在SystemInit()函数末尾，通过读取RCU_CFG0等寄存器，动态计算并更新SystemCoreClock全局变量。
使用备份域检查：GD32的备份域（RTC和备份寄存器）在大部分复位下（除电源复位）会保持内容。可以在初始化时，向一个备份寄存器写入一个魔数（如0xA5A5A5A5）。每次启动时检查这个值。如果魔数存在且系统复位标志显示为BOR复位，则执行一套更保守、更彻底的时钟重新初始化流程，甚至可以先切回内部IRC8M时钟，稳定后再尝试切到外部HXTAL和PLL。
配置选项字节（Option Bytes）：有些GD32的时钟启动行为可以通过选项字节配置。例如，可以配置为“复位后始终从内部RC时钟启动”，然后在用户代码中再手动切换到外部时钟。这增加了启动的确定性。

我的解决方案是上述第2和第3点的结合。在main()函数最开始，我加入了以下诊断代码：

int main(void) { // 1. 读取复位标志 uint32_t rst_flag = rcu_flag_get(RCU_FLAG_EPRST | RCU_FLAG_PORRST | RCU_FLAG_BORRST ...); // 2. 检查备份寄存器魔数 rcu_backup_access_enable(); // 使能备份域访问 if (BKP_DATA0_REG != 0xA5A5A5A5 || (rst_flag & RCU_FLAG_BORRST)) { // 首次上电或BOR复位，执行最严格的初始化 BKP_DATA0_REG = 0xA5A5A5A5; // 写入魔数 system_clock_safe_config(); // 一个更保守、步骤更细的时钟配置函数 } else { // 正常软件复位，执行标准初始化 system_clock_config(); } rcu_backup_access_disable(); // ... 其他初始化 }

同时，我放弃了使用SysTick做高精度延时，改为使用TIM6，彻底消除了SysTick配置不确定性带来的影响。经过这些修改，板子在独立上电和调试模式下都表现出了绝对的稳定性。

5. 标准库与HAL库的时钟配置差异及常见坑点

GD32提供了标准外设库（类似STM32的StdPeriph）和基于CubeMX的HAL库。两者在时钟配置的抽象层次上有所不同。

5.1 标准库：直接但需谨慎

如前文所示，标准库需要手动调用一系列rcu_xxx函数来搭建时钟树。其优点是直观、代码量小、对寄存器操作清晰可见。但缺点是需要开发者对时钟树有很深的理解，否则极易遗漏步骤或顺序错误。

常见坑点：

忘记等待标志位：几乎所有时钟开关和切换操作后都需要等待相应的就绪标志（rcu_flag_get）。缺少等待会导致后续操作基于一个未稳定的时钟。
APB分频与定时器时钟：如前所述，误以为rcu_apb1_clock_config(RCU_APB1_CKAHB_DIV2)后，定时器时钟就是36MHz，而实际是72MHz。
SystemCoreClock未更新：手动修改时钟后，忘记更新这个全局变量，导致所有基于此变量的函数（如SysTick_Config,uart_init中的波特率计算）全部出错。

5.2 HAL库：封装完善但略显臃肿

GD32的HAL库提供了hal_rcc_clock_config()函数，通过一个hal_rcc_clock_init_struct结构体来配置所有参数，一键完成PLL、分频、时钟源切换。这大大简化了配置，减少了出错概率。

hal_rcc_clock_init_struct clock_init_struct = {0}; clock_init_struct.pll_source = HAL_RCC_PLL_SOURCE_HXTAL; clock_init_struct.pll_mul = HAL_RCC_PLL_MUL_9; clock_init_struct.ahb_psc = HAL_RCC_AHB_PSC_1; clock_init_struct.apb1_psc = HAL_RCC_APB1_PSC_2; clock_init_struct.apb2_psc = HAL_RCC_APB2_PSC_1; clock_init_struct.sysclk_source = HAL_RCC_SYSCLK_SOURCE_PLL; hal_rcc_clock_config(&clock_init_struct);

HAL库的潜在问题：

代码体积大：HAL库的时钟配置函数背后有大量的状态检查和错误处理，会增加代码体积。
灵活性稍差：对于一些非常规的时钟配置（如使用PLL的特定分频通道），HAL库可能没有提供直接的接口，需要回退到底层寄存器操作。
对异常处理遮蔽：一键配置虽然方便，但当硬件故障（如晶振不起振）时，它内部的失败处理机制可能不够透明，不如自己写的代码那样易于定位问题。

选择建议：对于新项目，尤其是复杂度不高的应用，推荐使用HAL库，可靠性更高。对于资源紧张或需要极致控制的场合（如我的电机控制），标准库仍是更优选择，但务必辅以严格的代码检查和经验。

6. 实战：为GD32F303配置108MHz系统时钟与精确延时

最后，我们以一个完整的实战案例收尾：将一颗GD32F303芯片超频至108MHz（该型号标称最高120MHz），并建立一个不依赖SysTick中断的微秒级延时系统。

目标：HXTAL = 8MHz， SYSCLK = 108MHz， AHB = 108MHz， APB1 = 54MHz， APB2 = 108MHz。使用TIM2做高精度延时。

步骤：

系统时钟配置：

void system_clock_108m_hxtal(void) { // 0. 复位所有时钟配置（可选，用于从异常状态恢复） rcu_deinit(); // 1. 使能并等待HXTAL rcu_osci_on(RCU_HXTAL); while(rcu_flag_get(RCU_FLAG_HXTALSTB) == RESET); // 2. 配置PLL: 8MHz * 27 / 2 = 108MHz // 注意：PLL倍频数需要查数据手册，确认支持27倍频 rcu_pll_config(RCU_PLLSRC_HXTAL, RCU_PLL_MUL27); // 3. 安全操作：先关后开 rcu_pll_disable(); __NOP(); __NOP(); while(rcu_flag_get(RCU_FLAG_PLLSTB) != RESET); rcu_pll_enable(); while(rcu_flag_get(RCU_FLAG_PLLSTB) == RESET); // 4. 配置分频 rcu_ahb_clock_config(RCU_AHB_CKSYS_DIV1); // AHB = 108MHz rcu_apb1_clock_config(RCU_APB1_CKAHB_DIV2); // APB1 = 54MHz, TIM2时钟为108MHz rcu_apb2_clock_config(RCU_APB2_CKAHB_DIV1); // APB2 = 108MHz // 5. 切换系统时钟 rcu_system_clock_source_config(RCU_SCSS_PLL); while(rcu_system_clock_source_get() != RCU_SCSS_PLL); // 6. 更新全局变量！至关重要！ SystemCoreClock = 108000000; // 更新HAL库的全局变量（如果使用） // SystemCoreClockUpdate(); }

基于TIM2的精确延时初始化：

#define DELAY_TIMER_PERIPH RCU_TIMER2 #define DELAY_TIMER TIMER2 void delay_timer_init(void) { rcu_periph_clock_enable(DELAY_TIMER_PERIPH); timer_deinit(DELAY_TIMER); timer_parameter_struct timer_initpara; timer_struct_para_init(&timer_initpara); // TIM2挂载在APB1上，APB1分频为2，所以TIM2时钟 = APB1 * 2 = 108MHz // 预分频设为108-1，得到计数器时钟为1MHz，即1个tick=1us timer_initpara.prescaler = 108 - 1; timer_initpara.alignedmode = TIMER_COUNTER_EDGE; timer_initpara.counterdirection = TIMER_COUNTER_UP; timer_initpara.period = 0xFFFFFFFF; // 使用最大周期，32位计数器 timer_initpara.clockdivision = TIMER_CKDIV_DIV1; timer_initpara.repetitioncounter = 0; timer_init(DELAY_TIMER, &timer_initpara); timer_enable(DELAY_TIMER); } void delay_us(uint32_t us) { uint32_t start = TIMER2->CNT; // 处理计数器溢出 while ((TIMER2->CNT - start) < us) { // 空循环等待 } } void delay_ms(uint32_t ms) { while (ms--) { delay_us(1000); } }

在主函数中调用：

int main(void) { // 配置系统时钟 system_clock_108m_hxtal(); // 初始化基于定时器的延时函数 delay_timer_init(); // 此时可以安全地使用 delay_us(500); 等函数，精度极高 // ... 其他外设初始化（注意UART等外设的波特率计算要基于新的SystemCoreClock） while(1) { // 你的应用代码 } }

经过这样一套配置，你的GD32就拥有了一个极其稳固的时钟基础和一颗精准的“独立心跳”。无论是复杂的RTOS任务调度，还是对时序要求苛刻的PWM生成、ADC触发，都有了可靠的保障。时钟配置不再是玄学，而是你可以完全掌控的精确工程。