HardFault_Handler on STM32F407ZET6 - microcontroller

Question

I am currently facing some problems with STM32F4, the process "hangs" and I am not able to understand at what point it "locked". When this happened, I collected the following values for the following variables (I created the variable stepError to "translate" the CFSR variable):
void prvGetRegistersFromStack (uint32_t * pulFaultStackAddress)
{
volatile uint32_t CFSRValue = SCB-> CFSR;
volatile uint32_t HFSRValue = SCB-> HFSR;
char stepError [1024] = "";
if ((HFSRValue & (1 << 30)) = 0) {
CFSRValue >> = 16;
if ((CFSRValue & (1 << 9)) = 0) strcpy (stepError, "Divide by zero");
if ((CFSRValue & (1 << 8))! = 0) strcpy (stepError, "Unaligned access");
if ((CFSRValue & (1 << 3)) = 0) strcpy (stepError, "No UsageFault coprocessor");
if ((CFSRValue & (1 << 2)) = 0) strcpy (stepError, "Invalid PC load UsageFault");
if ((CFSRValue & (1 << 1))! = 0) strcpy (stepError, "Invalid state");
if ((CFSRValue & (1 << 0))! = 0) strcpy (stepError, "Undefined instruction");
}
/ * These are volatile to try and prevent the compiler / linker optimizing them
away the variables never actually get used. If the debugger will not show the
values of the variables, make them global my moving their declaration outside
of this function. * /
volatile uint32_t r0;
volatile uint32_t r1;
volatile uint32_t r2;
volatile uint32_t r3;
volatile uint32_t r12;
volatile uint32_t lr; / * Link register. * /
volatile uint32_t pc; / * Program counter. * /
volatile uint32_t psr; / * Program status register. * /
r0 = pulFaultStackAddress [0];
r1 = pulFaultStackAddress [1];
r2 = pulFaultStackAddress [2];
r3 = pulFaultStackAddress [3];
r12 = pulFaultStackAddress [4];
lr = pulFaultStackAddress [5]; // Bit (2 or 3) = 0 determines MSP (Main Stack Pointer); 1 = PSP (Process Stack Pointer)
pc = pulFaultStackAddress [6]; // Variable that contains the address where the error occurred. To check where it was, search the Disassembly on the screen Debug the address
psr = pulFaultStackAddress [7];
/ * When the following line is hit, the variables contain the register values. * /
// Joseph Yiu:
/ *
1) Look at LR value when the core enter hardfault, if bit 2 is 0, then read the value of MSP. Otherwise, read the value of PSP.
2) Based on the MSP / PSP value, you should be able to locate the start of stack frame, stacked PC is in address SP + 24.
3) Generate a disassembled listing of the program you run, and try to locate the stack PC address in the disassembled program list.
* /
GPIO_WriteLed (0,1);
for (int i = 0; i <= 10; i ++)
{
PWM_Change_DutyCycle (i, 0);
}
for (;;);
}
HFSRValue 1073741824 CFSRValue 0 StepError 0x2001fbb0 ""
r0 0 r1 0 r2 0 r3 11
r12 536890019 lr 134334773 pc 0x0801bab0 psr 3221225472
But I can not know from these values where the error occurred, whether it was caused by usb, serial, encoder or ADC converter and etc. How to implement void HardFault_Handler (void) so I can recognize where the error occurs?
Edit:From what I understand the disassembly shows the hardfault and not where the code was before hardfault.

Answer 1

You can find the address of the instruction/function that caused the fault from the exception stack frame:
In the example you gave this seems to be already passed to the prvGetRegistersFromStack function you've posted as the pulFaultStackAddress parameter. As you're interested in finding out which part of your code caused the HardFault, this can be found in the PC and LR that have been stacked - in your example those are taken from pulFaultStackAddress[6] and pulFaultStackAddress[5] respectively.
PC should contain the Program Counter, which is the instruction that was being executed as the fault occurred. LR should contain the Link Register value, which is the return address or in other words - address of the calling subroutine/function.
You've posted that those values are: pc 0x0801bab0 and lr 134334773 (0x801C935 in hexadecimal). Both values are valid addresses within internal flash for STM32F407ZE so we may assume they are valid. All that's left is to translate the memory addresses back to lines within your source code. Two examples of how to do so:
Using your IDE
Most IDEs nowadays have a "disassembly" view. Commonly used Eclipse-based ones (eg. SW4STM32 or TrueSTUDIO for STM32) have it under Window->Show View->Other->Debug->Disassembly. IAR also has one. Once open, paste the memory address (e.g. 0x0801bab0 which was the PC value) into the box during debugging and press Enter. That should show you the corresponding disassembly, interleaved with the source code lines. That should give you an idea of where the HardFault occurred.
Another approach is to..
Using your toolchain
Toolchains also have command line tools allowing you do the same thing as the option above. To give an example I'm going to assume you're using arm-none-eabi. There you can use the addr2line to translate the memory address back to source line code:
arm-none-eabi-addr2line.exe -e [your executable].elf -i 0x0801bab0
where [your executable] is the path to the ELF file you've loaded onto the MCU. The -i switch attempts to unwind inlined functions which sometimes helps to better see where the call originated from.
Whichever approach you choose from, you can do the same for both PC value (address of where the fault happened) and LR (caller).