Skip to main content
Ey.1
Associate II
March 23, 2021
Solved

Hardfault with Lwip Udp

  • March 23, 2021
  • 3 replies
  • 4080 views

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

This topic has been closed for replies.
Best answer by Piranha

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

3 replies

Ozone
Principal
March 23, 2021

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
Ey.1Author
Associate II
March 23, 2021

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 :(

Ozone
Principal
March 23, 2021

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.

Piranha
Principal III
March 24, 2021

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.

Ey.1
Ey.1Author
Associate II
March 24, 2021

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.

Piranha
PiranhaAnswer
Principal III
March 24, 2021

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