Hi Sergio,
thanks for the help.
Sorry about the screenshot, didn't know about capture files :-)
I am using the 1.4.1 version on a microcontroller (RM57) without OS. We
would move to 2.0 only if we really need to.
And yes, I am calling sys_check_timeouts(), which calls the callback
function from the last post. No mix.
I didn't write the port. I got it online from a Texas Instruments
tutorial. I've tried the tcpecho_raw example and it worked ok, but I
wasn't sending 2k chunks of data.
I printed the statistics after an ERR_MEM. I got this:
LINK
xmit: 4775
recv: 3671
fw: 0
drop: 0
chkerr: 0
lenerr: 0
memerr: 0
rterr: 0
proterr: 0
opterr: 0
err: 0
cachehit: 0
ETHARP
xmit: 2
recv: 5
fw: 0
drop: 0
chkerr: 0
lenerr: 0
memerr: 0
rterr: 0
proterr: 0
opterr: 0
err: 0
cachehit: 4769
IP
xmit: 4770
recv: 3668
fw: 0
drop: 0
chkerr: 0
lenerr: 0
memerr: 0
rterr: 0
proterr: 0
opterr: 0
err: 0
cachehit: 0
TCP
xmit: 4770
recv: 3668
fw: 0
drop: 0
chkerr: 0
lenerr: 0
memerr: 1
rterr: 0
proterr: 0
opterr: 0
err: 0
cachehit: 3667
MEM HEAP
avail: 51200
used: 0 <<<<<<<<<<<<<< I guess I can set MEM_SIZE very low :-)
max: 240
err: 0
MEM TCP_PCB
avail: 4
used: 1
max: 1
err: 0
MEM TCP_PCB_LISTEN
avail: 8
used: 3
max: 3
err: 0
MEM TCP_SEG
avail: 48
used: 0
max: 3
err: 0
MEM SYS_TIMEOUT
avail: 10
used: 2
max: 3
err: 0
MEM PBUF_REF/ROM
avail: 4
used: 0
max: 4
err: 1
MEM PBUF_POOL
avail: 8
used: 8
max: 8
err: 5
SYS
sem.used: 0
sem.max: 0
sem.err: 0
mutex.used: 0
mutex.max: 0
mutex.err: 0
mbox.used: 0
mbox.max: 0
mbox.err: 0
I marked the three errors in the stats that I can see. I am guessing these are not the same error values from err.h?
The member 'avail' of some of the structs is higher that 'max'.
Is it safe to try to decrease the 'avail' value to match that of 'max'?
Or should I try to increase the value of 'MEM PBUF_POOL.avail'?
BTW, these stats are not from a 'just before crash' state. Sometimes I get an ERR_MEM but the communication keeps ongoing.
These stats are from one of those 'not so bad' errors.
Attached is the capture file from wireshark when the communication does break.
Thanks again,
Julio
Am 02.06.2017 um 15:11 schrieb Sergio R. Caprile:
> > Does anyone have any ideas?
>
> Yes!
>
> You said '1.4', is there another number after that ? You should move
> to at least 1.4.1 if somehow you can't go 2.0 (unless you are on a
> ESP8266...)
>
> Don't attach screen captures, do attach capture files. For instance, I
> can't see the frame numbers in your snapshot, nor if there is an
> invalid checksum.
>
> As you know, TCP needs the other end to ACK before it can send more.
> Those unsent frames are there in your memory waiting to be ACKed. You
> shouldn't be sending at will but after you know for sure what you've
> sent has been ACKed. You do this by registering a tcp_sent() callback.
> 50ms seems a long time, but it depends on what your port does. What do
> you have below lwIP ? Is it an OS ? Is it bare metal ?
> Are you calling sys_check_timeouts() ?
> You must call lwIP low-level functions from within the same context,
> all from ints or all from main, no mix. Are you ?
>
> Your driver needs to behave in order for the pbufs to be properly
> freed. Does it ?
>
> Have you tried running a working example to see if your port + driver
> works OK ?
>
> Have you tried enabling statistics ?
>
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
Mit freundlichen Grüßen
Götting KG
i.A. Julio Cesar Aguilar Zerpa
--
M.Sc. Julio Cesar Aguilar Zerpa
Forschung & Entwicklung
address@hidden
Tel. +49(0)-5136-8096-39
————————————————————
Götting KG
Celler Str. 5, D-31275 Lehrte/Röddensen
Geschäftsführer H.-H. Götting
HR A 31127 | Amtsgericht Hildesheim
Gerichtsstand Lehrte
USt.-Id. Nr. DE 115055039
USt.-Nr. 16-226-13403
Phone +49(0)-5136-8096-0
Fax +49(0)-5136-8096-80
address@hidden | www.goetting.de
————————————————————
capture_wireshark.pcapng