lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Binary file upload chrashes the program (lwip 1.4.1)


From: Noam Weissman
Subject: Re: [lwip-users] Binary file upload chrashes the program (lwip 1.4.1)
Date: Sun, 12 Feb 2017 16:02:32 +0000

Hi Szabolcs,

What do you mean complicated project ? .

I am using FreeRTOS + LwIP 1.41 under STM32F427 with SPL, no cubeMX !

My LwIP heap uses just 15K RAM and has the following:
mDNS responder, SDDP responder and a third private discovery module.
HTTP server, TCP server capable handling 3 connections, WSS client running in 
secure mode
and a WS server in none secure mode.

The WSS client is running with the Socket API while all the rest use the RAW 
API.

The above are just the TCP related modules. Beside that I have another 7 tasks.

If you have problems with LwIP it is from my experience due to not using it 
properly or not setting the 
FreeRTOS properly.


BR,
Noam.




-----Original Message-----
From: lwip-users [mailto:address@hidden On Behalf Of Vass Szabolcs
Sent: Friday, February 10, 2017 3:10 PM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] Binary file upload chrashes the program (lwip 1.4.1)

Thank You for Your response.

So I'm using the lwip 1.4.1 stack. To configure my controller I used the CubeMx 
from ST. The Cube Mx generated this library to my project (in 2016). I read 
that the ST is working on next upgrade of Cube Mx that will contain the lwip 
2.0.

The problem is that my project is very large and complex so I wouldn't like to 
exchange my lwip libraries.

In my project I need to modify in the lwip function to work properly the binary 
upload, and some other features.

So please help me where I can find the solution within this stack?

Kind regards,

Szabolcs



2017.02.10. 14:33 keltezéssel, Sergio R. Caprile írta:
> The crashes are your responsibility. Or your vendor's...
> If you clearly indicate which API are you using and how you use the 
> stack, someone here might guide you.
> The dup acks are indicating your lwIP is not seeing some expected 
> frames. This is usually a driver fault. Most common culprit is that 
> the developers forget to extract all frames off the eth chip when 
> handling a frame rx indication. When traffic is low, everything is 
> fine, but as soon as network traffic is high and two or more frames 
> arrive in the service period, one of them is left sleeping and 
> eventually lost. If that one which is lost is the one you care about, 
> the stack will ask for it again, and that is what you are seeing.
> Search the list, there's someone else with the very same problem this 
> week, and I bet is also ST-related. My bet is strong on the driver. I 
> just can't wait to be right...
>
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users


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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]