FNET - TCP/IP Stack

[butok]

FNET TCP/IP stack: Version 0.5.0 released. 
 

FNET Home page: http://fnet.sourceforge.net/

    Please, submit your feature requests and feedbacks here:

    http://sourceforge.net/tracker/?group_id=253892&atid=1126921 

    Please, submit your bug reports here:

    http://sourceforge.net/tracker/?group_id=253892&atid=1126920

FNET brief information:
The FNET is a free, open source software project (under GNU GPLv3) for building embedded communication software using the Freescale processors.

The stack provides following protocols and services:
  * Supported platforms:
     - Reindeer - MCF5282 (M5282EVB).
     - Kirin2 - MCF52235 (M2235EVB).
     - Kirin3 - MCF52259 (M2259EVB).
     - Lasko - MCF51CN128 (TWR-MCF51CN).
     - Other Freescale platforms to be supported soon.
  * Available as:
     - Stand-alone version. No underlying RTOS is required, although it can be used with it.
  * Supported Compilers:
     - Freescale CodeWarrior for ColdFire Version 7.1.
     - Freescale CodeWarrior for Microcontrollers Version 6.2.
  * BSD-style Socket layer API
  * Protocols:
     - User Datagram Protocol (UDP).
     - Transmission Control Protocol (TCP).
     - Internet Protocol (IPv4).
     - Internet Control Message Protocol (ICMP).
     - Address Resolution Protocol (ARP).
  * Network Interfaces:
     - Ethernet interface.
     - Loopback interface.
  * Services:
     - HTTP/0.9 server. Both SSI and CGI are supported.
     - DHCP client.
     - TFTP client.
     - Static File System.
     - CFM Flash driver.
  * Tools:
     - GUI File System Generation Tool.
  * Applications:
     - TFTP Bootloader.
     - Shell Application.
  * Doxygen User Documentation.

 Changes in 0.5.0 (since last public version):
 - Added TFTP client.
 - Added Coldfire Flash Module (CFM) driver.
 - Added FNET TFTP Bootloader.
 - Fixed DHCP client.
 - Updated Shell Demo application. Application parameters are saved in the flash.
 - Improved Shell library. Added blocking-command and multi-word parameter features.
 - A lot of other changes and fixes.

Best regards,

Andrey Butok

[butok]

Hi Tom,

I have added your "temporisation" code to fnet_fec_output().

I am not able to reproduce any problem. There is NO locking on while or stop on your break point  ("fnet_fec_output_reentry_count = 0;").

I use FNET 2.6.0, MCF52259EVB, CW7.2.2. and FBENCH application stressing FNET stack.

BTW:

      Please use the latest FNET - to be sure that we use the same stack (older versions are unsupported).

      I have just put  the FNET for 24-hour stress-test, just to be 100% sure.

Thanks,

Andrey

[TomE]

First, I agree that trying the latest FNET should be the first thing to try. If that fails then ...

> There is NO locking on while or stop on your break point  ("fnet_fec_output_reentry_count = 0;").

I think that means that the network traffic you're using in your test isn't the same as Thomas is using. His traffic pattern is triggering the fault and FBENCH may not be generating this specific pattern.

From inspecting the Stack Trace that he posted I'm pretty sure that his traffic patterns consists of:

1 - His code is periodically sending UDP packets to another machine. The more frequent the sending the more often this should happen.

2 - (Critical) Something ELSE on his network is sending packets to his device that are triggering ICMP Error messages in reply. The most likely cause is a TCP or UDP packet sent to a port address that his code IS NOT listening on. Receipt of that packet should cause an ICMP "Destination port unreachable" Error message to be sent out. ICMP Pings from an external device might also trigger the same problem. Or they may not.

3 - When the FEC RX Interrupt with the incoming UDP packet interrupts the outgoing FEC transmit function it seems to trigger the problem.

I would suggest a test with the DUT sending a UDP packet stream to another device. This might best be done with a "UDP Echo Server" on the DUT and a sender elsewhere (these used to be standard services in Unix before people started abusing them). Then at the same time, FLOOD-ping the DUT.

I have send detailed suggestions for further testing to Thomas' email rather than fill up this post.

Tom

[TomLEE]

Ok, thank you Andrey.

I use FNET 2.3.0 so I will change to last version.

I don't test with FBENCH, I use my Windows application that I wrote in VB.NET using .net framework 3.5. Perhaps, there is an issue here, I don't know, I will try with FBENCH.

I'll keep you informed if I find something new...

Thomas.

[butok]

Hi Thomas,

Thank you very much for your pushing. I am able to reproduce the issue!!

The fix is to add missing fnet_isr_lock()/unlock() to the fnet_udp_snd() function:

+++ "b/C:\\@ccwork\\FNET\\gitcodedev\\src\\fnet\\fnet_stack\\stack\\fnet_udp.c"

@@ -574,6 +574,8 @@ static int fnet_udp_snd( fnet_socket_t *sk, char *buf, int len, int flags, const

     }

#endif /* FNET_CFG_TCP_URGENT */

+    fnet_isr_lock();

+

     if(len > sk->send_buffer.count_max)

     {

         error = FNET_ERR_MSGSIZE;   /* Message too long. */

@@ -613,6 +615,8 @@ static int fnet_udp_snd( fnet_socket_t *sk, char *buf, int len, int flags, const

         sk->options.flags = flags_save;

     }

+    fnet_isr_unlock();

+   

     if((error == FNET_OK) && (sk->options.local_error == FNET_OK)) /* We get UDP or ICMP error.*/

     {

         return (len);

BTW: The TCP is OK, has passed  the stress-tests.

The fix will be availble in the nearest FNET 2.6.1 release.

Thank you very much,

Andrey Butok

[TomE]

> The fix is to add missing fnet_isr_lock()/unlock() to the fnet_udp_snd() function:

I'm looking at your patch. I may have got this wrong as I need to count the lines in the file where the patch applies and may have missed something.

Doesn't it need a second fnet_isr_unlock() after the "ERROR:" line?

Otherwise if two of the three cases that "goto ERROR;" happen it will leave the function without removing the lock. I would assume interrupts ould remain locked out until a power cycle.

If that is the case it would be good practice to first improve the test harness to find this problem before fixing it.

There's a second problem that was the trigger for showing this first one.

As he said, Thomas is sending two UDP packets to FNET about 1ms apart. These are both to the same UDP socket. They should both result in responses from his code. Instead, the second one sometimes responds with an ICMP Error Message "Destination unreachable, Port unreachable. That means that fnet_socket_lookup() is somehow unable to find the socket when there's a reply pending. When he added that time-wasting delay to the Ethernet sending code it happened more often. So there's a timing race condition there somewhere.

Could your bug-fix explain this problem as well?

The only simple cause I can think of for this would that if Thomas' user code is de-registering the socket during a reply somehow, and then re-registering it after.

Tom (not Thomas, he's in France :-)

[butok]

Thanks Tom,

The correct version must be:

+++ "b/C:\\@ccwork\\FNET\\gitcodedev\\src\\fnet\\fnet_stack\\stack\\fnet_udp.c"

@@ -574,6 +574,8 @@ static int fnet_udp_snd( fnet_socket_t *sk, char *buf, int len, int flags, const

     }

#endif /* FNET_CFG_TCP_URGENT */

+    fnet_isr_lock();

+

     if(len > sk->send_buffer.count_max)

     {

         error = FNET_ERR_MSGSIZE;   /* Message too long. */

@@ -615,11 +617,13 @@ static int fnet_udp_snd( fnet_socket_t *sk, char *buf, int len, int flags, const

     if((error == FNET_OK) && (sk->options.local_error == FNET_OK)) /* We get UDP or ICMP error.*/

     {

+        fnet_isr_unlock();

         return (len);

     }

ERROR:

     fnet_socket_set_error(sk, error);

+    fnet_isr_unlock();

     return (SOCKET_ERROR);

}

>>The only simple cause I can think of for this would that if Thomas' user code is de-registering the socket

Think this is the case, the socket is closed before all data are received.

Thank you,

Andrey Butok

[TomE]

> Think this is the case, the socket is closed before all data are received.

I've just heard back from Thomas. His code was written to close the listening socket before transmitting a reply. I'd guess "Open receive socket, wait for packet, read, close, send then go back to the start". That's why it was occasionally sending the ICMP Error and tripping the Ethernet/IP reentry hazard.

> The correct version must be:

Andrey knows there are some minor changes needed to the patch to cover all of the exit conditions. Anyone applying this fix before the next release can get this right by inspection.

Tom

[butok]

The fix has been incorporated to the FNET 2.6.1

[TomLEE]

Hi Andrey,

wonderful ! Thank you for your perseverance !

As you said, I tried with FNET 2.6 but same problem.

So I search in my PC software and I found why this issue occur : it sends 2 successives frames (only 1ms between each in wireshark), and FNET don't have enough time I suppose, so it answers ICMP error (Destination unreachable, Port unreachable) for the second.

I modify my software in order to transmit only one frame at a time. And no more ICMP error !

I will also modify FNET with your last fix.

Now, I leave work one week and I hope there will be no lockup...

Thank you again,

Thomas.

[butok]

Hi Thomas,

>>I will add timeout to exit this infinite loop.

I guess it will not help to you to solve the issue.

Based on my practice, it locks in while(ethif->tx_buf_desc_cur->status & FNET_HTONS(FNET_FEC_TX_BD_R)){};

only cause of HW issue (wrong  communication  MAC and PHY) or wrong pin configuration, and it happens immediately - during sending the first packet.

In your case it happens after long time of work - never met it before.  Please inform us if you find a source of issue.

Thanks,

Andrey

[butok]

FNET 2.6.0 released (http://fnet.sourceforge.net):

- Added Multicast Listener Discovery Version 1 (MLDv1), enabled by FNET_CFG_MLD.

- New IPv6 socket options:

     - IPV6_MULTICAST_HOPS changes the hop limit to use for outgoing multicast IPv6 packets.

     - IPV6_JOIN_GROUP joins a multicast group on a specified local interface.

     - IPV6_LEAVE_GROUP leaves a multicast group on a specified interface.

- Other minor changes.

Best regards,
Andrey Butok

FNET Community

[JHinkle]

Andrey:

I attempting to understand your FNET code.

I started with the K60 ENET section in the K60 specification.  I've done some MAC related software years ago so I have a good feeling on what needs to happen (I had the raw data coming from a Microchip MAC at the time).

The MAC on the K60 appears to be more advanced but the documentation is hard to understand ... its all chopped up into little bits with no overview.

I've check the net and no luck --- so I'm hoping you can help.

Is there some document that explains the MAC in the K60, how it works, best way to interface with it, etc?

Thanks in advance for your help.

Joe Hinkle

[butok]

Hi Joe,

>>Is there some document that explains the MAC in the K60, how it works, best way to interface with it, etc?

The only ENET/FEC-module documentation, I know and use, is the standard Reference Manual. Agree, it is not clear and difficult to understand, and it does not show a best practice (it is true for any other module). You can also try to search an Application Note (not sure if any exists). The code you can see, in fnet_fec.c, is the result of try-and-mistake approach.

Best regards,

Andrey Butok

[wdehaan]

Hi,

I think there is a bug in the "fnet_fec_phy_discover_addr (...)" function. Even if it does not find any phy the address is set to 31. Is this behavior wanted?

Best regards,

Wilfried de Haan

[butok]

Hi Wilfried de Haan,

If it does not find any PHY, it is no matter to what value it is set, as there is something wrong with MAC and PHY communication. Actually it should never happen (if no HW issue).

In any case, I would change its behavior to signal about the error to a caller function.

Thank you,

Andrey

[wdehaan]

Hi,

I actually had this problem, there is a HW issue on the custom board I use, so the communication with the PHY via MDIO is not possible but the stack is still working and I can send and receive data via Ethernet.

Best regards,

Wilfried

[butok]

Hi Wilfried,

I see. The fix will be avalbale in the next FNET version release.

Thanks,

Andrey Butok

[JHinkle]

Andrey.

I moved away from Codewarrior and MQX -- so now I'm implementing FNET.

I am going to also use a RTOS so I was looking at where you signalled when a socket was ready for the application.

I noticed three fnet_os_event_raise() calls -- two were TCP and I suspect the third was upon a UDP socket message.

My question was -- why did you not place the signaling event inside the Socket structure?

I will have two tasks running - both processing different sockets.  Having FNET signal the task associated with the socket would be better than just a global signal as it is now.

I ask your opinion before I go in and make those changes to my version of FNET --- make sure I'm not missing something before I begin.

Thanks in advance for your reply.

Joe Hinkle

[butok]

Hi Joe,

FNET does not have sockets that are associated with RTOS tasks. It used with RTOS as a user-land library.

The fnet_os_event_raise() was used to wakeup a task that runs user application and fnet_poll_services().

>> Having FNET signal the task associated with the socket would

>> be better than just a global signal as it is now.

I guess you are  interested in OS-blocked Sockets => You can find them in RTCS :smileywink:

In any case, if you find a better solution => your contribution is welcome.

Thanks,

Andrey Butok

[butok]

FNET 2.5.0 released (http://fnet.sourceforge.net):

- Added support of Kinetis K70FN1M0 (TWR-K70F120M board).

- Added support of Modelo MCF54418 (TWR-MCF5441x board).

- Added support of two MAC/Ethernet modules by FEC driver (for MCF54418).

- Added support of uCOS-III, thanks to Jon Elliott.

- Added "bind/unbind" IPv6 address commands to the Shell Demo.

- Added "cookie" parameter to interrupt handlers.

- New/renamed configuration parameters:

    - FNET_CFG_CPU_ETH_RMII enables/disables RMII mode.

    - FNET_CFG_CPU_ETH_RMII_10T sets 10Mbps or 100Mbps in RMII mode.

    - FNET_CFG_CPU_ETHx enables/disables Externet-x module.

    - FNET_CFG_CPU_ETHx_MAC_ADDR defines default MAC address of Externet-x module.

    - FNET_CFG_CPU_ETHx_MTU defines default MTU of Externet-x module.

    - FNET_CFG_CPU_ETHx_PHY_ADDR defines default PHY address used by Ethernet-x module.

    - FNET_CFG_CPU_ETH_PHY_ADDR_DISCOVER enables/disables PHY addresses discover.

    - FNET_CFG_DEFAULT_IF defines default interface.

    - FNET_CFG_OS_TIMER enables/disables OS-specific timer initialization/release.

    - Others.

- Other internal changes.

Andrey Butok

FNET Community

[albertolubeiro]

Hi Andrey,

I´m working with Kinetis K60 and TCP/IP sending data to an hiperterminal program that works like a client.

What i do is; when the "hercules" connect i send "hello world" and next I close the socket. After doing this manytimes, the hercules connect but i can't send nothing because in the "fnet_tcp_snd" function  "if(malloc_max < (long)(FNET_CFG_ETH_MTU*1.5))" is TRUE and "freespace = 0"

I have tried to follow the code in order to delete the data sent but i don't know how.

I have not advanced since 2 months. Any help will be welcome.

Please can you give some indications to fix it.

Thanks and best regards