http://lwip.100.n7.nabble.com/LwIP-tcp-output-Pcb-Corruption-td21239.html

Sponsored by Single Sushi - International dating that really workslwIP › lwip-usersLogin  Register

LwIP tcp_output Pcb Corruption

ClassicListThreaded5 messages  Options mary_westReply | Threaded | More Mar 22, 2013; 3:17am

LwIP tcp_output Pcb Corruption

3 postsHi - I'm having an lwip problem in tcp_output.  It hangs in the following ‘for’ loop. /* useg should point to last segment on unacked queue */  useg = pcb->unacked;  if (useg != NULL) {    for (; useg->next != NULL; useg = useg->next);  <------- here  }   Here's the background:  - processor: STM32F107vc  - lwip 1.4.0  - NO_SYS = 1  - using raw API  - ethernet set up on an interrupt using DMA  - ethernet driver is pulled from an STM32F107 Lwip application note and example code   The stm32 board sits between a device and a PC.  It receives CAN messages from  the device and sends them to the PC as tcp messages.  When the problem occurs,  the pcb is corrupted.  All ->nexts point to the same address.   I've read in the archive that this is due to the main and  interrupts using the lwip stack at the same time.  The main loop runs the tcp timers.  The interrupt calls ethernetif_input.   On the send side (where it fails), the main checks a CAN queue and if there are  messages, builds a tcpip msg and calls tcp_write followed by tcp_output.     The tcpip traffic going to the PC consists of MANY small packets.  I have disabled the  Nagle algorithm.   I read this in the archive as part of an answer to a question about a similar input problem:  "When running without an OS, you have to put new packets on a linked list that is processed  periodically from main() (just like the timers)."  Is this true for outgoing tcp packets?  What are the safeguards for protecting the pcb from corruption?  Any help would be appreciated.   Thanks-  Mary  
_______________________________________________ 
lwip-users mailing list 
[hidden email] 
https://lists.nongnu.org/mailman/listinfo/lwip-usersSimon GoldschmidtReply | Threaded | More Mar 22, 2013; 3:23am

Re: LwIP tcp_output Pcb Corruption

2729 posts [hidden email] wrote:

  I read this in the archive as part of an answer to a question about a similar input problem:  "When running without an OS, you have to put new packets on a linked list that is processed  periodically from main() (just like the timers)."  Is this true for outgoing tcp packets?

No, it means don't call ethernet_input from the interrupt but from the main loop, too.
Simon
_______________________________________________ 
lwip-users mailing list 
[hidden email] 
https://lists.nongnu.org/mailman/listinfo/lwip-usersmary_westReply | Threaded | More Mar 22, 2013; 4:16am

Re: LwIP tcp_output Pcb Corruption

3 postsHi – Thanks for the response.   Do I get rid of ETH_IRQHandler altogether?  It checks for input, calls ethernetif_input which calls low_level_input and ethernet_input (setup in netif_add) then clears the ETH_DMAs.  Do I move this all to the main loop? Thanks in advance-Mary From: lwip-users-bounces+mary_west=[hidden email] [mailto:lwip-users-bounces+mary_west=[hidden email]] On Behalf Of Simon Goldschmidt
Sent: Thursday, March 21, 2013 12:24 PM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] LwIP tcp_output Pcb Corruption  [hidden email] wrote:

   I read this in the archive as part of an answer to a question about a similar input problem:  "When running without an OS, you have to put new packets on a linked list that is processed  periodically from main() (just like the timers)."  Is this true for outgoing tcp packets?

 No, it means don't call ethernet_input from the interrupt but from the main loop, too. Simon
_______________________________________________ 
lwip-users mailing list 
[hidden email] 
https://lists.nongnu.org/mailman/listinfo/lwip-usersmary_westReply | Threaded | More Mar 22, 2013; 5:56am

Re: LwIP tcp_output Pcb Corruption

3 postsIn reply to this post by Simon GoldschmidtOk – nevermind last email.  I need the ETH IRQ handler.  In there, I load an application list (not an LwIP pbuf) with the received ETH packet and clear the ETHDMA bits to get the next interrupt.  In main, I get the packet out of the list and call ethernet_input to have LwIP handle it.  Is this how it should be done to avoid problems in tcp_output? Thanks-Mary From: lwip-users-bounces+mary_west=[hidden email] [mailto:lwip-users-bounces+mary_west=[hidden email]] On Behalf Of Simon Goldschmidt
Sent: Thursday, March 21, 2013 12:24 PM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] LwIP tcp_output Pcb Corruption  [hidden email] wrote:

   I read this in the archive as part of an answer to a question about a similar input problem:  "When running without an OS, you have to put new packets on a linked list that is processed  periodically from main() (just like the timers)."  Is this true for outgoing tcp packets?

 No, it means don't call ethernet_input from the interrupt but from the main loop, too. Simon
_______________________________________________ 
lwip-users mailing list 
[hidden email] 
https://lists.nongnu.org/mailman/listinfo/lwip-usersSimon GoldschmidtReply | Threaded | More Mar 22, 2013; 2:54pm

Re: LwIP tcp_output Pcb Corruption

2729 posts[hidden email] wrote: 
> Ok – nevermind last email.  I need the ETH IRQ handler.  In there, I load an 
> application list (not an LwIP pbuf) with the received ETH packet and clear the 
> ETHDMA bits to get the next interrupt.  In main, I get the packet out of the 
> list and call ethernet_input to have LwIP handle it.  Is this how it should be 
> done to avoid problems in tcp_output? 

Yes. This is one way to do it. You are essentially free to chose any way that makes sure the core lwIP code (except for allocating/freeing PBUF_POOL pbufs and other memp-memory) is not exposed to concurrent execution (i.e. executed from main and ISR at the same time). 

Simon 

_______________________________________________ 
lwip-users mailing list 
[hidden email] 
https://lists.nongnu.org/mailman/listinfo/lwip-users« Return to lwip-users  |  371 viewsFree forum by NabbleDisable Popup Ads | Edit this page