Re: [lwip-users] blocked udp

[garibaldi pineda garcia]

Hi Noam,

 I really appreciate your help and thank you for the time you've taken to reply.

I believe my problem might be related to memory leaks, although I'm using a bare-metal application. The Zedboard has a dual Corex-A9 processor. So I process the video on the FPGA then transfer that via DMA to an ARM core; once the data is in a buffer in the ARM core I send things through the ethernet (Marvell 88E1518 PHY) using UDP.

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.

Cheers!

Best,

Gary

On 27 September 2016 at 12:35, Noam Weissman <address@hidden> wrote:

Hi Gary,

 

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.

 

 

 

BR,

Noam.

 

 

From: lwip-users [mailto:lwip-users-bounces+noam=address@hidden] On Behalf Of garibaldi pineda garcia
Sent: Tuesday, September 27, 2016 12:31 PM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] blocked udp

 

Hi Noam,

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!

Best,
Gary

 

Best,

Gary

 

On 26 September 2016 at 16:09, Noam Weissman <address@hidden> wrote:

Hi,

 

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?

 

BR,

Noam.

 

From: lwip-users [mailto:lwip-users-bounces+noam=address@hidden] On Behalf Of garibaldi pineda garcia
Sent: Monday, September 26, 2016 4:27 PM
To: address@hidden
Subject: [lwip-users] blocked udp

 

Hello all,

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?

 

Best,

Gary

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users

 

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users