HardFault UDP Client

[LEAMtw]

Hi Community,

I am using the Nucleo-H723ZG board for data receiving from the camera by utilizing the spi and processing the data then transforming the data through UDP to another program. The program can run for several hours without problem. But then it will suddenly lead to a HardFault problem caused by the wrong pointer to an invalid address inside the function of ethernet_input(struct pbuf *p, struct netif *netif) in the ethernet.c.  The ethhdr is pointed to an invalid address and causes the HardFault: ethhdr = (struct eth_hdr *)p->payload; The address as I checked is a reserved memory somewhere, which can not be accessed (please also see the photo). The HardFault is very difficult to get, as it takes hours to run the program. 

Thanks for the help in advance.

[SofLit]

Hello,

Not easy to tell you what the origin of a HardFault, you need to debug it yourself: you can see this article.

Start by increasing tasks stack as you are using (I think) FreeRTOS.

[Andrew Neil]

---

@LEAMtw wrote:

The HardFault is very difficult to get, as it takes hours to run the program. 

---

and that's for you - when you have the code and know the system, and can see it in context.

We don't have your code, and know nothing about your system - so, as @SofLit said, really impossible to say what's causing it.

You need to instrument your code to give insight into what's happening.

Make sure you are checking all return values from all APIs - particularly memory allocation.

You haven't said what IP stack you're using - maybe it has diagnostic options you can enable?

Does FreeRTOS have diagnostic options you can enable?

---

@LEAMtw wrote:

The program can run for several hours without problem. But then it will suddenly lead to a HardFault 

---

One thing that can cause errors "after a while" is a memory leak ... ?

[SofLit]

---

---

@LEAMtw wrote:

The program can run for several hours without problem. But then it will suddenly lead to a HardFault 

---

One thing that can cause errors "after a while" is a memory leak ... ?

---

Yes it could be. That's why I suggested him to increase the stack.

[Andrew Neil]

---

@SofLit wrote:

---

---

---

Yes it could be. That's why I suggested him to increase the stack.

---

Indeed. :thumbs_up:

@LEAMtw if the problem is a memory leak, this won't fix the problem - but could extend the time until it manifests...

[SofLit]

---

@SofLit wrote:

---

---

@LEAMtw wrote:

The program can run for several hours without problem. But then it will suddenly lead to a HardFault 

---

One thing that can cause errors "after a while" is a memory leak ... ?

---

Yes it could be. That's why I suggested him to increase the stack.

---

Set stack overflow and malloc failed flags in FreeRTOSConfig.h 

#define configCHECK_FOR_STACK_OVERFLOW           1
#define configUSE_MALLOC_FAILED_HOOK             1

 And declare these two callbacks elsewhere in your code, for example in freertos.c

void vApplicationStackOverflowHook(xTaskHandle xTask, signed char *pcTaskName)
{
   while(1){}
}

void vApplicationMallocFailedHook(void)
{
   while(1){}
}

See if it does stop in one of the while loops.

[LEAMtw]

Hello, @SofLit @Andrew Neil 

Thank you for the quick replies. I am using the FreeRTOS and the LwIP for my application. I think maybe the problem is somewhere at the LwIP library. I have tried to activate some of the options in the opt.h from the LwIP, such as the mem_overflow_check, it helps the program to run longer, but still, it will at end fail into the HardFault. I will go through what you have suggested about the debugging of HardFault and see if I can find the source of the problem. But, as a quick test, my program didn’t run into the while(1) loop, when using the vApplicationStackOverflowHook and vApplicationMallocFailedHook(void). I have set the stack size to 1024 Words, I think it should be big enough. Since it will take some time to run the program into the HardFault, so I will get an update when I find something there.  

I would like to thank both of you for your valuable suggestions.

[SofLit]

---

@LEAMtw wrote:

But, as a quick test, my program didn’t run into the while(1) loop, when using the vApplicationStackOverflowHook and vApplicationMallocFailedHook(void). 

---

Don't expect to get it quick, you need to wait until the issue occurs.

[Andrew Neil]

@eduardo_reis - your replies moved to a thread of their own, as the situation & symptoms don't match:

https://community.st.com/t5/stm32-mcus-embedded-software/re-hardfault-udp-client/td-p/753371