cancel
Showing results for 
Search instead for 
Did you mean: 

Hardfault with Lwip Udp

Ey.1
Associate II

Hello, I'm having trouble about use of lwip on Stm32h743. I'm using udp raw. I'm transmitting packet with 1ms period, there is no problem in sending/receiving. After 20-30 min, program is going to hardfault with 'Imprecise data access violation'. It is occuring at mem_free(void *rmem) function in mem.c file. The stack was just like this: GATEWAY_ADDRESS() -> mem_free() -> HardFault. I'm also attaching the disassembly. Thank you for your helps.

0693W000008xdWuQAI.png

1 ACCEPTED SOLUTION

Accepted Solutions

That's a good example of why a documentation must be read:

https://www.nongnu.org/lwip/2_1_x/pitfalls.html

And, when using RTOS, also:

https://www.nongnu.org/lwip/2_1_x/multithreading.html

View solution in original post

6 REPLIES 6
Ozone
Lead

I don't know the H7 series.

> It is occuring at mem_free(void *rmem) function in mem.c file. The stack was just like this: GATEWAY_ADDRESS() -> mem_free() -> HardFault.

Memory used in malloc/free functions is taken from the heap, not the stack.

Not sure where the implementations of those functions come from in your case, but I would focus on that. And linker script / heap size.

Ey.1
Associate II

I can not track, because where is the GATEWAY_ADDRESS(), I could not find it. Additionally, I increased the stack/heap size. Hardfault does not occur now, but the connection is getting lost after a while. I can not get answer even when I send ping request. I use the board as server. I checked my raw api functions, I think there is no problem, because they are very simple and looks very similar to examples. Problem is elsewhere but I don't know where :(

Wireshark and debugging ...

I used to avoid the IoT hype whenever possible.

Most MCUs and MCU boards are ill-equipped to handle real-world network traffic.

Ey.1
Associate II

I was transmitting the packet in timer interrupt elapsed callback which is equal to 1ms period. I moved the code into my main loop with checking systick so that time period stay same. Now, it is working without any error since the yesterday.

I debunked those MCU/Ethernet myths long ago by explaining all the details and even pointing from where those myths come. Read my latest and longest post in this topic:

https://community.st.com/s/question/0D50X0000BNu2BFSQZ/ethernet-performance-packets-loss

IoT hype is pushed by marketing hipsters, but the most ironic thing is they do not even understand what an IoT actually is. Their narrow minds think it's some sensors with 5G modem, but that is only one small part of it. Remember the analog security cameras with coaxial cable? Almost all new installations are based on Ethernet with PoE. That is the real IoT which started long before the IoT hype and which is not even notices by the marketing dummies.

That's a good example of why a documentation must be read:

https://www.nongnu.org/lwip/2_1_x/pitfalls.html

And, when using RTOS, also:

https://www.nongnu.org/lwip/2_1_x/multithreading.html