[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] lwIP trouble
From: |
Slava Zilberfayn |
Subject: |
Re: [lwip-users] lwIP trouble |
Date: |
Tue, 26 Feb 2019 16:07:34 -0500 |
Hello all,
I've done some more testing with tcpecho example. When I set
chunk size to be less than the size of the tcpecho
packets, I get exactly the same failure during the second
call to netconn_write. When the packet size small than chunk
size it crashes fairly quickly. For example I set chunk size
to 400 in the tcpecho example and send 400 bytes packets to
it. Works fine.
If I start sending 401 bytes, it crashes fairly quickly.
There must me something wrong with my settings. Any
help would be appreciated.
Thanks, Slava
Monday, February 25, 2019, 9:30:28 PM, you wrote:
SZ> Hello Lwip-users,
SZ> I have a networked device that was running lwIP 1.4.1 in the
SZ> past, but now I'm upgrading it to 2.1.0. The reason for the
SZ> upgrade is that we have a bit of instability. I have
SZ> previously identified two bugs in 1.4.1 that we were hitting,
SZ> and applied fixes. But since we still have occasional faults,
SZ> I decided to upgrade. The application is an http_server that
SZ> uses netconn API.
SZ> Now, I have also upgraded the FreeRTOS, which went relatively
SZ> trouble free.
SZ> With lwIP I first hit the new #ifdef in
SZ> netconn_write_vectors_partly:
SZ> #if LWIP_SO_SNDTIMEO
SZ> if (conn->send_timeout != 0) {
SZ> dontblock = 1;
SZ> }
SZ> #endif /* LWIP_SO_SNDTIMEO */
SZ> if (dontblock && !bytes_written) {
SZ> /* This implies netconn_write() cannot be used for non-blocking send,
since
SZ> it has no way to return the number of bytes written. */
SZ> return ERR_VAL;
SZ> }
SZ> I was using netconn_write() macro, and so it was exiting
SZ> here with ERR_VAL.
SZ> I switched to netconn_write_partly() and it made things work,
SZ> sort of. I'm testing the access of a single file. It works
SZ> about 90% of the time, but the other 10% it explodes in a
SZ> strange way.
SZ> Here is the log file.
SZ> Netcnn a009879c
SZ> http_server_netconn_thread: Sending Message
SZ> Netcnn 2 a009879c
SZ> http_file_server: Processing Message
SZ> netconn_recv...
SZ> resource requested = '/s.xml'
SZ> tcp_write(), LR = 28a77
SZ> tcp_write(pcb=a0098eac, data=10003160, len=68,
SZ> apiflags=1)
SZ> tcp_write: queueing 1b1c:1b60
SZ> tcp_output_segment: 1b1c:1b60
SZ> XML Generated 2000 bytes
SZ> calling netconn_write_partly 36
SZ> tcp_write(), LR = 28a77
SZ> tcp_write(pcb=a0098eac, data=1000c2c0, len=1460,
SZ> apiflags=1)
SZ> tcp_write: queueing 1b60:2114
SZ> tcp_output_segment: 1b60:2114
SZ> calling netconn_write_partly 37
SZ> tcp_write(), LR = 28a7************tcp_write(), LR = 28a77
SZ> tcp_write(pcb=a0098eac, data=1000c874, len=540,
SZ> apiflags=1)
SZ> tcp_write: queueing 2114:2330
SZ> tcp_output_segment: 2114:2330
SZ> ************7
SZ> tcp_write(pcb=a0098eac, data=1000c874, len=540,
SZ> apiflags=1)
SZ> tcp_write: queueing 2330:254c
SZ> HARD FAULT
SZ> _CFSR 8200
SZ> _BFAR 18
SZ> LR 2022d
SZ>
SZ> I have added the ********* manually to demark the
SZ> intervening call. What I see is that in
SZ> the middle of the tcp_write execution another call of
SZ> tcp_write comes in with exactly the same parameters.
SZ> Presumably to send the same piece of data. I've added
SZ> printing LR register at the entry into tcp_write to see there
SZ> it is called from. Both calls come from the same location
SZ> (api_msg.c:1712). Now I'm kind out of ideas. Any pointers
SZ> where to look at would be appreciated.
SZ> attached are my config files.
SZ> Thank you, Slava
--
Slava Zilberfayn mailto:address@hidden
Phone: 416 7289367
Home Electronics, www.home-electro.com
100 Drumlin Circle,
Suite 205
Concord, ON, L4K 3E6
CANADA