The LM3S6965 is still being manufactured, although it is not suggested for new designs. TI only recently came out with a ARM Cortex-M4 processor line with integrated MAC+PHY, which is why we are still using the LM3S6965.
Best regards, Element Green On Fri, Jan 10, 2014 at 5:22 AM, Alain Mouette <[email protected]> wrote: > Are you aware that there are no more Luminary chips??? > > Luminary was bought by Texas Instruments, which with caracteristic > customer care simply stopped producing it. > I am moving a product in production (gladly only one) to ST... > > I intend to use the external PHY from Microchip ENC424J600, but I asked > for help to find an LWIP driver but got no answer :( > > Alain > > Em 09-01-2014 02:45, Element Green escreveu: > > I wanted to add an update to this issue. By checking the interrupt status > in the Ethernet interrupt I confirmed that an RX FIFO overrun error was > indeed occurring with the HTTP POST request. It seems the LM3S6965 receive > FIFO is 2K. I think something else is going on though, because even after > adjusting the TCP_MSS to 960 and TCP_WND to 1920, there are still very long > delays (about 1.2 seconds) between the received packets and the ACKs sent > by the device running lwip. At least there aren't any dropped packets or > duplicate ACKs though. I've attached a new packet capture. > > This processor is running at 50MHz. One noteworthy thing is how the > lwip port related code is handling the Ethernet interrupt. It uses a Queue > to signal a FreeRTOS task when data is available from the Ethernet > interface. This task does the actual handling of the data received from > the Ethernet MAC. I scheduled this task as the highest priority one in the > system, but it doesn't seem to make a difference. The system is idle most > the time, so I can't see how task priority would account for 1.2 seconds of > ACK delay. > > I turned off the naggle algorithm with the HTTP listen port, not sure if > this also needs to be done with the accepted connections though. > > Best regards, > > Element Green > > > On Wed, Jan 8, 2014 at 5:12 PM, Element Green <[email protected] > > wrote: > >> I'm developing an application on the Stellaris LM3S6965 platform with >> lwip 1.4.1, FreeRTOS 7.5.2 and Stellarisware 10636. >> With a host Linux PC I'm sending a HTTP POST request (3011 byte payload) >> using wget connected to the target platform with a crossover cable. >> >> I've attached a wireshark capture of the strange behavior. It appears >> that 3 packets are sent from the HTTP post request without an ACK being >> sent by the lwip system, then several seconds later the host PC resends the >> first packet, some duplicate ACKs occur, etc. >> >> I wrote a more concise analysis of this before, but Nabble ate my >> message after I uploaded the capture file.. First and last time I'm using >> that. >> >> I did some debugging in the Ethernet interface driver receive function >> and it appears that not all of the packets are arriving. Anyone have any >> ideas where to go from here? I'm not very familiar with Ethernet hardware >> drivers, so I don't know how they buffer data and what would cause them to >> lose a packet. Could I decrease my WND size to try and fix this? >> >> Here are some of the TCP settings I have in my lwipopts.h file: >> //#define LWIP_TCP 1 >> //#define TCP_TTL (IP_DEFAULT_TTL) >> #define TCP_WND 4096 // default is 2048 >> //#define TCP_MAXRTX 12 >> //#define TCP_SYNMAXRTX 6 >> #define TCP_QUEUE_OOSEQ 1 >> #define TCP_MSS 1460 // default is 128 >> //#define TCP_CALCULATE_EFF_SEND_MSS 1 >> #define TCP_SND_BUF (2 * TCP_MSS) >> //#define TCP_SND_QUEUELEN (4 * (TCP_SND_BUF/TCP_MSS)) >> //#define TCP_SNDLOWAT (TCP_SND_BUF/2) >> //#define TCP_LISTEN_BACKLOG 0 >> //#define TCP_DEFAULT_LISTEN_BACKLOG 0xff >> >> Thanks in advance for any assistance. >> >> Element Green >> >> > > > _______________________________________________ > lwip-users mailing > [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
