9 years, 11 months ago.  This question has been closed. Reason: Duplicate question

K64F and ethernet seem very unstable

Hi All,

I've started working on ethernet on a Freescale F64F (Version: 0202 Build: Apr 24 2014 15:04:52). I've created the following program with the latest revisions of these libs included:

http://mbed.org/users/mbed_official/code/EthernetInterface/ http://mbed.org/users/mbed_official/code/mbed-rtos/ http://mbed.org/users/mbed_official/code/mbed-src/

#include "mbed.h"
#include "EthernetInterface.h"

DigitalOut green(LED_GREEN);
DigitalOut blue(LED_BLUE);
EthernetInterface eth;

int main()
{
    blue=0;    
    eth.init(); //Use DHCP
    eth.connect();
    blue=1;
    while (true) {
        green = 1;
        wait(1);
        green = 0;
        wait(0.1);
    }

}

The program boots. After a few seconds the blue led turns blinking green indicating it has an IP. I can indeed ping the IP, but only about 5 times, after that the device stops responding to ping, but the green led keeps blinking.

ping -c 10 192.168.1.29
PING 192.168.1.29 (192.168.1.29) 56(84) bytes of data.
64 bytes from 192.168.1.29: icmp_seq=1 ttl=255 time=6.82 ms
64 bytes from 192.168.1.29: icmp_seq=2 ttl=255 time=9.83 ms
64 bytes from 192.168.1.29: icmp_seq=3 ttl=255 time=7.87 ms
64 bytes from 192.168.1.29: icmp_seq=4 ttl=255 time=5.83 ms
64 bytes from 192.168.1.29: icmp_seq=5 ttl=255 time=8.83 ms

--- 192.168.1.29 ping statistics ---
10 packets transmitted, 5 received, 50% packet loss, time 9009ms
rtt min/avg/max/mdev = 5.836/7.841/9.830/1.415 ms

Also when sending a large packet (which will require fragmentation), the device will hang after trying to send it's response in just 1 packet and the green led will stop blinking:

ping -s 4096 -c 2 192.168.1.29
PING 192.168.1.29 (192.168.1.29) 4096(4124) bytes of data.
4104 bytes from 192.168.1.29: icmp_seq=2 ttl=255 time=6.11 ms

--- 192.168.1.29 ping statistics ---
2 packets transmitted, 1 received, 50% packet loss, time 1008ms
rtt min/avg/max/mdev = 6.118/6.118/6.118/0.000 ms

It seems that (at least ICMP) on these devices is *very* unstable. I've made some first steps in debugging the issue and was able to 'workaround' the second problem by dropping large packets in the ip_output_if function in ip.c (line 572). So it seems the device will hang on sending such a large packet, not on receiving).

What to do now? There is a lot of debug information mentioned in the code, is there any way for me to get this debug output somehow?

Hi,

there's LWIPOPTS header file, where you can enable messages. A snippet from that file

// Debug Options
// #define LWIP_DEBUG
#define UDP_LPC_EMAC                LWIP_DBG_OFF
#define SYS_DEBUG                   LWIP_DBG_OFF
#define PPP_DEBUG                   LWIP_DBG_OFF
#define IP_DEBUG                    LWIP_DBG_OFF
#define MEM_DEBUG                   LWIP_DBG_OFF
#define MEMP_DEBUG                  LWIP_DBG_OFF
#define PBUF_DEBUG                  LWIP_DBG_OFF
#define API_LIB_DEBUG               LWIP_DBG_OFF
#define API_MSG_DEBUG               LWIP_DBG_OFF
#define TCPIP_DEBUG                 LWIP_DBG_OFF
#define SOCKETS_DEBUG               LWIP_DBG_OFF
#define TCP_DEBUG                   LWIP_DBG_OFF
#define TCP_INPUT_DEBUG             LWIP_DBG_OFF
#define TCP_FR_DEBUG                LWIP_DBG_OFF
#define TCP_RTO_DEBUG               LWIP_DBG_OFF
#define TCP_CWND_DEBUG              LWIP_DBG_OFF
#define TCP_WND_DEBUG               LWIP_DBG_OFF
#define TCP_OUTPUT_DEBUG            LWIP_DBG_OFF
#define TCP_RST_DEBUG               LWIP_DBG_OFF
#define TCP_QLEN_DEBUG              LWIP_DBG_OFF
#define ETHARP_DEBUG                LWIP_DBG_OFF
#define NETIF_DEBUG                 LWIP_DBG_OFF
#define DHCP_DEBUG                  LWIP_DBG_OFF

The messages should be send via USBTX, USBRX, so you should see it on your console. Let us know if you get the debug messages activated.

Regards,
0xc0170

posted by Martin Kojtal 30 May 2014

Hi Martin,

When I set the define of the debug and set the flags to LWIP_DBG_ON the device never passes the connect() phase. This is all the output I'm getting:

New Thread: tcpip_thread netif_set_ipaddr: netif address being changed netif: IP address of interface set to 192.168.1.20 netif: netmask of interface set to 255.255.255.0 netif: GW address of interface set to 192.168.1.1

Regards, Marius

posted by Marius Karthaus 01 Jun 2014

1 Answer

9 years, 11 months ago.

Hello Marius:

Can you try my code? http://mbed.org/users/sscaglia/code/

I just tested it again and it works fine (1000 pings and/or 4096-sized packets) and I don't see your problem.... Just change the DHCP configuration in case you need (I think it's using static IP in the main.cpp, but just change it as needed.

Regards; Sergio

Hello Sergio,

Your version of ethernetInterface works better in that it keeps responding to pings. However your version still crashes the mbed with a ping packet of 4096 bits.

To test replace from line 30 in your code:

  //UDPSocket echo;
   //echo.bind(ECHO_SERVER_PORT);

 
   //Endpoint host_send;  
   //Endpoint host_rcv;

   // First time only: detect host IP
   //int n = echo.receiveFrom(host_send, buffer, sizeof(buffer));          
   //host_rcv.set_address(host_send.get_address(), 8);
   //echo.sendTo(host_rcv, buffer, sizeof(buffer));

   while(1) {
    // int n = echo.receiveFrom(host_send, buffer, sizeof(buffer));          
   //  echo.sendTo(host_rcv, buffer, sizeof(buffer));
    pc.printf("test\r\n");
    wait(0.5);
   
   }

once you send a :

ping -s 4096 192.168.1.20

the 'test' outputs will stop ( the while loop will not be traversed again, it's not just serial that stops )

Regards, Marius

posted by Marius Karthaus 01 Jun 2014