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 <[email protected]> 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:[email protected]] *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 <[email protected]> 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:[email protected]] *On > Behalf Of *garibaldi pineda garcia > *Sent:* Monday, September 26, 2016 4:27 PM > *To:* [email protected] > *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 > [email protected] > https://lists.nongnu.org/mailman/listinfo/lwip-users > > > > _______________________________________________ > lwip-users mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/lwip-users >
_______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
