[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-devel] TCP Client system fault
From: |
Vinicius Bernardi |
Subject: |
Re: [lwip-devel] TCP Client system fault |
Date: |
Wed, 25 Apr 2012 08:59:01 -0300 |
Hi All,
I finally found the reason about the TCP is receiving a corrupt package , I
will try to explain the process :
1 - I had writen some data using netconn_write
Then I had received a semaphore post saying that the TCPIP thread already
process that message
Then PPP thread receive a package (IP buffer) and process it, but during the
process of that package the code decide to call do_write method again ( it's
related to SEND EVENT about the message confirmed - previous message maybe )
With this new POST again at semaphore, my next write to netconn_write will be
out of sync, because I will not wait again, as my semaphore it's already 1 ,
and it will be released imediatly.
In my solution for now it's to remove the do_writemore inside of API to send
signal, as there is no sense to be there.
I would like some comments if it's possible.
Another important question :
I'm trying to write huge packages, 1600 bytes for example, how the
netconn_write should handle it? Right now, there is a output of 1400 bytes and
I receive ACK that everything it's ok, and it's not ok, there is a part of
package missing.
My best regards,
Vinicius
Em 14/04/2012, às 16:31, Vinicius Bernardi escreveu:
> Hi Everyone,
>
> I`m facing a issue that is very complex to understand how it's happening.
> The issue happens like this :
>
> I have a PPP connection + TCP Client, I keep just 1 client connection open.
> This connection can be used for many hours without any problem, sending and
> receiving packages.
> But if I decide to send a huge buffer (1400 bytes) with very short interval,
> as I receive the TCP ACK, I send a new one, the code is generating a system
> fault.
> I'm using a RTOS uC/OS-II port, and as I said it's working very well, even
> with Huge buffers in case that the interval it's bigger.
> I already increase STACK size, buffer's sizes, but as far as I don't know
> when the problem will happens, and sometimes it happnes in 50 seconds,
> sometimes with 300 seconds after I had start it, it's vey complex to
> understand why the system fault it`s cause by.
> The it`s always in the same state, and the data is 0x00000000.
> I'm using a Cortex M4.
> Does anybody have some clue, or additional information how can I debbug it,
> and get more information?
> I already have all the trace information enabled, and I didn't find a route
> cause, or a different sittuation inside the log.
>
> My best regards,
> Vinicius