lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] lwip-users Digest, Vol 125, Issue 1


From: Lehel Benedek
Subject: Re: [lwip-users] lwip-users Digest, Vol 125, Issue 1
Date: Thu, 2 Jan 2014 20:55:40 +0800

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, <address@hidden> wrote:
Send lwip-users mailing list submissions to
        address@hidden

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
        address@hidden

You can reach the person managing the list at
        address@hidden

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 <address@hidden>
To: address@hidden
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" <address@hidden>
To: Mailing list for lwIP users <address@hidden>
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 <address@hidden> 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
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users


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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]