[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] thread safe issue
From: |
Jonathan Larmour |
Subject: |
Re: [lwip-users] thread safe issue |
Date: |
Thu, 24 Jan 2008 19:42:01 +0000 |
User-agent: |
Thunderbird 1.5.0.12 (X11/20070530) |
Steve Waligurski wrote:
> Hi,
>
> I'm looking for some advice on an issue I'm seeing in the field with our
> new product which is running lwIP 1.10. Our platform is a Xilinx
> Spartan 3E running the Xilinx OS. The way our unit works is that when
> it boots up, it starts issuing UDP packets intended for a server running
> our application. As soon as the server receives one or more of these
> packets it makes a TCP connection with the device. This connection
> should stay up indefinitely but it doesn't. This is usually caused by
> a failure to respond to a command which causes the server to drop
> the connection. To make matters worse, randomly our device will not
> connect at all and must be power cycled before it will. Our EMAC core
> has been modified to block everything except our TCP packets and our
> ARP requests. 99% of communications starts with the server sending a
> packet and the device responding. In the other 1%, the device sends an
> asynchronous packet. Before doing this I disable the RX interrupt on
> the EMAC to avoid any thread issues. What I don't do though is disable
> the RX interrupt when sending out UDP packets after bootup which I do
> every 3 seconds. My question is, will I run into thread issue if the
> server tries to make a TCP connection at the exact same time the
> device is sending a UDP packet?
>From what you describe (that there is no protection in the stack when
interacting with the EMAC), yes any incoming packets or ARPs would be a
problem if so.
> Also, what happens if I'm transmitting
> a packet and an ARP request comes in? If I need to stop input packets
> during all transmissions, what is your recommendation on how I do this?
Upgrade to 1.3.0 ;).
Are you using the sequential API or sockets API? If so for 1.1.0 you may
want to use tcpip_callback() to invoke your packet processing so it happens
in the context of the tcpip thread. You have to make sure all packets,
including the calls to etharp_ip_input() and etharp_arp_input() happen in
the tcpip thread.
The vital thing is that no lwIP core code can be interrupted by any other
lwIP core code.
Jifl
--
eCosCentric Limited http://www.eCosCentric.com/ The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------ Opinions==mine