2011-12-13 10:34 AM
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=255Odpov?? od 10.0.10.144: bajty=1472?as=1ms
TTL=255Odpov?? od 10.0.10.144: bajty=1472?as=1ms
TTL=255Odpov?? od 10.0.10.144: bajty=1472?as=1ms
TTL=255Statistika 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 = 1msC:\>ping 10.0.10.144 -l1473
P?�kaz PING na 10.0.10.144 s d�lkou 1473 bajt?:Vypr�el ?asov� limit ��dosti. -Means timeoutStatistika ping pro 10.0.10.144:Pakety: Odeslan� = 1, P?ijat� = 0, Ztracen� = 1 (ztr�ta 100%),Control-C^CC:\>ping 10.0.10.144 -l1472
P?�kaz PING na 10.0.10.144 s d�lkou 1472 bajt?:Odpov?? od 10.0.10.144: bajty=1472?as=340ms
TTL=255Odpov?? od 10.0.10.144: bajty=1472?as=89ms
TTL=255Odpov?? od 10.0.10.144: bajty=1472?as=691ms
TTL=255Odpov?? od 10.0.10.144: bajty=1472?as=438ms
TTL=255Statistika 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 = 389msAs 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-delay2011-12-14 11:12 AM
!!!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 Kamenicky2011-12-15 12:54 AM
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,2011-12-15 05:40 AM
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 1may help. You should try it, I have no time at moment to test it.Regards,TK