I also try to identify if it was a resend, so I added a counter to the
payload, but I haven't caught one fail since the modification last
Friday, because WireShark quit when this happened over the weekend.
Hopefully I can catch it soon
I am not using DMA and this one running on TI's TiVa
The
Hi,
I uses 1.41 as well... I did not find the function you use so I think what you
have is a variation of 1.41
I sent an email earlier that explains what to do but it looks that it was lost
???
Please send me your direct mail address and I will forward it to you again.
Follow my explanations
I missed your other post,
You shouldn't have threading issues with netconn, however, these can be
at a lower level, check how frames are dispatched, all calls to
low-level functions must be on the same thread (unless you clearly know
what you are doing)
Furthermore, now you say you are
Hi Julio,
To be honest I never used LwIP without OS I always use FreeRTOS. I hope I will
not make any errors in my replies.
Lets se...
To make it simpler to understand. Think on the following scenario... main has
some endless loop that does something...
Assume it is turning on/off a LED... so
It is not a matter of "compatibility" but doing things right or wrong,
you either do things the right way or you violate the rules of your
working environment.
If you are suspicious on printf(), then don't use it, your port should
have the correct output function and you should be able to ask
I see your out-of-order friend in frame #11 looks very much like frame
#8 revisited. I would say that is a DMA driver glitch (are you using DMA
?), however, the IP ID field is different, so it looks more like a
resend, due to frame #9 being internally lost; however, this does not
look
I think it is a problem with the printf function not being compatible with
FreeRTOS. Furthermore I think formating symbols are a problem. Normal char
are no problem.
Any suggestions how to fix that?
--
View this message in context:
Hi Noam,
thanks again for your help.
Which LwIP version do you have? The function 'tcp_new_ip_type' is just
another way to allocate a new tcp pcb (I use version 1.4.1). I don't
think that is the cause of the problem, though.
However, I did try it again with your init function and the
Hi,
As a continuation to my earlier mail...
Where do you call tcpServer_send ??
In tcpecho_raw_init function you call function tcp_new_ip_type I am not
familier with this function ?
My init function looks like this:
struct tcp_pcb *Listening_pcb; // is define static global
void
