STM32 使用HAL库,HAL_Delay()会卡死, 程序一直卡在 HAL_GetTick( ) 函数中(已解决)

文章讲述了作者在STM32F103C8T6单片机项目中遇到系统卡在HAL_Delay中的问题,通过追踪发现是定时器TIM3的停止和开启导致的uwTickFreq变为0,最终通过重写HAL_IncTick函数解决了问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

今天遇到个很奇怪的问题, 不知道为什么, 单片机运行一会之后, 系统就没反应了, 经过调试发现, 系统卡在HAL_Delay()中了.
之前也遇到过这个问题后来把HAL_Delay 去掉了. 然后发现不行, 还是得有它.不然发串口数据发的太快会乱掉. 得慢点发.

然后调试到HAL_Delay()方法的内部发现 HAL_GetTick( )函数一直返回

__weak void HAL_Delay(uint32_t Delay)
{
  uint32_t tickstart = HAL_GetTick();
  uint32_t wait = Delay;

  /* Add a freq to guarantee minimum wait */
  if (wait < HAL_MAX_DELAY)
  {
    wait += (uint32_t)(uwTickFreq);
  }
	
  //卡在这个while函数里
  while ((HAL_GetTick() - tickstart) < wait)
  {
  }
}

再跟踪发现 HAL_GetTick() - tickstart 永远等于0
这就很奇怪了.
于是再深入看一下HAL_GetTick()函数. 代码如下

__weak uint32_t HAL_GetTick(void)
{
  return uwTick;
}

也就是说, uwTick 不再更新了. 数值永远是某个固定数值.
那uwTick 到底是怎么更新的呢?
最后发现
在这里更新的.

__weak void HAL_IncTick(void)
{ 
  uwTick += uwTickFreq;
}

调试发现 uwTickFreq ===0
也就是说, uwTick 不再增加了.
所以导致外层的while死循环了.
那么uwTickFreq又是什么时候变成0的呢?
我跟踪了很久也没有拦截到uwTickFreq 是什么时候更新的. keil工具也拦截不到是什么时候更新的.
最后索性, 给uwTickFreq 一个默认值. 只要发现 uwTickFreq 为0了.
就给它个默认值., 然后就把代码改成了下面这样的函数.
由于源代码函数是__weak 的, 也就是说, 可以被覆盖的.
于是我在自己的main.c 文件代码中重新写了一下. 如下:

void HAL_IncTick(void)
{
	if(uwTickFreq==0)
	{
		uwTickFreq = HAL_TICK_FREQ_DEFAULT;
	}
  uwTick += uwTickFreq;
}

如果不在乎延迟时间的精准度, 可以考虑.写成下面的这种, 更快一点

void HAL_IncTick(void)
{ 
  uwTick += HAL_TICK_FREQ_DEFAULT;
} 

后来经过调试, 我猜测是因为定时器的停止和开启导致的.
具体中间的原因就不再深入细究了. 有时间精力的朋友可以再追踪下去.
找到原因欢迎分享.

我用的是STM32F103C8T6 , 其中的定时器TIM3用来驱动ADC的采样频率.
在循环中不停的停止和开启Tim3. 我估计是因为这个原因导致的. uwTickFreq 重新计算.

而且我这里做了自动计算Tim3的自动重载计数值. 估计是跟它有关.
具体的不再深入探究了.
延迟时间就写死吧…

后来我换了个定时器, 不再重置TIM定时器的PSC, 然后就好了. .

昨天电脑坏了重装系统, 然后小半年的代码都没了. …我操…该死的Dell电脑, 恶心的要死, 故意搞的不能重装系统. 不能从u盘启动, 以后再也不买dell电脑了. …

STM32delay 程序卡死通常有以下几个原因: 1. **无限循环**:最常见的原因之一就是代码中存在了一个无限循环。例如,在处理延时功能时,如果未正确设置退出条件,可能导致定时器中断无法触发,进而导致程序一直运行而不会停止。 示例错误代码片段: ```c while (1) { HAL_Delay(1000); // 这里应该有一个退出条件 } ``` 2. **硬件资源冲突**:某些操作可能会占用系统的重要资源,如内存、CPU周期或其他外设资源,并长时间消耗它们而不释放。这可能导致其他部分的程序无法正常运行或等待资源释放的时间过长。 3. **中断服务例行程序(ISR)阻塞**:如果中断服务例行程序中包含了可能永远执行下去的代码段,如持续读取某个传感器值并进行复杂计算,而没有适当的退出机制,则可能导致中断处理过程无限循环。 4. **内存泄漏**:如果程序中存在内存分配但未能正确地进行内存释放的情况,随着程序运行时间的增长,可用内存逐渐耗尽,最终可能导致系统崩溃或程序无法继续执行。 5. **外部因素影响**:比如电源供应不稳定、外部设备故障等也可能导致程序异常终止或运行缓慢。 解决这类问题的一般步骤包括: - 检查代码中是否有无限循环的结构,尤其是与延迟相关的代码。 - 查看是否有效管理了所有硬件资源,确保没有长期占有重要资源。 - 审核中断服务程序,确保其内部逻辑能够及时完成任务并在必要时退出。 - 使用调试工具跟踪程序的执行流程,观察程序何时进入异常状态以及可能出现的错误点。 - 对代码进行单元测试和集成测试,特别是在涉及延时和中断的地方,确保每个模块都能正常工作。 相关问题: 1. 在编写 STM32delay 程序时如何避免出现无限循环? 2. 当遇到 STM32硬件资源紧张导致的程序卡死时,应采取哪些措施? 3. 在调试 STM32 程序时,有哪些常见的方法可以检测出程序卡死的原因?
评论 19
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值