Thank you Krzysztof, Indeed I am getting several TX Underrun errors, that's why packets are missing, so bad in fact that is unusable together with the LCD controller activated.
>From the LPC178x manual: "Underrun errors can have three causes: • The next fragment in a multi-fragment transmission is not available. This is a nonfatal error. A NoDescriptor status will be returned on the previous fragment and the TxError bit in IntStatus will be set. • The transmission fragment data is not available when the Ethernet block has already started sending the frame. This is a nonfatal error. An Underrun status will be returned on transfer and the TxError bit in IntStatus will be set. • The flow of transmission statuses stalls and a new status has to be written while a previous status still waits to be transferred across the memory interface. This is a fatal error which can only be resolved by a soft reset of the hardware. The first and second situations are nonfatal and the device driver has to re-send the frame or have upper software layers re-send the frame. In the third case the hardware is in an undefined state and needs to be soft reset by setting the TxReset bit in the Command register." Any ideas how to overcome this? So far I tried lowering the frame size TCP_MSS from 1460 to 536 and the PHY clock rates, but without success. On Thu, Jan 2, 2014 at 8:55 PM, Lehel Benedek <[email protected]>wrote: > Thank you Krzysztof, > > Indeed I am getting several TX Underrun errors, that's why packets are > missing, so bad in fact that is unusable together with the LCD controller > activated. > > From the LPC178x manual: > "Underrun errors can have three causes: > • The next fragment in a multi-fragment transmission is not available. > This is a nonfatal > error. A NoDescriptor status will be returned on the previous fragment and > the TxError > bit in IntStatus will be set. > • The transmission fragment data is not available when the Ethernet block > has already > started sending the frame. This is a nonfatal error. An Underrun status > will be returned > on transfer and the TxError bit in IntStatus will be set. > • The flow of transmission statuses stalls and a new status has to be > written while a > previous status still waits to be transferred across the memory interface. > This is a fatal > error which can only be resolved by a soft reset of the hardware. > The first and second situations are nonfatal and the device driver has to > re-send the frame > or have upper software layers re-send the frame. In the third case the > hardware is in an > undefined state and needs to be soft reset by setting the TxReset bit in > the Command > register." > > Any ideas how to overcome this? > So far I tried lowering the frame size TCP_MSS from 1460 to 536 and the > PHY clock rates, but without success. > > > > On Thu, Jan 2, 2014 at 1:00 AM, <[email protected]> wrote: > >> Send lwip-users mailing list submissions to >> [email protected] >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.nongnu.org/mailman/listinfo/lwip-users >> or, via email, send a message with subject or body 'help' to >> [email protected] >> >> You can reach the person managing the list at >> [email protected] >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of lwip-users digest..." >> >> Today's Topics: >> >> 1. missing TX packets (Lehel Benedek) >> 2. Re: missing TX packets (Krzysztof Weso?owski) >> >> >> ---------- Forwarded message ---------- >> From: Lehel Benedek <[email protected]> >> To: [email protected] >> Cc: >> Date: Wed, 1 Jan 2014 15:13:14 +0800 >> Subject: [lwip-users] missing TX packets >> Hello, >> >> I'm using an SBC1788 board with an LPC1788 micro controller and >> successfully implemented a web server based on lwIP v1.4.1 with FreeRTOS >> v7.4.2. >> I am using zero copy TX buffers located in the external SDRAM, the >> performance is quite good (the webpage of 600KB (also buffered in the >> external SDRAM) gets loaded up in less than 1sec), and was working >> flawlessly, until I added emWin to the project. Using the embedded LCD >> controller from the LPC1788 and the video buffers also located in the >> external SDRAM I got also the LCD and touchscreen working, however I notice >> that the web-server was no longer working. >> After some debugging I found the following: >> - the problem with the web-server is that some TX packets are not sent >> out at all, although the frame transmission gets correctly called, so from >> 100 packets only around 70-80 are sent out >> - the only thing that will cause this problem is the LCD power control. >> When I enable power to the LCD controller the problem is there, if I >> disable power to the LCD controller it's gone. >> >> I'm guessing it could be a conflict between the Ethernet chip and LCD >> controller both accessing the external SDRAM through DMA, but I have no >> idea on how to proceed. >> I tried different AHB matrix priority settings, without any success. >> >> Any thoughts on this? >> >> >> ---------- Forwarded message ---------- >> From: "Krzysztof Wesołowski" <[email protected]> >> To: Mailing list for lwIP users <[email protected]> >> Cc: >> Date: Wed, 1 Jan 2014 15:36:23 +0100 >> Subject: Re: [lwip-users] missing TX packets >> I dont know how MAC operates in this particular CHIP, but in STM32 you >> can select to either transmit frames directly from memory (using FIFO as >> temporary buffer) or in "store and forward" mode when complete frame is >> gatheren in FIFO and sent as a whole from FIFO. Maybe you have similar >> settings, and change to "more buffered mode" will be solution? have you >> checked underrun flags (if they are available) to detect if tihs is a >> source of problem? >> >> Regards, >> Krzysztof Wesolowski >> >> >> On Wed, Jan 1, 2014 at 8:13 AM, Lehel Benedek <[email protected]>wrote: >> >>> Hello, >>> >>> I'm using an SBC1788 board with an LPC1788 micro controller and >>> successfully implemented a web server based on lwIP v1.4.1 with FreeRTOS >>> v7.4.2. >>> I am using zero copy TX buffers located in the external SDRAM, the >>> performance is quite good (the webpage of 600KB (also buffered in the >>> external SDRAM) gets loaded up in less than 1sec), and was working >>> flawlessly, until I added emWin to the project. Using the embedded LCD >>> controller from the LPC1788 and the video buffers also located in the >>> external SDRAM I got also the LCD and touchscreen working, however I notice >>> that the web-server was no longer working. >>> After some debugging I found the following: >>> - the problem with the web-server is that some TX packets are not sent >>> out at all, although the frame transmission gets correctly called, so from >>> 100 packets only around 70-80 are sent out >>> - the only thing that will cause this problem is the LCD power control. >>> When I enable power to the LCD controller the problem is there, if I >>> disable power to the LCD controller it's gone. >>> >>> I'm guessing it could be a conflict between the Ethernet chip and LCD >>> controller both accessing the external SDRAM through DMA, but I have no >>> idea on how to proceed. >>> I tried different AHB matrix priority settings, without any success. >>> >>> Any thoughts on this? >>> >>> _______________________________________________ >>> 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
