在STM32中,使用HAL_Delay()函数时可能会遇到卡死的问题。这个问题通常与HAL_Delay()函数的实现机制和优先级设置有关。以下是可能导致HAL_Delay()卡死的几个原因及相应的解决方案: 1. HAL_Delay()函数的使用不当 HAL_Delay()函数依赖于SysTick定时器来计时。如果在SysTick中断处理函数(通常是
使用stm32cubeProgrammer连接stm32 点左侧OB 配置nBOOT1=0 nSWBOOT0=0 nBOOT0=1(为0就卡在HAL_Delay) 我知道有些人本来就是这个设置,但是就是会卡住, 如果你本来就是这样设置,先反向设置一下保存然后再设置回来就可以
所以在中断里调用HAL_Delay会卡死，所以我们需要去调高滴答定时器的抢占优先级，调低中断的抢占优先级...
之前也遇到过这个问题后来把HAL_Delay 去掉了. 然后发现不行, 还是得有它.不然发串口数据发的太快会乱掉. 得慢点发. 然后调试到HAL_Delay()方法的内部发现 HAL_GetTick( )函数一直返回 __weak void HAL_Delay(uint32_t Delay) { uint32_t tickstart = HAL_GetTick(); uint32_t wait = Delay; /* A...
在HAL_Delay(PHY_RESET_DELAY);之前的调试信息能打印出来,它之后的就打印不出来了。把该延时函数注释,又能正常运行,直到遇到下一个HAL_Delay函数。 这里可以确定是HAL_Delay();延时函数导致卡死在这里了。 但是很不解,一个通用的HAL_Delay();函数,怎么就成了元凶?!
STM32使用HAL库,使用延时卡死的问题。 之前一直使用标准库的,现在转到HAL库来后,编写了第一个程序就遇到了问题。发现我使用库里的延时程序HAL_Delay()时,会卡死在里面。 根据程序,进入到这个延时程序后 ,发现HAL_GetTick()取来的数字一直没有变化,才发现是因为...
STM32CubeMX FreeRTOS HAL_Delay 卡死 FreeRTOS作为开源的轻量级实时性操作系统,不仅实现了基本的实时调度、信号量、队列和存储管理,而且在商业应用上不需要授权费。 FreeRTOS的实现主要由list.c、queue.c、croutine.c和tasks.c 4个文件组成。list.c 是一个链表的实现,主要供给内核调度器使用;queue.c 是一个...
Interrupt这一词是问题的关键,既然是中断,势必就有优先级,如果在中断里面HAL_Delay会卡死,而main函数则不会,那么有没有可能是Systick优先级太低造成的呢。带着这个问题我们回到STM32CubeMX中重新找到NVIC。 这时候我们注意到在默认使能的中断里面有一个System tick的中断,这就是给HAL_Delay函数提供时基的定时器...
一是优先级的问题，我设置的优先级高于HAL_Delay的优先级造成一直在HAL_Delay中卡死，还有一种就是...
HAL_Delay()函数的注意事项 特别注意,在中断中使用HAL_Delay()很容易造成程序异常,原因是HAL_Delay()使用 滴答定时器的中断,如果在高于滴答定时器中断的中断函数中使用这个函数,程序将会锁死在HAL_delay()中,原因是,滴答定时器无法别调用,HAL_delay()就无法跳出函数内部的 while 循环。