STM32F2x7 lwip ping -l> 1472 causes library mailfunction

[tomas239955_stm1_st]

Posted on December 13, 2011 at 19:34

Hi there,

if you try to ping demo example LWIP 1.1.0 for STM32F2x7 mcu with data length bigger than 1472 then lwip library or something else goes wrong, see responses:

C:\>ping 10.0.10.144 -l

1472

P?�kaz PING na 10.0.10.144 s d�lkou 1472 bajt?:

Odpov?? od 10.0.10.144: bajty=1472

?as=1ms

TTL=255

Odpov?? od 10.0.10.144: bajty=1472

?as=1ms

TTL=255

Odpov?? od 10.0.10.144: bajty=1472

?as=1ms

TTL=255

Odpov?? od 10.0.10.144: bajty=1472

?as=1ms

TTL=255

Statistika ping pro 10.0.10.144:

Pakety: Odeslan� = 4, P?ijat� = 4, Ztracen� = 0 (ztr�ta 0%),

P?ibli�n� doba do p?ijet� odezvy v milisekund�ch:

    Minimum = 1ms, Maximum = 1ms, Pr?m?r = 1ms

C:\>ping 10.0.10.144 -l

1473

P?�kaz PING na 10.0.10.144 s d�lkou 1473 bajt?:

Vypr�el ?asov� limit ��dosti. -Means timeout

Statistika ping pro 10.0.10.144:

Pakety: Odeslan� = 1, P?ijat� = 0, Ztracen� = 1 (ztr�ta 100%),

Control-C

^C

C:\>ping 10.0.10.144 -l

1472

P?�kaz PING na 10.0.10.144 s d�lkou 1472 bajt?:

Odpov?? od 10.0.10.144: bajty=1472

?as=340ms

TTL=255

Odpov?? od 10.0.10.144: bajty=1472

?as=89ms

 TTL=255

Odpov?? od 10.0.10.144: bajty=1472

?as=691ms

TTL=255

Odpov?? od 10.0.10.144: bajty=1472

?as=438ms

TTL=255

Statistika ping pro 10.0.10.144:

Pakety: Odeslan� = 4, P?ijat� = 4, Ztracen� = 0 (ztr�ta 0%),

P?ibli�n� doba do p?ijet� odezvy v milisekund�ch:

    Minimum = 89ms, Maximum = 691ms, Pr?m?r = 389ms

As you can see the if you try ping again with proper length the lwip or something is causing big delays, any suggestions?

This happens only if you exceed MTU size, after that delays occures.

Regards,

Tomas Kamenicky

#lwip-ping-icmp-echo-request #lwip-fragmentation-problem-delay

[tomas239955_stm1_st]

Posted on December 14, 2011 at 20:12

!!!SOLVED!!!

The problem is in PHY or PERIPHERAL hw. If you send to unit a fragmented packed (for example by sending ping with arg -l 1473) then packets are bufferd inside hardware. The IRQ is called, but only once, which result is reading out only the first fragment, the second one keeps remaining in hw. After that if you send to unit an another packet, lets say third packet, the IRQ is called but the second (half of fragmented) packet is readed out and the third remains in hardware. This repeats until reset. The result is as described in first post.

So to repair this issue you have to modify functionethernetif_input andlow_level_input only (blue backround means code changes from origin):

void

 

ethernetif_input(

 

void

 

* pvParameters) {

struct

 

pbuf *p;

for

 

(;;) {

if

 

(xSemaphoreTake( s_xSemaphore, emacBLOCK_TIME_WAITING_FOR_INPUT) == pdTRUE) {

TRY_GET_NEXT_FRAGMENT:

p = low_level_input(s_pxNetIf);

if

 

(p != NULL) {

if

 

(ERR_OK != s_pxNetIf->input(p, s_pxNetIf)) {

pbuf_free(p);

p = NULL;

}

else

 

{

xSemaphoreTake( s_xSemaphore, 0);

goto

 

TRY_GET_NEXT_FRAGMENT;

}

}

 

else

 

{

//PHY buffer is empty, continue to wait for ISR

}

}

}

}

static

 

struct

 

pbuf * low_level_input(

 

struct

 

netif *netif) {

struct

 

pbuf *p, *q;

u16_t len;

uint32_t l = 0, i = 0;

FrameTypeDef frame;

u8 *buffer;

__IO ETH_DMADESCTypeDef *DMARxNextDesc;

p = NULL;

/* Get received frame */

frame = ETH_Get_Received_Frame_interrupt();

/* Check if really we have something or not */

if

 

(frame.descriptor==NULL)

 

return

 

p;

/* check that frame has no error */

if

 

((frame.descriptor->Status & ETH_DMARxDesc_ES) == (uint32_t) RESET) {

/* Obtain the size of the packet and put it into the ''len'' variable. */

len = frame.length;

buffer = (u8 *) frame.buffer;

/* We allocate a pbuf chain of pbufs from the pool. */

p = pbuf_alloc(PBUF_RAW, len, PBUF_POOL);

/* Copy received frame from eth....and so on the code under that text remains untouched

Regards,

Tomas Kamenicky

[amin23]

Posted on December 15, 2011 at 09:54

Hi Tomas,

I have made the same update, but I still have an issue when I try to ping

with data length bigger than 1472.

I am using the latest Ethernet package V1.1.0

Regards,

[tomas239955_stm1_st]

Posted on December 15, 2011 at 14:40

Hi,

ICMP echo request width data length > 1472 not supported in lwip 1.3.2. (this version is in ST's lib V1.1.0).

Maybe turning options:

#define IP_REASSEMBLY           1

 

#define IP_FRAG                       1

may help. You should try it, I have no time at moment to test it.

Regards,

TK