STM32+HAL+FreeRTOS，已经修改了系统时钟为定时器，为什么还卡死在HAL_Delay()

问题

使用CubeMX创建了STM32的工程，启用了FreeRTOS，使用的是HAL库，运行后发现卡死在HAL_Delay()，修改了Timebase Source后正常了，后来加入了USB，又卡死了，参考这篇文章解决，后来我又加了一个串口进行通信测试，发现又卡死了，唉。。。

具体原因

其实，通过上述的两种配置后，不应该出现HAL_Delay()卡死的问题了，如果你确实遇到了，可以看看是不是和我相同的问题。
我的问题其实是因为调用HAL_Delay()的地方太靠前了，在osKernelStart();调用之前调用的，这样是会有问题的，事实也验证了这一点，具体原因我们参考一下文心一言的回答吧：

在嵌入式系统或RTOS（实时操作系统）环境中，通常不建议在osKernelStart（或任何RTOS内核启动函数）之前调用与硬件抽象层（HAL）相关的函数，如HAL_Delay()。原因有以下几点：
RTOS未初始化：在RTOS内核启动之前，RTOS提供的服务（如任务调度、时间管理、中断管理等）都还没有被初始化。因此，依赖于RTOS服务的函数（如HAL_Delay()，如果它依赖于RTOS的时间管理）可能不会按预期工作。
系统状态不确定：在RTOS启动之前，系统的状态是不确定的。此时，调用某些函数可能会导致不可预测的行为或系统崩溃。
HAL函数依赖RTOS：某些HAL函数可能依赖于RTOS提供的服务。在RTOS启动之前调用这些函数可能会导致问题。
不恰当的延迟：HAL_Delay()函数通常用于在RTOS环境中创建延迟。但是，在RTOS启动之前，你可能没有有效的任务调度器或时间管理功能，因此延迟可能无法正确实现。
如果你需要在RTOS启动之前进行某种形式的延迟，你可能需要考虑使用以下方法：
忙等待：使用简单的循环来创建延迟。这种方法会阻塞CPU，但在RTOS启动之前，这可能是唯一可行的方法。
c
for (volatile uint32_t i = 0; i < SOME_LARGE_NUMBER; i++) {
// 空循环，创建延迟
}
硬件定时器：如果硬件支持，并且你有足够的硬件知识，你可以直接使用硬件定时器来创建延迟。但是，请注意，这种方法需要你对硬件有深入的了解，并且可能需要编写特定的硬件相关代码。
调整启动顺序：如果可能的话，尝试调整你的启动顺序，以便在需要延迟之前启动RTOS。这样，你就可以使用RTOS提供的服务来创建延迟。
总的来说，在RTOS启动之前调用HAL_Delay()（或任何依赖于RTOS服务的函数）通常是不安全的，并且可能会导致不可预测的行为或系统崩溃。你应该尽量避免这样做，并寻找其他方法来满足你的需求。

总结

关于卡死在HAL_Delay()的问题，网上有很多类似的解决方法，资料还是挺多的，如果你尝试了所有的方法还是没有解决，那就看看是不是和我的问题相同吧，提供一个思路。