Hi, 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 ☺ 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 ? http://store.digilentinc.com/zedboard-zynq-7000-arm-fpga-soc-development-board/ 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 Ram !! BR, Noam. From: lwip-users [mailto:lwip-users-bounces+noam=silrd....@nongnu.org] On Behalf Of garibaldi pineda garcia Sent: Wednesday, September 28, 2016 12:46 PM To: Mailing list for lwIP users Subject: Re: [lwip-users] blocked udp 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 <n...@silrd.com<mailto:n...@silrd.com>> 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<mailto:lwip-users-bounces%2Bnoam>=silrd....@nongnu.org<mailto:silrd....@nongnu.org>] 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 <n...@silrd.com<mailto:n...@silrd.com>> 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<mailto:lwip-users-bounces%2Bnoam>=silrd....@nongnu.org<mailto:silrd....@nongnu.org>] On Behalf Of garibaldi pineda garcia Sent: Monday, September 26, 2016 4:27 PM To: lwip-users@nongnu.org<mailto:lwip-users@nongnu.org> 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 lwip-users@nongnu.org<mailto:lwip-users@nongnu.org> https://lists.nongnu.org/mailman/listinfo/lwip-users _______________________________________________ lwip-users mailing list lwip-users@nongnu.org<mailto:lwip-users@nongnu.org> https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
