STM32 HardFault_Handler错误定位方法

来源:互联网 发布:ip绑定mac地址 编辑:程序博客网 时间:2024/05/22 12:53

Your program most likely crashes because of an illegal memory access, which is almost always an indirect (subsequent) result of a legal memory access, but one that you did not intend to perform.

For example (which is also my guess as to what's happening on your system):

Your heap most likely begins right after the stack. Now, suppose you have a stack-overflow in main. Then one of the operations that you perform in main, which is naturally a legal operation as far as you're concerned, overrides the beginning of the heap with some "junk" data.

As a subsequent result, the next time that you attempt to allocate memory from the heap, the pointer to the next available chunk of memory is no longer valid, eventually leading to a memory access violation.

So to begin with, I strongly recommend that you increase the stack size from 0x200 bytes to 0x400 bytes. This is typically defined within the linker-command file, or through the IDE, in the project's linker settings.

If your project is on IAR, then you can change it in the icf file:

define symbol __ICFEDIT_size_cstack__ = 0x400

Other than that, I suggest that you add code in your HardFault_Handler, in order to reconstruct the call-stack and register values prior to the crash. This might allow you to trace the runtime error and find out exactly where it happened.

In file 'startup_stm32f03xx.s', make sure that you have the following piece of code:

EXTERN  HardFault_Handler_C        ; this declaration is probably missing__tx_vectors                       ; this declaration is probably there    DCD     HardFault_Handler

Then, in the same file, add the following interrupt handler (where all other handlers are located):

    PUBWEAK HardFault_Handler    SECTION .text:CODE:REORDER(1)HardFault_Handler    TST LR, #4    ITE EQ    MRSEQ R0, MSP    MRSNE R0, PSP    B HardFault_Handler_C

Then, in file 'stm32f03xx.c', add the following ISR:

void HardFault_Handler_C(unsigned int* hardfault_args){    printf("R0    = 0x%.8X\r\n",hardfault_args[0]);             printf("R1    = 0x%.8X\r\n",hardfault_args[1]);             printf("R2    = 0x%.8X\r\n",hardfault_args[2]);             printf("R3    = 0x%.8X\r\n",hardfault_args[3]);             printf("R12   = 0x%.8X\r\n",hardfault_args[4]);             printf("LR    = 0x%.8X\r\n",hardfault_args[5]);             printf("PC    = 0x%.8X\r\n",hardfault_args[6]);             printf("PSR   = 0x%.8X\r\n",hardfault_args[7]);             printf("BFAR  = 0x%.8X\r\n",*(unsigned int*)0xE000ED38);    printf("CFSR  = 0x%.8X\r\n",*(unsigned int*)0xE000ED28);    printf("HFSR  = 0x%.8X\r\n",*(unsigned int*)0xE000ED2C);    printf("DFSR  = 0x%.8X\r\n",*(unsigned int*)0xE000ED30);    printf("AFSR  = 0x%.8X\r\n",*(unsigned int*)0xE000ED3C);    printf("SHCSR = 0x%.8X\r\n",SCB->SHCSR);                    while (1);}

If you can't use printf at the point in the execution when this specific Hard-Fault interrupt occurs, then save all the above data in a global buffer instead, so you can view it after reaching the while (1).

Then, refer to the 'Cortex-M Fault Exceptions and Registers' section athttp://www.keil.com/appnotes/files/apnt209.pdf in order to understand the problem, or publish the output here if you want further assistance.

UPDATE:

In addition to all of the above, make sure that the base address of the heap is defined correctly. It is possibly hard-coded within the project settings (typically right after the data-section and the stack). But it can also be determined during runtime, at the initialization phase of your program. In general, you need to check the base addresses of the data-section and the stack of your program (in the map file created after building the project), and make sure that the heap does not overlap either one of them.

I once had a case where the base address of the heap was set to a constant address, which was fine to begin with. But then I gradually increased the size of the data-section, by adding global variables to the program. The stack was located right after the data-section, and it "moved forward" as the data-section grew larger, so there were no problems with either one of them. But eventually, the heap was allocated "on top of" part of the stack. So at some point, heap-operations began to override variables on the stack, and stack-operations began to override the contents of the heap.

0 0