• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 2088 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

lwip tcp issues with tcp_recved outside of receive function

Sean Bedford
Expert 1560 points

Good afternoon,

I am having an issue with flow control of tcp data being received by the am335x running lwip 1.4.1.  My code is based on the Starterware example only we are using sys/bios and I updated lwip to try and remedy this and a couple of other issues I saw.

Basically what I am doing is receiving data into the tcp_recv function which pushes the data into a thread safe buffer and frees the pbuf.  Then in another thread this data is pulled in chunks and written to file.

I then call tcp_recved() with the amount of data I have written. I checked nothing is over flowing and I tried just printing the window size and emptying the buffer without writing and its the same issue.  It takes a varied amount of time to happen.

However when I put the tcp_recved() in the tcp_recv() function and throttle the data by reducing the window sir or sending it slower it works?

Below is how it ends in wireshark with some duplicate acks then reporting window full, 195.0.0.133 is the lwip macine.

Has anybody seen anything similar or have any suggestions?

Thanks

Sean

  • 0
    Genius 5820 points

    I don't know if I fully understood it...but: tcp_recved() definitely has to be placed in your receive callback function. Or to be more generic: all lwIP functions (except the ones where you set up your callbacks) have to run in interrupt-context and are not allowed to be called somewhere from main function context.

  • 0 in reply to qxc
    Expert 1560 points

    Hi,

    Yes it does seem you are right but it is badly documented and quite a few examples seem to ignore it.

    Can you point to any good examples as to how I can initiate a chain of transfers and manage flow control inside the isr when it is dependent on a lower tasks read speed?

    Setting TCP_QUEUE_OOSEQ to 0 does seem to stop the issue but i would rather implement it properly.

    Kind regards

    Sean

  • 0 in reply to Sean Bedford
    Genius 5820 points
    I don't know of such examples, but the whole thing is not that complicated. OK, a bit complictated:

    In general you only would have to enqueue your data to be sent into some buffer/FIFO/ringbuffer/whatever. Then from within lwIP's poll-function you fetch these data and hand them over to the send-function. This works because the poll-function runs in ISR-context too.

    Now the bad news: in StarterWare's implementation the poll-function does not work, the related timers are not implemented. So you only have the chance to check during every reception of data if there are any to be sent too. This may need some changes in your protocol in order to have recv-function called regularly...