Re: [lwip-users] 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:address@hidden 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: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
>
> _______________________________________________
> 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