正点原子 STM32MP257 修复异核 FreeRTOS 例程 osDelay() 函数比 HAL_Delay() 延时快的问题

在 STM32MP257 异核 FreeRTOS 例程中，如果发现 osDelay() 的实际延时时间明显比 HAL_Delay() 短，通常不是 FreeRTOS 延时函数本身异常，而是 RTOS Tick 使用的系统时钟频率没有更新导致的。

一、问题现象

在 FreeRTOS 例程中测试延时函数时，可能会发现：

c 复制代码

osDelay(1000);

实际延时不到 1 秒，而：

c 复制代码

HAL_Delay(1000);

延时表现正常。

这说明两个延时函数使用的 Tick 来源不一致。

osDelay() 使用的是 RTOS Tick，通常依赖 SystemCoreClock 来配置 SysTick 或 RTOS 节拍。

出厂例程中，默认的 HSI 时钟值为 64MHz：

c 复制代码

#define HSI_VALUE ((uint32_t)64000000U)

如果 SystemCoreClock 没有更新，它仍然可能保持为默认的 64MHz。

但实际 M 核运行频率是 400MHz。这样 FreeRTOS 在初始化 Tick 时，会按照 64MHz 去计算重装载值，而硬件实际按 400MHz 在跑，最终就会导致 RTOS Tick 变快，osDelay() 延时自然也会变短。

而 HAL_Delay() 使用的是 TIM6 Tick：

c 复制代码

void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)
{
  if (htim->Instance == TIM6) {
    HAL_IncTick();
  }
}

TIM6 的时钟配置与实际内核时钟匹配，所以 HAL_Delay() 延时是正常的。

在 FreeRTOS 例程的 main.c 文件中，找到 osKernelInitialize() 函数，在它前面添加：

c 复制代码

SystemCoreClockUpdate();

修改示例：

c 复制代码

/* 更新 SystemCoreClock，确保 RTOS Tick 使用正确的 M 核运行频率 */
SystemCoreClockUpdate();

/* Init scheduler */
osKernelInitialize();

SystemCoreClockUpdate() 会自动从 RCC 寄存器中读取当前 M 核实际运行频率，并更新 SystemCoreClock 变量。

修复后，可以打印或调试查看：

c 复制代码

printf("SystemCoreClock = %lu\r\n", SystemCoreClock);

正常情况下，读取到的 SystemCoreClock 应为：

c 复制代码

400000000

也就是 400MHz，与 M 核实际运行频率一致。

此时 osDelay() 和 HAL_Delay() 的延时表现就会恢复一致。

这个问题的本质是：

FreeRTOS Tick 初始化时使用了错误的 SystemCoreClock，导致 osDelay() 延时基准不准确。

解决方法很简单：

在 osKernelInitialize() 前调用 SystemCoreClockUpdate()，让 FreeRTOS 初始化前拿到正确的 M 核时钟频率。