|Subject:||Re: [lwip-users] blocked udp|
|Date:||Wed, 28 Sep 2016 10:10:09 +0000|
No problems, I enjoy it.
I head lots of help from people here when I started so it’s just reasonable that I will help
others when I can J
As far as I understand and also from my own experience there is no memory leak. You
simply do not use LwIP properly.
In RAW mode when you call tcpip_init function and I it will call (inside) sys_thread_new.
This is where (as I understand) the LwIP own task is created.
When you try to send data from your own main it is not from within the LwIP context
and that is what is causing you to get into memory leaks.
By the way you did not answer if you use an OS or not ????
If you use an OS the problem is that TCP stack task should be one of the highest priority tasks.
That means that you send data from your main task but you have no control when the OS does its
context switch and let LwIP run before it returns the context to your own task.
As a result you get into synchronization issues with LwIP and that causes the memory leaks.
It is like accessing a shared buffer or data base without protecting that with semaphores etc…
I hope this is understood now.
Is this the board you are using ?
If this is the board why do you use LwIP and more than that why use RAW mode ??
You use LwIP RAW mode when you do not need or cannot use an OS in systems limited
with resources. If this is the board you use it has 512Mb RAM This is almost unlimited RAM
compared to what I am referring to. I am running LwIP on systems that have 96-192 Kbyte
From: lwip-users [mailto:lwip-users-bounces+address@hidden
On Behalf Of garibaldi pineda garcia
I really appreciate your help and thank you for the time you've taken to reply.
What I do is have an interrupt to receive the data from the FPGA and, in the main program loop (would this be the LWIP context?), I call a function to send data out. I also have an interrupt for the receive
function for the LWIP data.
On 27 September 2016 at 12:35, Noam Weissman <address@hidden> wrote:
Sorry but I did not understand completely your answer.
Do you use FreeRTOS or any other OS or no OS at all ?
I presume you use an OS and my reply is based on that estimate.
Let me explain. LwIP in RAW mode is not thread safe and more than that you are not
allowed to call LwIP functions outside of the LwIP context. In RAW mode all the TCP code
run’s within one task. That means that timers, TCP handshake, your application code etc…
All that is running under the same context.
So if you get some data in recv callback only after you exit the function the TCP stack returns
To do its own house keeping etc.
Were the problem is?... If you call any of the LwIP functions from your application not from within
The TCP stack context you are not synchronized with the internal code and may find your code
unstable or even crashing.
Now that I explained the above lets assume you define an array of 500 bytes. Fill it with random
data and every time you get some data in your recv function callback you call tcp_write and send
the random data. This is fine and runs within the TCP context. No problems here.
If you try calling tcp_write from within one of your task, not from inside the TCP context it may fail
or have strange behavior. The most common problem that people complain is “memory leaks”
I had that for a long time until I understood the problem and added synchronization code.
You must find a way to synchronize your data creation and the need to send it out.
One way is to create a cyclic buffer or set of buffers accessed from your application (fill data)
And on the TCP side periodically check if there is new data to send and send it from within the
LwIP own context.
A second way to do it, not so preferred by some peoples but worked for me, is to add critical
Sections in code that call’s LwIP functions. Adding a critical section means that you block other
Tasks for a short time. Especially the TCP task from running. It means that if you allocate a buffer from
the LwIP pool until you do not Call exit from the critical section the TCP task will not run and therefore
will not interfere.
If we stick to the “correct” way to do it use LwIP sys_timeout … for example if you need to send out
data every 50 ms you set the sys_timeout to call a function. Once the 50ms time has been passed LwIP
will call your function from within the TCP own context and do something.
Lets assume you fill a cyclic buffer from your application and the above call back checks this buffer for data.
If it has something it will send it out but it will work from within the TCP context.
Another BIG overlooked problem is the Cortex-M3 interrupt levels definitions. If you work with FreeRTOS
And probably other OS have the same problem or misunderstanding… The OS has its own timetick interval
Or OS priority. If your TCP priority is higher than the OS tick the OS will not be able to musk the TCP stack
Task when it enters its own critical sections. That also leads to unpredictable system behavior and may cause
hanging, lowness etc…
Sorry for the long text and for repeating myself.
I hope that will help you stabilize your code.
From: lwip-users [mailto:lwip-users-bounces+noam=address@hidden]
On Behalf Of garibaldi pineda garcia
I'm using the RAW API, I chose that for performance.
By sending random data I mean I allocate a buffer in the ARM core and continuously send that through Ethernet/UDP. I'm also trying to send the video through Ethernet/UDP, I'm basically sending the differences between consecutive frames.
Thanks for your time!
On 26 September 2016 at 16:09, Noam Weissman <address@hidden> wrote:
What API are you using?... RAW, Netconn or Socket ?
When you say you send random data, how do you send it. I mean do you send it from
Within the LwIP context or via the route you try to send the video?
I'm building a system which encodes video in a Zedboard FPGA and sends it out through the ethernet port. I have tested sending random data out and it works, but when I try to use the data from the video source I manage to set the ARM core/network in a locked state. I've also tested the system without sending any data through etherenet and it works fine.
I've increased memory and pool sizes; I also decreased the Time-To-Live for all protocols and tried using a global pbuf or a dynamic local pbuf.
These setting seem to get the system working a bit longer, but I still get locked whenever the video encoding requires to send more than random data.
Does anyone have suggestions on what I could do?
|[Prev in Thread]||Current Thread||[Next in Thread]|