/** * MEMP_NUM_TCP_PCB: the number of simulatenously active TCP connections. * (requires the LWIP_TCP option) */ #define MEMP_NUM_TCP_PCB 10
/** * MEMP_NUM_TCP_PCB_LISTEN: the number of listening TCP connections. * (requires the LWIP_TCP option) */ #define MEMP_NUM_TCP_PCB_LISTEN 4 I personally have found that to use Chrome I need at least 6 TCP connections as it opens new connection for each of the CSS files. Also with the STM32 their drivers for the PHY chips have some bugs. https://community.st.com/s/question/0D50X0000AivM4MSQU/hal-ethernet <https://www.google.com/url?q=https://community.st.com/s/question/0D50X0000AivM4MSQU/hal-ethernet&sa=D&source=hangouts&ust=1580918613367000&usg=AFQjCNH08XCtpxzs6GegvRj8cyW2TxSP9g> I do not use the STM32, but be careful if the GMAC driver does DMA transfers as you may need to turn off data cache on the core. On Tue, Feb 4, 2020 at 10:30 AM Adam Baron <vysoca...@gmail.com> wrote: > Not sure which parameter is defining maximum number of connections. > Processor is ARM 32bit STM32F407. > > út 4. 2. 2020 v 15:38 odesílatel Trampas Stern <tram...@gmail.com> napsal: > >> What is the maximum number of connections you have setup? >> >> Which processor are you using? >> >> Trampas >> >> On Tue, Feb 4, 2020 at 9:08 AM Adam Baron <vysoca...@gmail.com> wrote: >> >>> I'm bit new to lwip, and I'm using it on STM32407 with ChibiOS which is >>> RTOS. I'm using current stable version of lwip and bindings form ChibiOS to >>> run it as threads. My static and also dynamically generated html pages are >>> served well and without any issues. But I have problem with POST. I use the >>> example post striped down to bare minimum, that is the application does not >>> do any other thing on httpd_post_begin, _receive_data, _finished, then to >>> print the >>> parameters received. >>> >>> Now what I;m experiencing is that after few POSTs the whole lwip gets >>> stuck. Curiously enough, it does not get stuck in POST itself but in the >>> sending of subsequent html pages. >>> >>> Then after few more POSTs I get this from debug: >>> Opening /index.html >>> http_recv: data 536926228 len 1420 >>> http_send: pcb=536925064 hs=536926136 left=1420 >>> Trying to send 17 bytes >>> Sent 17 bytes >>> Trying to send 63 bytes >>> Sent 63 bytes >>> Trying to send 16 bytes >>> Sent 16 bytes >>> Trying to send 6 bytes >>> Sent 6 bytes >>> Trying to send 27 bytes >>> Sent 27 bytes >>> Trying to send 1420 bytes >>> Sent 1420 bytes >>> End of file. >>> Closing connection 536925064 >>> ethernet_output: sending packet p >>> ethernet_output: sending packet p >>> etharp_timer >>> etharp_timer >>> ethernet_output: sending packet p >>> etharp_timer >>> ....... >>> etharp_timer >>> >>> And the lwip is stuck, not sending the file requested by next GET, while >>> other threads work well. >>> Both threads serving lwip, called lwipthread and tcpip_thread are in >>> good state and not over flooded. >>> >>> Any ideas what can be the cause? >>> >>> Thanks Adam >>> _______________________________________________ >>> lwip-users mailing list >>> 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 > > > > -- > 731435556 > Adam Baron > _______________________________________________ > lwip-users mailing list > 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
