c - 在 STM32F411 Discovery 上实现 HD44780 LCD 时调试 HardFault

Question

我在使用此库在 STM32F411 Discovery 上对 LCD HD44780 进行编程时遇到问题:https://stm32f4-discovery.net/2015/07/hal-library-15-hd44780-for-stm32fxxx/问题是，在实现库并运行代码后，我通常会陷入 HardFault_Handler 函数中。我阅读了互联网上有关调试硬故障的几篇文章，并从该站点实现了 HardFault_HandlerC 函数:https://community.nxp.com/thread/389002程序现在陷入了这个函数，这让我了解了寄存器中的内容，但现在我真的不知道下一步应该做什么，因为这些值绝对没有告诉我任何内容。

这些是提到的寄存器的值:

stacked_r0  volatile unsigned long  0   
stacked_r1  volatile unsigned long  0   
stacked_r2  volatile unsigned long  0   
stacked_r3  volatile unsigned long  1   
stacked_r12 volatile unsigned long  45000000    
stacked_lr  volatile unsigned long  11018266    
stacked_pc  volatile unsigned long  553682714   
stacked_psr volatile unsigned long  8192    
_CFSR   volatile unsigned long  256 
_HFSR   volatile unsigned long  1073741824  
_DFSR   volatile unsigned long  11  
_AFSR   volatile unsigned long  0   
_BFAR   volatile unsigned long  3758157112  
_MMAR   volatile unsigned long  3758157108  

有人可以告诉我下一步应该做什么来进一步检查问题吗？

此外，我的随机运行程序也卡在这段代码中(而不是 HardFault):

/* Wait till LSE is ready */
      while(__HAL_RCC_GET_FLAG(RCC_FLAG_LSERDY) == RESET)
      {
        if((HAL_GetTick() - tickstart ) > RCC_LSE_TIMEOUT_VALUE)
        {
          return HAL_TIMEOUT;
        }
      }

这似乎与统一化LSE有关，但我认为我应该首先专注于调试硬故障。

Answer 1

调试硬故障是出了名的困难。您很可能已进入硬故障处理程序，因为发生了异常且没有可用的处理程序，但也可能是因为处理程序本身生成了异常。

如Lundin在评论中说，如果您有一个不错的调试器，您可以在硬故障处理程序中放置一个断点，并让调试器向您显示完整的调用堆栈。但如果没有，您将不得不采取困难的方式。

当CPU进入处理程序模式来处理异常时，各种寄存器被硬件推送到事件堆栈，并且您实现的处理程序将从堆栈中取出这些寄存器供您检查。首先要看的是堆栈程序计数器(PC)的内容。尝试获取其十六进制值；然后，您应该能够使用调试器将其与生成错误的指令的地址关联起来。

如果堆栈的 PC 地址与合理的代码地址不对应，则可能有另一行代码尝试分支到该无意义的地址，这就是触发故障的原因。在这种情况下，您可以通过查看堆栈链接寄存器 (LR) 地址来获取一些信息 - 这应该包含 CPU 上次遇到调用指令时程序计数器的值。这可能与生成恶意分支的行不完全对应，但它应该让您足够接近以放置另一个断点并逐步执行，直到异常发生。

如果这些不能让您找到罪魁祸首，我很乐意编辑此答案并提供进一步的建议 - 只需发表评论，我会回复您。