How to debug a hard fault exception for STM32?

[yanhc]

I am currently using stm32f407 with FreeRTOS as operating system in MDK IDE. Recently, When I added a new function ( The new function is ospf routing algorithm, and it is very complex and involves many files ) to my project, I began to encounter hard fought exception. I use the call stack window to check the context of the exception and found that the context is uart_send function. Since I redirect the printf function to uart_send and use it to print debug information so uart_send is called most frequently. When I comment the new added ospf function, everything goes fine, no hard fault exception and uart_send goes fine. So, the hard fault exception comes from the new added ospf function. However, I have no idea which part of the ospf function goes wrong and the call stack window gave nothing useful.

I have no idea what to do next? Could anyone tell me what to do next? Is there a procedure to debug a hard falt exception?

Thanks in advance!

[AvaTar]

> I found out that my hard fault is a FORCED one and is escalated by Usage fault which is UNALIGNED.

This doesn't make much difference.

As suggested, tracking down of such faults is often covered here.

Using the debugger is probably the easiest. Perhaps an out-of-bound access, or an odd type cast.

The address of the unaligned address should tell you more (see your map file).

[yanhc]

Hi, AvaTar!

Thanks for your reply!

I am using Keil MDK IDE (with FreeRTOS and LwIP and OSPF routing protocol). The MDK call stack screen capture is shown in the following image.

​

The call stack shows that 0x0801B758 of uart1SendChar cause the UNALIGNED Usage fault.

The instruction at address 0x0801B758 is as follows which is used to get the value of USART1->SR:

0x0801B758 8809   LDRH     r1,[r1,#0x00]

Since the USART1 is a peripheral structure and SR (Status Register) is the first element, I cannot figure out how could this instruction cause the UNALIGNED Usage fault?

I also find a strange phenomenon. When the UNALIGNED Usage fault is caused, my uart output is as follows:

lwip_select: no timeout, returning 0

Interface Event et0: [InterfaceUp]Filter out Linklocal: FE80::200:D4FF:FE01:1/128Interface state change et0: Down -> Waitinglwip_select(4, 200062e8, 200062e4, 200062e0, tvsec=0 tvusec=0)

lwip_select: no timeout, returning 0

No retr

If I set a breakpoint in the uart1SendChar function before "No retr" is printed. Then, one letter after another, the whole sentence can be printed as follows:

lwip_select: no timeout, returning 0

Interface Event et0: [InterfaceUp]Filter out Linklocal: FE80::200:D4FF:FE01:1/128Interface state change et0: Down -> Waitinglwip_select(4, 200062e8, 200062e4, 200062e0, tvsec=0 tvusec=0)

lwip_select: no timeout, returning 0

No retransmission scheduled, next interface

However, if I run again without any breakpoint, the UNALIGNED Usage fault will also be triggered in another place.

How could the UNALIGNED Usage fault disappear when there is breakpoint? I am very confused.

[yanhc · Accepted solution]

Finally, after I have changed the task stack size of the new added OSPF task from 500 to 2000, everything goes fine. However, I still cannot figure out how could task stack overflow cause the above strange phenomenon.

Or just as this link (https://www.micrium.com/detecting-stack-overflows-part-1-of-2/) says:

Stack overflows are common and can lead to some curious behaviors. In fact, whenever someone mentions that his or her application behaves “strangely,�? insufficient stack size is the first thing that comes to mind.

Although I am using a FreeRTOS operating system, my knowledge about os is very limited. It's time to make up this limitation for me.

Anyway, many thanks to @Community member​ @Community member​ @Bob S​ @Community member​ .