Binary file upload chrashes the program (lwip 1.4.1)

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Binary file upload chrashes the program (lwip 1.4.1)

Vass Szabolcs

Hello,

I'm working on a webserver application, and I use the lwip 1.4.1 tcp/ip stack. I'm working on STM32F407 device. I implemented the binary file upload, but sometimes when I try to upload the files, get TCP retransmission and TCP Dup Ack error on network capture. Sometimes the file upload was succesfully and somtimes wasn't. Can You tell me somebody why it's caused? I didn't find the right solution up to now.

The two captures(one when the upload was succesfully, one when wasn't) is available at this link.

https://we.tl/BYayHqMAEV

Please use the following filter to see the captures between my PC and my device: ip.addr == 192.168.0.23

Please help me. Kind regards, Szabolcs


_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Binary file upload chrashes the program (lwip 1.4.1)

Sergio R. Caprile
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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Binary file upload chrashes the program (lwip 1.4.1)

Vass Szabolcs
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
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/lwip-users


_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Binary file upload chrashes the program (lwip 1.4.1)

Jens Nielsen
Hi

Which version of CubeMx? And are you using their ethernetif.c or did you
get it somewhere else? I don't remember when it was fixed but old
versions had the exact problem Sergio mentioned. Search for anything
related to ST from a couple of years ago and you'll definitely find it

BR /Jens


On 2017-02-10 14:09, Vass Szabolcs wrote:

> 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
>> [hidden email]
>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
>
> _______________________________________________
> lwip-users mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/lwip-users


_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Binary file upload chrashes the program (lwip 1.4.1)

Sergio R. Caprile
In reply to this post by Sergio R. Caprile
What your vendor offers belongs to your vendor, you should ask them for
support.
lwIP has several APIs, most of us can only help at the API level;
although if you are lucky you'll find a fellow advocate who can guide
you through your vendor nightmare. I still think your vendor's forums
are a better place to get help faster.


_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Binary file upload chrashes the program (lwip 1.4.1)

Noam weissman
In reply to this post by Vass Szabolcs
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:lwip-users-bounces+noam=[hidden email]] 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
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/lwip-users


_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Binary file upload chrashes the program (lwip 1.4.1)

Vass Szabolcs
Hello,

@Mr. Nielsen: I don't remember which version of Cube Mx was used when I
generated the project. Honestly it was a long time ago, and I used to
download frequently the latest updates. But I know that version
contained only the lwip 1.4 stack. I'm using their ethernetif.c

@Mr. Weissmann: Under complicated project I understand that I
implemented a http webserver using Raw API. It's running on a device,
that have another complex features that I can't share with You, because
these are company secrets. I hope You understand me and You aren't mad
at me.
I think that the problem is coming two possible way:

                 - the generated lwip library contains these bugs

                 - I'm not using the lwip functions properly


Is helping if I attach the lwip library compressed to a zip file and the
http functions that I implemented for uploading binary files?'

I think that this forum only the right place where I can get the right
answers and helps from You, because You developed these stack and You
are experts in this area. ST and other vendors just are using Your
stack, sometimes add some functionality to them, but You are who
understand deeply.

I'm sure that if I write to their forums they send to You (and I think
that it is correct), because this area isn't their area, and You are the
lwip developers.

Please help me, to get the right solution together.

Than You so much.

Sincerely,

Szabolcs



2017.02.12. 18:02 keltezéssel, Noam Weissman írta:

> 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:lwip-users-bounces+noam=[hidden email]] 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
>> [hidden email]
>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
> _______________________________________________
> lwip-users mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
> _______________________________________________
> lwip-users mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/lwip-users


_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Binary file upload chrashes the program (lwip 1.4.1)

Noam weissman
Hi Szabolcs,

Sure I am ok :-),  we are all developers here.

RAW API is very tricky. If you only use RAW API you cannot call any LwIP functions from outside the TCP stack context !.
If you call any LwIP functions in another task without protection or not as it was designed it may crash, you may get
Memory allocation errors etc...

On other thing to pay attention that is not so obvious is Cortex-M interrupts handling and FreeRTOS.

If you took an ST project and this is from the last year or something you are probably ok if you have not changed the interrupts
Priority levels. If you did you must check your code again. This is a problem that many do not pay attention. Let me explain.

FreeRTOS uses a time tick interrupt. It also uses code to protect critical sections. Critical section means that portion of the
code will mask interrupts that have a LOWER interrupt priority.

** In FreeRTOS a higher number means higher interrupt level.
*** in Cortext-M a lower interrupt level number means a higher priority !!

If the RTOS tick has interrupt priority 5, any other interrupt that is set lower than 5 will not be masked if a critical section is
handled. As a result you get instability issues that are very difficult to debug.

Take a look at the following code, part of FreeRTOSConfig.h:

#define IRQ_SYS_PRIORITY_MODEL  NVIC_PriorityGroup_4

/* Cortex-M specific definitions. */
#ifdef __NVIC_PRIO_BITS
        /* __BVIC_PRIO_BITS will be specified when CMSIS is being used. */
        #define configPRIO_BITS       __NVIC_PRIO_BITS
#else
        #define configPRIO_BITS       4        /* 15 priority levels */
#endif

/* The lowest interrupt priority that can be used in a call to a "set priority"
function. */
#define configLIBRARY_LOWEST_INTERRUPT_PRIORITY 0xF

/* The highest interrupt priority that can be used by any interrupt service
routine that makes calls to interrupt safe FreeRTOS API functions.  DO NOT CALL
INTERRUPT SAFE FREERTOS API FUNCTIONS FROM ANY INTERRUPT THAT HAS A HIGHER
PRIORITY THAN THIS! (higher priorities are lower numeric values. */
#define configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY 5

/* Interrupt priorities used by the kernel port layer itself.  These are generic
to all Cortex-M ports, and do not rely on any particular library functions. */
#define configKERNEL_INTERRUPT_PRIORITY ( configLIBRARY_LOWEST_INTERRUPT_PRIORITY << (8 - configPRIO_BITS) )
/* !!!! configMAX_SYSCALL_INTERRUPT_PRIORITY must not be set to zero !!!!
See http://www.FreeRTOS.org/RTOS-Cortex-M3-M4.html. */
#define configMAX_SYSCALL_INTERRUPT_PRIORITY ( configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY << (8 - configPRIO_BITS) )


#define ADC3_DMA_ISR_PRIO      (configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY + 6)
#define ETH_ISR_PRIO           (configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY + 5)
#define IR_TIMERS_ISR_PRIO     (configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY + 2)
#define SERIAL_ISR_PRIO        (configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY + 1)

-----------------------------------------------------------------------------------------------------------------------------------------------------

The RTOS priority level is configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY ... while ETH and all other hardware interrupts are set at
a higher number ( lower priority )

If your system is not set like this you must change it. !!!

-------------------------------------------------------------------------

Secondly if you need to send data over TCP outside of the LwIP context you must pay special attention to it.

The designed (correct) way to do it is create a call back function that is called from within the LwIP context.
This is done by using this function:  tcpip_callback(function, ctx);

Function is your own call back while ctx is your own argument. Here is a a portion of my code that uses this,
This function is my call back, part of my code:

//typedef void (*tcpip_callback_fn)(void *ctx);
static void TcpUdpSendToRemote_Write(void *Data)
{
  TcpUdpConData_t *pTcpUdpConData = (TcpUdpConData_t*)Data;
  err_t err;
 
  TCPUDP_SND_DIAG("From TcpUdpSendToRemote_Write: pcb->state = %s\r\n", StatStr[pTcpUdpConData->tcp_pcb->state]);
   
  err = tcp_write(pTcpUdpConData->tcp_pcb, pTcpUdpConData->RmSavedMessage.Command, pTcpUdpConData->RmSavedMessage.CommandLen, 0);
   
  if(err == ERR_OK)
  {
    tcp_output(pTcpUdpConData->tcp_pcb);  
  }
  else
  {    
    TCPUDP_SND_DIAG("From TcpUdpSendToRemote_Write: tcp_write returned err = %0X\r\n", err);
   
    TcpUdpSendToRemote_Close(pTcpUdpConData->tcp_pcb);
   
    pTcpUdpConData->tcp_pcb = NULL;
  }
}  
 

This is how the above is added to the LwIP handling queue:
tcpip_callback(TcpUdpSendToRemote_Write, pTcpUdpConData);


This way LwIP calls user function from within LwIP context.


The above is the recommended way to do it. I hope this helped :-)

BR,
Noam.


-----Original Message-----
From: lwip-users [mailto:lwip-users-bounces+noam=[hidden email]] On Behalf Of Vass Szabolcs
Sent: Monday, February 13, 2017 9:51 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] Binary file upload chrashes the program (lwip 1.4.1)

Hello,

@Mr. Nielsen: I don't remember which version of Cube Mx was used when I generated the project. Honestly it was a long time ago, and I used to download frequently the latest updates. But I know that version contained only the lwip 1.4 stack. I'm using their ethernetif.c

@Mr. Weissmann: Under complicated project I understand that I implemented a http webserver using Raw API. It's running on a device, that have another complex features that I can't share with You, because these are company secrets. I hope You understand me and You aren't mad at me.
I think that the problem is coming two possible way:

                 - the generated lwip library contains these bugs

                 - I'm not using the lwip functions properly


Is helping if I attach the lwip library compressed to a zip file and the http functions that I implemented for uploading binary files?'

I think that this forum only the right place where I can get the right answers and helps from You, because You developed these stack and You are experts in this area. ST and other vendors just are using Your stack, sometimes add some functionality to them, but You are who understand deeply.

I'm sure that if I write to their forums they send to You (and I think that it is correct), because this area isn't their area, and You are the lwip developers.

Please help me, to get the right solution together.

Than You so much.

Sincerely,

Szabolcs



2017.02.12. 18:02 keltezéssel, Noam Weissman írta:

> 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:lwip-users-bounces+noam=[hidden email]]
> 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
>> [hidden email]
>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
> _______________________________________________
> lwip-users mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
> _______________________________________________
> lwip-users mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/lwip-users


_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Binary file upload chrashes the program (lwip 1.4.1)

Noam weissman
Hi Szabolcs,

There is an error in my previous mail that may confuse... for some reason the CRLF was deleted...

//typedef void (*tcpip_callback_fn)(void *ctx);

static void TcpUdpSendToRemote_Write(void *Data)
{
  TcpUdpConData_t *pTcpUdpConData = (TcpUdpConData_t*)Data;
  err_t err;
 
  TCPUDP_SND_DIAG("From TcpUdpSendToRemote_Write: pcb->state = %s\r\n", StatStr[pTcpUdpConData->tcp_pcb->state]);
   
  err = tcp_write(pTcpUdpConData->tcp_pcb, pTcpUdpConData->RmSavedMessage.Command, pTcpUdpConData->RmSavedMessage.CommandLen, 0);
   
  if(err == ERR_OK)
  {
    tcp_output(pTcpUdpConData->tcp_pcb);
  }
  else
  {    
    TCPUDP_SND_DIAG("From TcpUdpSendToRemote_Write: tcp_write returned err = %0X\r\n", err);
   
    TcpUdpSendToRemote_Close(pTcpUdpConData->tcp_pcb);
   
    pTcpUdpConData->tcp_pcb = NULL;
  }
}


BR,
Noam.

-----Original Message-----
From: lwip-users [mailto:lwip-users-bounces+noam=[hidden email]] On Behalf Of Noam Weissman
Sent: Monday, February 13, 2017 10:28 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] Binary file upload chrashes the program (lwip 1.4.1)

Hi Szabolcs,

Sure I am ok :-),  we are all developers here.

RAW API is very tricky. If you only use RAW API you cannot call any LwIP functions from outside the TCP stack context !.
If you call any LwIP functions in another task without protection or not as it was designed it may crash, you may get Memory allocation errors etc...

On other thing to pay attention that is not so obvious is Cortex-M interrupts handling and FreeRTOS.

If you took an ST project and this is from the last year or something you are probably ok if you have not changed the interrupts Priority levels. If you did you must check your code again. This is a problem that many do not pay attention. Let me explain.

FreeRTOS uses a time tick interrupt. It also uses code to protect critical sections. Critical section means that portion of the code will mask interrupts that have a LOWER interrupt priority.

** In FreeRTOS a higher number means higher interrupt level.
*** in Cortext-M a lower interrupt level number means a higher priority !!

If the RTOS tick has interrupt priority 5, any other interrupt that is set lower than 5 will not be masked if a critical section is handled. As a result you get instability issues that are very difficult to debug.

Take a look at the following code, part of FreeRTOSConfig.h:

#define IRQ_SYS_PRIORITY_MODEL  NVIC_PriorityGroup_4

/* Cortex-M specific definitions. */
#ifdef __NVIC_PRIO_BITS
        /* __BVIC_PRIO_BITS will be specified when CMSIS is being used. */
        #define configPRIO_BITS       __NVIC_PRIO_BITS
#else
        #define configPRIO_BITS       4        /* 15 priority levels */
#endif

/* The lowest interrupt priority that can be used in a call to a "set priority"
function. */
#define configLIBRARY_LOWEST_INTERRUPT_PRIORITY 0xF

/* The highest interrupt priority that can be used by any interrupt service routine that makes calls to interrupt safe FreeRTOS API functions.  DO NOT CALL INTERRUPT SAFE FREERTOS API FUNCTIONS FROM ANY INTERRUPT THAT HAS A HIGHER PRIORITY THAN THIS! (higher priorities are lower numeric values. */
#define configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY 5

/* Interrupt priorities used by the kernel port layer itself.  These are generic to all Cortex-M ports, and do not rely on any particular library functions. */
#define configKERNEL_INTERRUPT_PRIORITY ( configLIBRARY_LOWEST_INTERRUPT_PRIORITY << (8 - configPRIO_BITS) )
/* !!!! configMAX_SYSCALL_INTERRUPT_PRIORITY must not be set to zero !!!!
See http://www.FreeRTOS.org/RTOS-Cortex-M3-M4.html. */
#define configMAX_SYSCALL_INTERRUPT_PRIORITY ( configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY << (8 - configPRIO_BITS) )


#define ADC3_DMA_ISR_PRIO      (configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY + 6)
#define ETH_ISR_PRIO           (configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY + 5)
#define IR_TIMERS_ISR_PRIO     (configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY + 2)
#define SERIAL_ISR_PRIO        (configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY + 1)

-----------------------------------------------------------------------------------------------------------------------------------------------------

The RTOS priority level is configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY ... while ETH and all other hardware interrupts are set at
a higher number ( lower priority )

If your system is not set like this you must change it. !!!

-------------------------------------------------------------------------

Secondly if you need to send data over TCP outside of the LwIP context you must pay special attention to it.

The designed (correct) way to do it is create a call back function that is called from within the LwIP context.
This is done by using this function:  tcpip_callback(function, ctx);

Function is your own call back while ctx is your own argument. Here is a a portion of my code that uses this, This function is my call back, part of my code:

//typedef void (*tcpip_callback_fn)(void *ctx); static void TcpUdpSendToRemote_Write(void *Data) {
  TcpUdpConData_t *pTcpUdpConData = (TcpUdpConData_t*)Data;
  err_t err;
 
  TCPUDP_SND_DIAG("From TcpUdpSendToRemote_Write: pcb->state = %s\r\n", StatStr[pTcpUdpConData->tcp_pcb->state]);
   
  err = tcp_write(pTcpUdpConData->tcp_pcb, pTcpUdpConData->RmSavedMessage.Command, pTcpUdpConData->RmSavedMessage.CommandLen, 0);
   
  if(err == ERR_OK)
  {
    tcp_output(pTcpUdpConData->tcp_pcb);
  }
  else
  {    
    TCPUDP_SND_DIAG("From TcpUdpSendToRemote_Write: tcp_write returned err = %0X\r\n", err);
   
    TcpUdpSendToRemote_Close(pTcpUdpConData->tcp_pcb);
   
    pTcpUdpConData->tcp_pcb = NULL;
  }
}  
 

This is how the above is added to the LwIP handling queue:
tcpip_callback(TcpUdpSendToRemote_Write, pTcpUdpConData);


This way LwIP calls user function from within LwIP context.


The above is the recommended way to do it. I hope this helped :-)

BR,
Noam.


-----Original Message-----
From: lwip-users [mailto:lwip-users-bounces+noam=[hidden email]] On Behalf Of Vass Szabolcs
Sent: Monday, February 13, 2017 9:51 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] Binary file upload chrashes the program (lwip 1.4.1)

Hello,

@Mr. Nielsen: I don't remember which version of Cube Mx was used when I generated the project. Honestly it was a long time ago, and I used to download frequently the latest updates. But I know that version contained only the lwip 1.4 stack. I'm using their ethernetif.c

@Mr. Weissmann: Under complicated project I understand that I implemented a http webserver using Raw API. It's running on a device, that have another complex features that I can't share with You, because these are company secrets. I hope You understand me and You aren't mad at me.
I think that the problem is coming two possible way:

                 - the generated lwip library contains these bugs

                 - I'm not using the lwip functions properly


Is helping if I attach the lwip library compressed to a zip file and the http functions that I implemented for uploading binary files?'

I think that this forum only the right place where I can get the right answers and helps from You, because You developed these stack and You are experts in this area. ST and other vendors just are using Your stack, sometimes add some functionality to them, but You are who understand deeply.

I'm sure that if I write to their forums they send to You (and I think that it is correct), because this area isn't their area, and You are the lwip developers.

Please help me, to get the right solution together.

Than You so much.

Sincerely,

Szabolcs



2017.02.12. 18:02 keltezéssel, Noam Weissman írta:

> 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:lwip-users-bounces+noam=[hidden email]]
> 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
>> [hidden email]
>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
> _______________________________________________
> lwip-users mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
> _______________________________________________
> lwip-users mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/lwip-users


_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Binary file upload chrashes the program (lwip 1.4.1)

Vass Szabolcs
Thank You Mr. Weissman, but I don't use FreeRTOS, I use only RAW API.

Can You help me that in this case what can I do?

Sincerely,

Szabolcs


2017.02.13. 11:11 keltezéssel, Noam Weissman írta:

> Hi Szabolcs,
>
> There is an error in my previous mail that may confuse... for some reason the CRLF was deleted...
>
> //typedef void (*tcpip_callback_fn)(void *ctx);
>
> static void TcpUdpSendToRemote_Write(void *Data)
> {
>    TcpUdpConData_t *pTcpUdpConData = (TcpUdpConData_t*)Data;
>    err_t err;
>    
>    TCPUDP_SND_DIAG("From TcpUdpSendToRemote_Write: pcb->state = %s\r\n", StatStr[pTcpUdpConData->tcp_pcb->state]);
>      
>    err = tcp_write(pTcpUdpConData->tcp_pcb, pTcpUdpConData->RmSavedMessage.Command, pTcpUdpConData->RmSavedMessage.CommandLen, 0);
>    
>    if(err == ERR_OK)
>    {
>      tcp_output(pTcpUdpConData->tcp_pcb);
>    }
>    else
>    {
>      TCPUDP_SND_DIAG("From TcpUdpSendToRemote_Write: tcp_write returned err = %0X\r\n", err);
>      
>      TcpUdpSendToRemote_Close(pTcpUdpConData->tcp_pcb);
>      
>      pTcpUdpConData->tcp_pcb = NULL;
>    }
> }
>
>
> BR,
> Noam.
>
> -----Original Message-----
> From: lwip-users [mailto:lwip-users-bounces+noam=[hidden email]] On Behalf Of Noam Weissman
> Sent: Monday, February 13, 2017 10:28 AM
> To: Mailing list for lwIP users
> Subject: Re: [lwip-users] Binary file upload chrashes the program (lwip 1.4.1)
>
> Hi Szabolcs,
>
> Sure I am ok :-),  we are all developers here.
>
> RAW API is very tricky. If you only use RAW API you cannot call any LwIP functions from outside the TCP stack context !.
> If you call any LwIP functions in another task without protection or not as it was designed it may crash, you may get Memory allocation errors etc...
>
> On other thing to pay attention that is not so obvious is Cortex-M interrupts handling and FreeRTOS.
>
> If you took an ST project and this is from the last year or something you are probably ok if you have not changed the interrupts Priority levels. If you did you must check your code again. This is a problem that many do not pay attention. Let me explain.
>
> FreeRTOS uses a time tick interrupt. It also uses code to protect critical sections. Critical section means that portion of the code will mask interrupts that have a LOWER interrupt priority.
>
> ** In FreeRTOS a higher number means higher interrupt level.
> *** in Cortext-M a lower interrupt level number means a higher priority !!
>
> If the RTOS tick has interrupt priority 5, any other interrupt that is set lower than 5 will not be masked if a critical section is handled. As a result you get instability issues that are very difficult to debug.
>
> Take a look at the following code, part of FreeRTOSConfig.h:
>
> #define IRQ_SYS_PRIORITY_MODEL  NVIC_PriorityGroup_4
>
> /* Cortex-M specific definitions. */
> #ifdef __NVIC_PRIO_BITS
> /* __BVIC_PRIO_BITS will be specified when CMSIS is being used. */
> #define configPRIO_BITS       __NVIC_PRIO_BITS
> #else
> #define configPRIO_BITS       4        /* 15 priority levels */
> #endif
>
> /* The lowest interrupt priority that can be used in a call to a "set priority"
> function. */
> #define configLIBRARY_LOWEST_INTERRUPT_PRIORITY 0xF
>
> /* The highest interrupt priority that can be used by any interrupt service routine that makes calls to interrupt safe FreeRTOS API functions.  DO NOT CALL INTERRUPT SAFE FREERTOS API FUNCTIONS FROM ANY INTERRUPT THAT HAS A HIGHER PRIORITY THAN THIS! (higher priorities are lower numeric values. */
> #define configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY 5
>
> /* Interrupt priorities used by the kernel port layer itself.  These are generic to all Cortex-M ports, and do not rely on any particular library functions. */
> #define configKERNEL_INTERRUPT_PRIORITY ( configLIBRARY_LOWEST_INTERRUPT_PRIORITY << (8 - configPRIO_BITS) )
> /* !!!! configMAX_SYSCALL_INTERRUPT_PRIORITY must not be set to zero !!!!
> See http://www.FreeRTOS.org/RTOS-Cortex-M3-M4.html. */
> #define configMAX_SYSCALL_INTERRUPT_PRIORITY ( configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY << (8 - configPRIO_BITS) )
>
>
> #define ADC3_DMA_ISR_PRIO      (configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY + 6)
> #define ETH_ISR_PRIO           (configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY + 5)
> #define IR_TIMERS_ISR_PRIO     (configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY + 2)
> #define SERIAL_ISR_PRIO        (configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY + 1)
>
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
> The RTOS priority level is configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY ... while ETH and all other hardware interrupts are set at
> a higher number ( lower priority )
>
> If your system is not set like this you must change it. !!!
>
> -------------------------------------------------------------------------
>
> Secondly if you need to send data over TCP outside of the LwIP context you must pay special attention to it.
>
> The designed (correct) way to do it is create a call back function that is called from within the LwIP context.
> This is done by using this function:  tcpip_callback(function, ctx);
>
> Function is your own call back while ctx is your own argument. Here is a a portion of my code that uses this, This function is my call back, part of my code:
>
> //typedef void (*tcpip_callback_fn)(void *ctx); static void TcpUdpSendToRemote_Write(void *Data) {
>    TcpUdpConData_t *pTcpUdpConData = (TcpUdpConData_t*)Data;
>    err_t err;
>    
>    TCPUDP_SND_DIAG("From TcpUdpSendToRemote_Write: pcb->state = %s\r\n", StatStr[pTcpUdpConData->tcp_pcb->state]);
>      
>    err = tcp_write(pTcpUdpConData->tcp_pcb, pTcpUdpConData->RmSavedMessage.Command, pTcpUdpConData->RmSavedMessage.CommandLen, 0);
>    
>    if(err == ERR_OK)
>    {
>      tcp_output(pTcpUdpConData->tcp_pcb);
>    }
>    else
>    {
>      TCPUDP_SND_DIAG("From TcpUdpSendToRemote_Write: tcp_write returned err = %0X\r\n", err);
>      
>      TcpUdpSendToRemote_Close(pTcpUdpConData->tcp_pcb);
>      
>      pTcpUdpConData->tcp_pcb = NULL;
>    }
> }
>  
>
> This is how the above is added to the LwIP handling queue:
> tcpip_callback(TcpUdpSendToRemote_Write, pTcpUdpConData);
>
>
> This way LwIP calls user function from within LwIP context.
>
>
> The above is the recommended way to do it. I hope this helped :-)
>
> BR,
> Noam.
>
>
> -----Original Message-----
> From: lwip-users [mailto:lwip-users-bounces+noam=[hidden email]] On Behalf Of Vass Szabolcs
> Sent: Monday, February 13, 2017 9:51 AM
> To: Mailing list for lwIP users
> Subject: Re: [lwip-users] Binary file upload chrashes the program (lwip 1.4.1)
>
> Hello,
>
> @Mr. Nielsen: I don't remember which version of Cube Mx was used when I generated the project. Honestly it was a long time ago, and I used to download frequently the latest updates. But I know that version contained only the lwip 1.4 stack. I'm using their ethernetif.c
>
> @Mr. Weissmann: Under complicated project I understand that I implemented a http webserver using Raw API. It's running on a device, that have another complex features that I can't share with You, because these are company secrets. I hope You understand me and You aren't mad at me.
> I think that the problem is coming two possible way:
>
>                   - the generated lwip library contains these bugs
>
>                   - I'm not using the lwip functions properly
>
>
> Is helping if I attach the lwip library compressed to a zip file and the http functions that I implemented for uploading binary files?'
>
> I think that this forum only the right place where I can get the right answers and helps from You, because You developed these stack and You are experts in this area. ST and other vendors just are using Your stack, sometimes add some functionality to them, but You are who understand deeply.
>
> I'm sure that if I write to their forums they send to You (and I think that it is correct), because this area isn't their area, and You are the lwip developers.
>
> Please help me, to get the right solution together.
>
> Than You so much.
>
> Sincerely,
>
> Szabolcs
>
>
>
> 2017.02.12. 18:02 keltezéssel, Noam Weissman írta:
>> 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:lwip-users-bounces+noam=[hidden email]]
>> 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
>>> [hidden email]
>>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>> _______________________________________________
>> lwip-users mailing list
>> [hidden email]
>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>>
>> _______________________________________________
>> lwip-users mailing list
>> [hidden email]
>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
> _______________________________________________
> lwip-users mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
> _______________________________________________
> lwip-users mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
> _______________________________________________
> lwip-users mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/lwip-users


_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Binary file upload chrashes the program (lwip 1.4.1)

Noam weissman
Hi Szabolcs,

I have never worked without an OS in TCP so I am a bit out of the loop here...

I can give you some suggestions but those will not come from experience
so I think you better ask someone that did something similar.

First I think that TCP interrupt should be the highest priority.
Secondly if you send data from outside the context of LWIP you must use the method
I explained or mask interrupts on critical sections.

Lets assume you have a UART getting data over RS232 and want to send it via TCP. You have
an interrupt handler for RS232 that collects data and then tries to call lwip_write or something.

Calling an LWIP function means outside of TCP context. This may lead to unpredictable results
as TCP interrupt is higher.

In order to overcome this you either use the method I showed you or something like this:

Mask_isr()
{
   Do something here ... call tcp_write(...)

}
UnMask_isr()



Hope that helped.

BR,
Noam.

-----Original Message-----
From: lwip-users [mailto:lwip-users-bounces+noam=[hidden email]] On Behalf Of Vass Szabolcs
Sent: Tuesday, February 14, 2017 9:45 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] Binary file upload chrashes the program (lwip 1.4.1)

Thank You Mr. Weissman, but I don't use FreeRTOS, I use only RAW API.

Can You help me that in this case what can I do?

Sincerely,

Szabolcs


2017.02.13. 11:11 keltezéssel, Noam Weissman írta:

> Hi Szabolcs,
>
> There is an error in my previous mail that may confuse... for some reason the CRLF was deleted...
>
> //typedef void (*tcpip_callback_fn)(void *ctx);
>
> static void TcpUdpSendToRemote_Write(void *Data) {
>    TcpUdpConData_t *pTcpUdpConData = (TcpUdpConData_t*)Data;
>    err_t err;
>    
>    TCPUDP_SND_DIAG("From TcpUdpSendToRemote_Write: pcb->state =
> %s\r\n", StatStr[pTcpUdpConData->tcp_pcb->state]);
>      
>    err = tcp_write(pTcpUdpConData->tcp_pcb,
> pTcpUdpConData->RmSavedMessage.Command,
> pTcpUdpConData->RmSavedMessage.CommandLen, 0);
>    
>    if(err == ERR_OK)
>    {
>      tcp_output(pTcpUdpConData->tcp_pcb);
>    }
>    else
>    {
>      TCPUDP_SND_DIAG("From TcpUdpSendToRemote_Write: tcp_write
> returned err = %0X\r\n", err);
>      
>      TcpUdpSendToRemote_Close(pTcpUdpConData->tcp_pcb);
>      
>      pTcpUdpConData->tcp_pcb = NULL;
>    }
> }
>
>
> BR,
> Noam.
>
> -----Original Message-----
> From: lwip-users [mailto:lwip-users-bounces+noam=[hidden email]]
> On Behalf Of Noam Weissman
> Sent: Monday, February 13, 2017 10:28 AM
> To: Mailing list for lwIP users
> Subject: Re: [lwip-users] Binary file upload chrashes the program
> (lwip 1.4.1)
>
> Hi Szabolcs,
>
> Sure I am ok :-),  we are all developers here.
>
> RAW API is very tricky. If you only use RAW API you cannot call any LwIP functions from outside the TCP stack context !.
> If you call any LwIP functions in another task without protection or not as it was designed it may crash, you may get Memory allocation errors etc...
>
> On other thing to pay attention that is not so obvious is Cortex-M interrupts handling and FreeRTOS.
>
> If you took an ST project and this is from the last year or something you are probably ok if you have not changed the interrupts Priority levels. If you did you must check your code again. This is a problem that many do not pay attention. Let me explain.
>
> FreeRTOS uses a time tick interrupt. It also uses code to protect critical sections. Critical section means that portion of the code will mask interrupts that have a LOWER interrupt priority.
>
> ** In FreeRTOS a higher number means higher interrupt level.
> *** in Cortext-M a lower interrupt level number means a higher priority !!
>
> If the RTOS tick has interrupt priority 5, any other interrupt that is set lower than 5 will not be masked if a critical section is handled. As a result you get instability issues that are very difficult to debug.
>
> Take a look at the following code, part of FreeRTOSConfig.h:
>
> #define IRQ_SYS_PRIORITY_MODEL  NVIC_PriorityGroup_4
>
> /* Cortex-M specific definitions. */
> #ifdef __NVIC_PRIO_BITS
> /* __BVIC_PRIO_BITS will be specified when CMSIS is being used. */
> #define configPRIO_BITS       __NVIC_PRIO_BITS
> #else
> #define configPRIO_BITS       4        /* 15 priority levels */
> #endif
>
> /* The lowest interrupt priority that can be used in a call to a "set priority"
> function. */
> #define configLIBRARY_LOWEST_INTERRUPT_PRIORITY 0xF
>
> /* The highest interrupt priority that can be used by any interrupt service routine that makes calls to interrupt safe FreeRTOS API functions.  DO NOT CALL INTERRUPT SAFE FREERTOS API FUNCTIONS FROM ANY INTERRUPT THAT HAS A HIGHER PRIORITY THAN THIS! (higher priorities are lower numeric values. */
> #define configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY 5
>
> /* Interrupt priorities used by the kernel port layer itself.  These are generic to all Cortex-M ports, and do not rely on any particular library functions. */
> #define configKERNEL_INTERRUPT_PRIORITY ( configLIBRARY_LOWEST_INTERRUPT_PRIORITY << (8 - configPRIO_BITS) )
> /* !!!! configMAX_SYSCALL_INTERRUPT_PRIORITY must not be set to zero !!!!
> See http://www.FreeRTOS.org/RTOS-Cortex-M3-M4.html. */
> #define configMAX_SYSCALL_INTERRUPT_PRIORITY ( configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY << (8 - configPRIO_BITS) )
>
>
> #define ADC3_DMA_ISR_PRIO      (configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY + 6)
> #define ETH_ISR_PRIO           (configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY + 5)
> #define IR_TIMERS_ISR_PRIO     (configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY + 2)
> #define SERIAL_ISR_PRIO        (configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY + 1)
>
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> ---------
>
> The RTOS priority level is configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY ... while ETH and all other hardware interrupts are set at
> a higher number ( lower priority )
>
> If your system is not set like this you must change it. !!!
>
> ----------------------------------------------------------------------
> ---
>
> Secondly if you need to send data over TCP outside of the LwIP context you must pay special attention to it.
>
> The designed (correct) way to do it is create a call back function that is called from within the LwIP context.
> This is done by using this function:  tcpip_callback(function, ctx);
>
> Function is your own call back while ctx is your own argument. Here is a a portion of my code that uses this, This function is my call back, part of my code:
>
> //typedef void (*tcpip_callback_fn)(void *ctx); static void TcpUdpSendToRemote_Write(void *Data) {
>    TcpUdpConData_t *pTcpUdpConData = (TcpUdpConData_t*)Data;
>    err_t err;
>    
>    TCPUDP_SND_DIAG("From TcpUdpSendToRemote_Write: pcb->state =
> %s\r\n", StatStr[pTcpUdpConData->tcp_pcb->state]);
>      
>    err = tcp_write(pTcpUdpConData->tcp_pcb,
> pTcpUdpConData->RmSavedMessage.Command,
> pTcpUdpConData->RmSavedMessage.CommandLen, 0);
>    
>    if(err == ERR_OK)
>    {
>      tcp_output(pTcpUdpConData->tcp_pcb);
>    }
>    else
>    {
>      TCPUDP_SND_DIAG("From TcpUdpSendToRemote_Write: tcp_write
> returned err = %0X\r\n", err);
>      
>      TcpUdpSendToRemote_Close(pTcpUdpConData->tcp_pcb);
>      
>      pTcpUdpConData->tcp_pcb = NULL;
>    }
> }
>  
>
> This is how the above is added to the LwIP handling queue:
> tcpip_callback(TcpUdpSendToRemote_Write, pTcpUdpConData);
>
>
> This way LwIP calls user function from within LwIP context.
>
>
> The above is the recommended way to do it. I hope this helped :-)
>
> BR,
> Noam.
>
>
> -----Original Message-----
> From: lwip-users [mailto:lwip-users-bounces+noam=[hidden email]]
> On Behalf Of Vass Szabolcs
> Sent: Monday, February 13, 2017 9:51 AM
> To: Mailing list for lwIP users
> Subject: Re: [lwip-users] Binary file upload chrashes the program
> (lwip 1.4.1)
>
> Hello,
>
> @Mr. Nielsen: I don't remember which version of Cube Mx was used when
> I generated the project. Honestly it was a long time ago, and I used
> to download frequently the latest updates. But I know that version
> contained only the lwip 1.4 stack. I'm using their ethernetif.c
>
> @Mr. Weissmann: Under complicated project I understand that I implemented a http webserver using Raw API. It's running on a device, that have another complex features that I can't share with You, because these are company secrets. I hope You understand me and You aren't mad at me.
> I think that the problem is coming two possible way:
>
>                   - the generated lwip library contains these bugs
>
>                   - I'm not using the lwip functions properly
>
>
> Is helping if I attach the lwip library compressed to a zip file and the http functions that I implemented for uploading binary files?'
>
> I think that this forum only the right place where I can get the right answers and helps from You, because You developed these stack and You are experts in this area. ST and other vendors just are using Your stack, sometimes add some functionality to them, but You are who understand deeply.
>
> I'm sure that if I write to their forums they send to You (and I think that it is correct), because this area isn't their area, and You are the lwip developers.
>
> Please help me, to get the right solution together.
>
> Than You so much.
>
> Sincerely,
>
> Szabolcs
>
>
>
> 2017.02.12. 18:02 keltezéssel, Noam Weissman írta:
>> 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:lwip-users-bounces+noam=[hidden email]]
>> 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
>>> [hidden email]
>>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>> _______________________________________________
>> lwip-users mailing list
>> [hidden email]
>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>>
>> _______________________________________________
>> lwip-users mailing list
>> [hidden email]
>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
> _______________________________________________
> lwip-users mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
> _______________________________________________
> lwip-users mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
> _______________________________________________
> lwip-users mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/lwip-users


_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Binary file upload chrashes the program (lwip 1.4.1)

Vass Szabolcs
Hi Mr. Weissman,

Thank You for Your advice. If I understood good, I have to set the
ethernet interrupt priority to the highest, and when I use the
tcp_write(), or tcp_recved() have to mask all other interrupts?

So these are same with mutexes or semaphores under an operating system?
And if I didn't use any real time operating system(FreeRTOS) I have to
write manually these functions that threat the critical section?


Kind regards,

Szabolcs Vass



2017.02.14. 10:50 keltezéssel, Noam Weissman írta:
> Thank You Mr. Weissman


_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Binary file upload chrashes the program (lwip 1.4.1)

Vass Szabolcs
*treat (handle) the critical section


2017.02.23. 10:14 keltezéssel, Vass Szabolcs írta:

> Hi Mr. Weissman,
>
> Thank You for Your advice. If I understood good, I have to set the
> ethernet interrupt priority to the highest, and when I use the
> tcp_write(), or tcp_recved() have to mask all other interrupts?
>
> So these are same with mutexes or semaphores under an operating
> system? And if I didn't use any real time operating system(FreeRTOS) I
> have to write manually these functions that threat the critical section?
>
>
> Kind regards,
>
> Szabolcs Vass
>
>
>
> 2017.02.14. 10:50 keltezéssel, Noam Weissman írta:
>> Thank You Mr. Weissman
>


_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Binary file upload chrashes the program (lwip 1.4.1)

Noam weissman
In reply to this post by Vass Szabolcs
Hi Szabolcs,

Not exactly....

I said that TCP stack should be the highest priority because it is doing housekeeping and needs a high time share
In order to work properly, and efficiently.

Regarding the usage of critical section it is not the preferred or advised way to use LwIP functions outside
of the TCP thread context. This is a way I found to be working and gives a solution to some situations.

The correct way is to create a call back function and call it from within the TCP stack context.

I never used LwIP without an OS running it all so I am not the person to consult with, sorry.
I just do not want advise you something I have no experience with :-(

Anyone can assist  ???


BR,
Noam.


-----Original Message-----
From: lwip-users [mailto:lwip-users-bounces+noam=[hidden email]] On Behalf Of Vass Szabolcs
Sent: Thursday, February 23, 2017 10:15 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] Binary file upload chrashes the program (lwip 1.4.1)

Hi Mr. Weissman,

Thank You for Your advice. If I understood good, I have to set the ethernet interrupt priority to the highest, and when I use the tcp_write(), or tcp_recved() have to mask all other interrupts?

So these are same with mutexes or semaphores under an operating system?
And if I didn't use any real time operating system(FreeRTOS) I have to write manually these functions that threat the critical section?


Kind regards,

Szabolcs Vass



2017.02.14. 10:50 keltezéssel, Noam Weissman írta:
> Thank You Mr. Weissman


_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Binary file upload chrashes the program (lwip 1.4.1)

goldsimon@gmx.de
In reply to this post by Vass Szabolcs
Coming back to the 2nd mail of this thread:

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

So here's a problem in lwIP (or the handling of lwIP rather) and you
don't want to use a fixed version...

> 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?

That being said ("modify".. whatever), I just can say: not me! How could
I possible tell what's going wrong if I don't know what's running on
your side? I wouldn't want to start telling you what it could be if
you're running a modified version that I don't know!

That being said, I have plans of getting lwIP to run no-OS on my
ETH-enabled STM32F429I-DISCO which shouldn't be too much different from
the F407. Well, ST has the annyoing problem that sometimes the libraries
for different processors are too different (in my opinion), but the F407
and the F427 should be OK.

However, I'll try to do it the standard ST (cube) way then and report
problems back to ST instead of "modify[ing] in the lwip function"
(whatever that means).

Cheers,
Simon

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Binary file upload chrashes the program (lwip 1.4.1)

Pal Gabor
In reply to this post by Vass Szabolcs
I'm working on a webserver with firmware update, and I use lwip 1.4.0 with
atmel SAME54 , I have your problem too
when I try to upload binary file. My problem was solved, when I overwrite
the TCP window parameter from 4 to 1.

...
// <o> The size of a TCP window<0-100000>
// / multiple of TCP_MSS
// / Default: 4
// <id> lwip_tcp_wnd_mul
#ifndef TCP_WND_MUL
#define TCP_WND_MUL 1
#endif
...




--
Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Binary file upload chrashes the program (lwip 1.4.1)

goldsimon@gmx.de
Am 30.11.2018 um 15:03 schrieb Pal Gabor:
> I'm working on a webserver with firmware update, and I use lwip 1.4.0 with
> atmel SAME54 , I have your problem too
1.4.0 is *really* old! There have been many bugs fixed since then!

> when I try to upload binary file. My problem was solved, when I overwrite
> the TCP window parameter from 4 to 1.
>
> ...
> // <o> The size of a TCP window<0-100000>
> // / multiple of TCP_MSS
> // / Default: 4
> // <id> lwip_tcp_wnd_mul
> #ifndef TCP_WND_MUL
> #define TCP_WND_MUL 1
> #endif
> ...

That doesn't sound like lwIP specific defines. Is this Atmel specific?


Simon



_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users