[lwip-users] (no subject)

80 views

Skip to first unread message

Funk, Artur

unread,

Mar 27, 2012, 9:45:33 AM3/27/12

to lwip-...@nongnu.org

I have a web interface on my device based on raw http server example. Now I wanted to use the web interface for firmware updates. So I’ve decided to receive firmware files and save these in a SPI flash first and do the update after the next power on.

The firmware receive function is based on “stm32 In application programming” example. It works fine while the device receive small binary files (11Kb). But since my real application has still about 130KB the upload is not possible. The connection will be always closed after several data packets. What I’ve seen is, when I just call websites, wireshark show no errors. By uploading of binary files they are many errors like

TCP Window Full
TCP Dup ACK

TCP Retransmission

And the upload fails with RST ACK from device even the file upload isn’t ready. Used LWIP Version is 1.3.0, raw http. The is debug output (But it’s not really helpful for me)

tcp_slowtmr: no active pcbs

TCP connection request TCP connection established est tcp_slowtmr: processing active pcb

tcp_recved: recveived

Octet_stream found

File Name: file.bin

TotalData 817 (135724)tcp_fasttmr: delayed ACK

tcp_slowtmr: processing active pcb

tcp_recved: recveived

TotalData 2277 (135724)tcp_recved: recveived

TotalData 3737 (135724)tcp_recved: recveived

TotalData 5197 (135724)tcp_fasttmr: delayed ACK

tcp_slowtmr: processing active pcb

tcp_recved: recveived

TotalData 6657 (135724)tcp_fasttmr: delayed ACK

tcp_slowtmr: processing active pcb

tcp_slowtmr: polling application

tcp_slowtmr: processing active pcb

tcp_recved: recveived

TotalData 8117 (135724)tcp_fasttmr: delayed ACK

tcp_slowtmr: processing active pcb

tcp_slowtmr: polling application

tcp_slowtmr: processing active pcb

tcp_recved: recveived

TotalData 9577 (135724)tcp_fasttmr: delayed ACK

tcp_slowtmr: processing active pcb

tcp_slowtmr: polling application

tcp_slowtmr: processing active pcb

tcp_recved: recveived

TotalData 11037 (135724)tcp_fasttmr: delayed ACK

tcp_recved: recveived

TotalData 12497 (135724)tcp_recved: recveived

TotalData 13957 (135724)tcp_recved: recveived

TotalData 15417 (135724)tcp_recved: recveived

TotalData 16877 (135724)tcp_recved: recveived

TotalData 18337 (135724)tcp_recved: recveived

TotalData 19797 (135724)tcp_fasttmr: delayed ACK

tcp_slowtmr: processing active pcb

tcp_recved: recveived

TotalData 21257 (135724)tcp_recved: recveived

TotalData 22717 (135724)tcp_recved: recveived

TotalData 24177 (135724)tcp_fasttmr: delayed ACK

tcp_slowtmr: processing active pcb

tcp_slowtmr: polling application

tcp_slowtmr: processing active pcb

tcp_recved: recveived

TotalData 25637 (135724)tcp_fasttmr: delayed ACK

tcp_slowtmr: processing active pcb

tcp_recved: recveived

TotalData 27097 (135724)tcp_fasttmr: delayed ACK

tcp_slowtmr: processing active pcb

tcp_slowtmr: polling application

tcp_recved: recveived

TotalData 28557 (135724)tcp_fasttmr: delayed ACK

tcp_slowtmr: processing active pcb

tcp_slowtmr: polling application

tcp_pcb_purge

tcp_slowtmr: no active pcbs

Any Ideas why file transfer doesn’t works properly?

Greets

Funk, Artur

unread,

Mar 28, 2012, 6:16:31 AM3/28/12

to Mailing list for lwIP users

Ohmmmm sorry, there is the file.
I've also checked LwIP TCP settings. I didn't notice anything unusual.

#define TCP_TTL 128
#define TCP_QUEUE_OOSEQ 0
#define TCP_MSS (1500 - 40)
#define TCP_SND_BUF (4 * TCP_MSS)
#define TCP_SND_QUEUELEN (6 * (TCP_SND_BUF)/TCP_MSS)
#define TCP_WND (4 * TCP_MSS)

PS: I've tested tftp upload from IAP Appnote. Tftp Upload works file,
the whole file was send successfully.

Greets

On 27 Mar 2012, at 14:45, Artur wrote:

> The firmware receive function is based on "stm32 In application
programming" example. It works fine while the device receive small
binary files (11Kb). But since my real application has still about 130KB
the upload is not possible. The connection will be always closed after
several data packets.

Do you have an example packet capture (e.g. from wireshark) showing the
problem?

Kieran
_______________________________________________
lwip-users mailing list
lwip-...@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users