2018-10-26 03:15 AM
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!
Solved! Go to Solution.
2018-10-31 09:32 PM
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 .
2018-10-26 03:27 AM
Are you using a large number of parameters to your debug printf ?
If so, I would check the buffer size the printf is expanded into.
Andy
2018-10-26 04:04 AM
Thanks for your reply!
I also tried to comment all the debug printf output. But I also encounter the hard fault exception. If I comment the new added ospf function, everything goes fine. So, I think the hard fault exception has no relation with the debug printf and it comes from the new ospf function. I just have no idea which part of the code goes wrong and have no experience in debugging hard fault exception.
2018-10-26 04:17 AM
The methods to chase down Hard Faults have been covered in recurrent topics.
2018-10-26 04:31 AM
Could you please provide the topic link? I have searched the stm32 forum and find limited information.
I found there is a Fault Reports in MDK as shown below with Call Stack. It can be seen that a Hard Fault is invoked and it is FORCED which means I should check other fault. Usage Fault is also invoked and it is an UNALIGNED access usage fault.
From the right of the above image, it can be seen that the call stack is very deep. Since uart1SendChar is tested before many times, so I guess somewhere of the new added ospf function may change the memory of others. Then, what should I do next to find which part of the code is wrong?
The following is the uart1SendChar code which is very simple. Then which memory of the following code is corrupted will cause the UNALIGNED access usage fault?
void uart1SendChar(u8 ch)
{
while((USART1->SR&0x40)==0);
USART1->DR = (u8) ch;
}
2018-10-30 08:23 AM
Hi, Andy!
After a long time debugging, now I think your suggestion is good. However, could you tell me how to check the buffer size the printf is expanded into?
I have redirect the printf function to uart_send as following:
#define PUTCHAR_PROTOTYPE int fputc(int ch, FILE *f)
PUTCHAR_PROTOTYPE
{
uart1SendChar(ch);
return ch;
}
void uart1SendChar(u8 ch)
{
while((USART1->SR&0x40)==0);
USART1->DR = (u8) ch;
}
Thanks very much!
2018-10-30 09:23 AM
The C99 standard suggests that the buffer should be large enough to handle at least 4095 characters but not sure how large the buffer is in the library ST uses.
Andy
2018-10-30 02:09 PM
Are you using the MPU? Search for "hardfault mpu" (without quotes, with "hardfault" as one word). Though the search results are flaky (for me) right now - lots of "check your connection" pop-up errors. So here is the link:
2018-10-30 06:03 PM
Hi, Bob. Thanks for your reply.
I have check the my setting. The MPU (Memory Protection Unit) is not enabled.
After I have check further with my hard fault, I found out that my hard fault is a FORCED one and is escalated by Usage fault which is UNALIGNED. The following image is the screen capture after I enable the Usage Fault.
However, do you known how to find which line of code or which assembler instruction that cause this UNALIGNED fault?
I have redirect the printf function to uart send as following:
#define PUTCHAR_PROTOTYPE int fputc(int ch, FILE *f)
PUTCHAR_PROTOTYPE
{
uart1SendChar(ch);
return ch;
}
void uart1SendChar(u8 ch)
{
while((USART1->SR&0x40)==0);
USART1->DR = (u8) ch;
}
Thanks very much.
2018-10-30 10:42 PM
Hi Andy!
I checked the project setting and found that I am using Micro LIB, not the standard ARM C library. The following image is my project options setting.
The Keil website says that Micro LIB has support for printf (http://www.keil.com/support/man/docs/armlib/armlib_chr1358938940288.htm). However, how could I check the buffer size of printf in Micro LIB?
Thanks again!
p.s. My project is made from STSW-STM32070, LwIP TCP/IP stack demonstration for STM32F4x7 microcontrollers (AN3966) (https://www.st.com/zh/embedded-software/stsw-stm32070.html).