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

Question

I have problem while programming LCD HD44780 on STM32F411 Discovery using this library: https://stm32f4-discovery.net/2015/07/hal-library-15-hd44780-for-stm32fxxx/ The problem is that after implementing the library and running the code I am usually get stuck in HardFault_Handler function. I read through a few articles on the internet about debuging hard faults and I implemented HardFault_HandlerC function from this site: https://community.nxp.com/thread/389002 The program now gets stuck in this function, which gives me insight about what is in the registers, but now I have really no idea what I should do next, because these values tell me absolutely nothing.

These are the values of mentioned registers:

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  

Can somebody please tell me what should I do next to inspect the problem further?

Also my program on random runs also gets stuck in this block of code (instead of 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;
        }
      }

Which seems to be related to unitialized LSE, but I think I should focus on debugging hard fault first.

Answer 1

Debugging hard faults is notoriously difficult. You have most likely entered the hard fault handler because an exception has occurred for which no handler is available, though it could possibly be because a handler has itself generated an exception.

As Lundin said in a comment, if you have a decent debugger you may be able to place a breakpoint inside the hard fault handler and have the debugger show you a complete call stack. But if not, you'll have to do it the hard way.

When the CPU enters handler mode to service the exception, various registers are pushed to the active stack by the hardware, and the handler you've implemented fetches these out of the stack for you to inspect. The first thing to look at is the contents of the stacked program counter (PC). Try to get its value in hexadecimal; you should then be able to relate this to the address of the instruction that generated the fault, by using the debugger.

If the stacked PC address doesn't correspond to a sensible code address, then it's possible that another line of code attempted to branch to this nonsense address and that's what triggered the fault. In this case you can get some information by looking at the stacked link register (LR) address - this should contain the value of the program counter from the last time the CPU encountered a call instruction. This might not correspond exactly to the line that generated the rogue branch, but it should get you close enough to place another breakpoint and step through until the exception occurs.

I am happy to edit this answer with further suggestions if these don't get you to the point of finding the culprit - just leave a comment and I'll get back to you.