FNET - TCP/IP Stack

butok · ‎08-24-2009

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

arunkumar1989 · ‎02-23-2017

Hello Andrey,

Is the FNET stack compatable with Kenetis series MCUs?

Thanks,

Arun

niranjanbc · ‎01-25-2017

Hi Andrey

any idea what is the footprint of FNET stack

how much flash it needs, Ram etc

thanks

Niranjan

NicolaPonte · ‎01-16-2014

Hi Andrey,

I'm using FNET 2.6.2 on K60DN256Z.

I simply connect to a TCP server, so I have to open a connection and send data to the port of the TCP server.

Before sending data (I send data every 1 second), I need to know if the TCP server port is still open. Which is the parameter I have to read to check the connection status?

At the moment I'm using

getsockopt(socket_foreign, SOL_SOCKET, SO_STATE, (char*)&connection_state, &option_len);

it returns SS_CONNECTED.

Then I call

send_result = send(socket_foreign, "Test\r\n", 6, 0);

and the result is OK.

For example using the following settings:

TCP_KEEPCNT (1)

TCP_KEEPINTVL (1) /*sec*/

TCP_KEEPIDLE (1) /*sec*/

I can send 3 times the "Test" string before receiving SS_UNCONNETED.

Thank you,

Nicola Ponte

butok · ‎01-16-2014

All what you do is correct.

You can also add a check of the TCP_FINRCVD socket option, to complete your collection :smileywink:

Actually, it is enough to use send() without any additional check. It returns with error, in case connection is closed.

Best regards,

Andrey Butok

NicolaPonte · ‎01-16-2014

But anyway I lose the first two "Test" I send.

I should know if socket is not connected at the first "Test" sending because in my application I would send a string, then save it in an SD card and append a flag that tells me if the string has been correctly sent or not.

In this way I'll save some strings in memory and append a flag that tells me that they have been sent and this is a problem in my application.

Now I check with TCP_FINRCVD option.

Should I call it instead of SO_STATE or call SO_STATE and then TCP_FINRCVD?

Thank you!

butok · ‎01-17-2014

Tom is fully right.

>>Should I call it instead of SO_STATE or call SO_STATE and then TCP_FINRCVD?

For your case, better check TCP_FINRCVD, as it changes its state sooner.

albertolubeiro · ‎05-29-2014

Hi Andrey,

is FNET 2.6.3 compatible with codewarrior 10.6?

I have my code working with FENT 2.1.0 in CW10.5 but i have just updated CW to 10.6 and downoladed FNET 2.6.3 and cant make it works. I get lots of errors.

Before i start working on it, i would like to know if they are compatible or not.

Thanks a lot and best regards

butok · ‎05-30-2014

Hi Alberto,

I am still using 10.5, and not tested it with 10.6.

TomLEE · ‎12-17-2014

Hello Andrey and everybody who use this forum.

I'm trying to port MCF52233 project (originally created with CodeWarrior 7.2) on CodeWarrior 10.6.

On Properties -> C/C++ General -> Paths and symbols, I added ${ProjDirPath}/Sources/FNET Stack but the tool can't find all the subdirectories (I have many errors and warnings and most of #include file.h are "unresolved inclusion"). I MUST manually add all subdirectory to work !!! I don't understand why the tool don't check sub in a directory, is there an option to be checked ?

I look in your MCF52259 project and you only add the top directory, not all sub.

Does someone have any idea to help me ?

Thanks, regards,

Thomas RETAIL.

TomLEE · ‎12-17-2014

I finally found !

In project properties : C/C++ build -> settings -> in Tool Settings -> Coldfire Compiler -> Input, add include paths, not in User Path but in User Recursive Path.

Thomas.

albertolubeiro · ‎06-02-2014

Hi Andrey,

Ok, thanks :smileywink:

NicolaPonte · ‎01-18-2014

Thank you for the answers Tom and Andrey and congratulations for the work on FNET!

Nicola

TomE · ‎01-16-2014

I'm very surprised that TCP is detecting a dropped connection after 3 seconds, It can (and should) take up to 9 minutes.

When faced with these questions, some people try using the "Keepalive" option to detect dropped connections. I detailed the problems with that in this post:

https://community.freescale.com/message/67425#67425

Please read the above as it details other things about TCP connections.

Network stacks can tell you when your local Ethernet cable has been unplugged, but they can't tell you if the NEXT cable (after the first hub) has been unplugged or if the remote server is still working.

TCP "Keepalive" is a really bad idea, and it is only meant to let you know that a connection is down AFTER TWO HOURS and not "right now".

After you attempt a Send, if the connection has been down it can take up to 5 minutes or so for the standard TCP timeouts to finally give up and signal to the Application that THE NEXT send failed. That's not a bug. TCP Writes are queued. The return status indicates they have been QUEUED successfully, not end-to-end-DELIVERED. You can't rely on it taking 3 seconds either. The time taken to time out and signal the disconnection depends on the measured network latencies. You may be getting 3 seconds on your desk, but if you then put the device somewhere else on the Internet or on a slow connection the timing will get longer (up to the 9 minute maximum).

Here is a very good explanation of why TCP should take 9 minutes. FNET may allow these numbers to be changed:

http://www.pcvr.nl/tcpip/tcp_time.htm

TCP was never designed to do automatically what your particular APPLICATION wants to do.

The only way to get a confirmation of delivery of data is to have your program send an explicit message with the data and to then have the remote end send an explicit "Acknowledge" message back.

> Now I check with TCP_FINRCVD option

I'd suggest you examine this diagram:

File:Tcp state diagram fixed new.svg - Wikipedia, the free encyclopedia

It only goes into states that signal "TCP_FINRCVD" after the connection has been CLOSED, either from your end or the other end. So if you send data then actively CLOSE the connection, waiting for the FINRCVD state will tell you that the data got send, then the close, and the close has been completed. If you don't want to perform a CLOSE after every send, then reading TCP_FINRCVD shouldn't tell you anything that the error return from a send already does.

If you want "proof" the data has been accepted by the server (and successfully written) then the server has to tell you that.

Tom

lucaognibene · ‎01-09-2014

Hello everybody and happy new year!

I managed to make FNET work on our board with K60DN256: I prevented the DEBUG_HALT problem (@ optimization level 0) by activating all options in fnet_user_config.h

But I'll post a detailed answer regarding this in few days.

Now I'm facing some problems with the "merge" of FNET with the Freescale USB stack: I had some errors/warnings in the linker files (ProcessorExpert.lcf) while merging the two configurations.

I modified the memory address 'm_data': in this way I got rid of errors and warnings, but I'm not sure I've done the things correctly.

(the line with '#' is the original one; mine is just below)

The problem is that now I receive incorrect characters on the USB port (in echo mode, as basic example in the USB stack): whatever I'm sending I receive 0x20 for the first character and 0x45 for the second.

Here is the whole file ProcessorExpert.lcf:

# Default linker command file.

MEMORY {

m_interrupts (RX) : ORIGIN = 0x00000000, LENGTH = 0x00000410

m_text (RX) : ORIGIN = 0x00000410, LENGTH = 0x0003F3F0 #0x00040000-0x410 /*Ints*/-0x800/*Params*/

fapp_paramsrom (RW) : ORIGIN = 0x0003F800, LENGTH = 0x00000800 # 2KBytes = Last logical-block resevrd for params.

vectorram (RWX) : ORIGIN = 0x1FFF8000, LENGTH = 0x00000410 #

#m_data (RWX) : ORIGIN = 0x1FFF8410, LENGTH = 0x0000EBF0 #0x00010000-0x00000410-0x00001000/*Stack*/

m_data (RWX) : ORIGIN = 0x1FFF8800, LENGTH = 0x0000E800 #0x00010000-0x00000410-0x00001000/*Stack*/

}

KEEP_SECTION { .vectortable }

KEEP_SECTION { .fapp_params }

SECTIONS {

.vectorram : {} > vectorram

.interrupts :

{

__vector_table = .;

* (.vectortable)

. = ALIGN (0x4);

} > m_interrupts

.app_text:

{

ALIGNALL(4);

* (.init)

* (.text)

.= ALIGN(0x8) ;

* (.rodata)

.= ALIGN(0x4) ;

___ROM_AT = .;

} > m_text

.app_data: AT(___ROM_AT)

{

*(.FNET_RAM) #Flash driver "in ram" function.

* (.sdata)

* (.data)

.= ALIGN(0x4) ;

*(.ARM.extab)

.= ALIGN(0x4) ;

__exception_table_start__ = .;

EXCEPTION

__exception_table_end__ = .;

.= ALIGN(0x4) ;

__sinit__ = .;

STATICINIT

___DATA_START =.;

* (.data)

. = ALIGN (0x4);

## Additional data sections defined by components

. = ALIGN (0x0200);

* (.USB_LDD_memory_section)

___DATA_END =.;

__SDATA_START =.;

* (.sdata)

. = ALIGN (0x4);

__SDATA_END = .;

__SDA_BASE = .;

. = ALIGN(0x4);

} > m_data

.bss :

{

.= ALIGN(0x4) ;

__START_BSS = .;

* (.bss)

__END_BSS = .;

.= ALIGN(0x8) ;

} >> m_data

_romp_at = ___ROM_AT + SIZEOF(.app_data);

.romp : AT(_romp_at)

{

__S_romp = _romp_at;

WRITEW(___ROM_AT);

WRITEW(ADDR(.app_data));

WRITEW(SIZEOF(.app_data));

WRITEW(0);

}

__SP_INIT = . + 0x00001000;

__heap_addr = __SP_INIT;

__heap_size = 0x00000000;

# ====== Definitions used by FNET Application. =======

.params :

{

*(.fapp_params)

} > fapp_paramsrom

__VECTOR_RAM = ADDR(.vectorram);

}

Thanks and let me know if I should post this in a different section of the site.

Luca O.

lucaognibene · ‎01-10-2014

Hello again!

Autoanswer! we solved the problem with linker file generated by Processor Expert with this modified 'lcf' file:

KEEP_SECTION { .vectortable }

KEEP_SECTION { .cfmconfig }

KEEP_SECTION { .fapp_params }

MEMORY {

m_interrupts (RX) : ORIGIN = 0x00000000, LENGTH = 0x000001E0

m_text (RX) : ORIGIN = 0x00000410, LENGTH = 0x0003F3F0

fapp_paramsrom (RW) : ORIGIN = 0x0003F800, LENGTH = 0x00000800 # 2kBytes: last logical block reserved for params

m_data (RW) : ORIGIN = 0x1FFF8000, LENGTH = 0x00010000

m_cfmprotrom (RX) : ORIGIN = 0x00000400, LENGTH = 0x00000010

}

SECTIONS {

## Heap and Stack sizes definition

__heap_size = 0x0400;

___stack_size = 0x0400;

.interrupts :

{

__vector_table = .;

* (.vectortable)

. = ALIGN (0x4);

} > m_interrupts

.cfmprotect :

{

*(.cfmconfig)

. = ALIGN (0x4);

} > m_cfmprotrom

.text :

{

* (.text)

. = ALIGN(0x4);

* (.rodata)

. = ALIGN(0x4);

___ROM_AT = .;

___DATA_ROM = .;

} > m_text

.data : AT(___ROM_AT)

{

___DATA_RAM = .;

*(.FNET_RAM) #Flash driver "in ram" function.

* (.data)

.= ALIGN(0x4) ;

* (.ARM.extab)

. = ALIGN(0x4);

__exception_table_start__ = .;

EXCEPTION

__exception_table_end__ = .;

__sinit__ = .;

STATICINIT

___DATA_START =.;

* (.data)

. = ALIGN (0x4);

## Additional data sections defined by components

. = ALIGN (0x0200);

* (.USB_LDD_memory_section)

___DATA_END =.;

__SDATA_START =.;

* (.sdata)

. = ALIGN (0x4);

__SDATA_END = .;

__SDA_BASE = .;

. = ALIGN(0x4);

} > m_data

.bss :

{

__START_SBSS = .;

* (.sbss)

*(SCOMMON)

__END_SBSS = .;

__START_BSS = .;

* (.bss)

* (COMMON)

__END_BSS = .;

. = ALIGN(0x4);

} >> m_data

___HEAP_START = .;

___HEAP_END = ___HEAP_START + __heap_size;

___SP_END = ___HEAP_END;

___SP_INIT = ___SP_END + ___stack_size;

__heap_addr = ___HEAP_START;

__heap_size = ___HEAP_END - ___HEAP_START;

__SP_INIT = ___SP_INIT;

_romp_at = ___ROM_AT + SIZEOF(.data);

.romp : AT(_romp_at)

{

__S_romp = _romp_at;

WRITEW(___ROM_AT);

WRITEW(ADDR(.data));

WRITEW(SIZEOF(.data));

WRITEW(0);

}

# ====== Definitions used by FNET Application. =======

.params :

{

*(.fapp_params)

} > fapp_paramsrom

__VECTOR_RAM = ADDR(.interrupts);

}

As you can notice we put FNET parameters in flash RAM space (see last line) and aligned 'm_data' to 0x200 (512) as requested by USB stack.

But we encountered another "little" problem we didn't face before in our TCP send/receive experiments: we manage to send only 10 bytes to a TCP port, not more, despite we charge a char array buffer with more, and we provide the correct size to send.

Here's some relevant code:

char g_curr_send_buf[] = "Ciao Amiga!!!"; // setting send buffer: 13 bytes plus end-of-string character

[other code...]

size = sizeof(g_curr_send_buf);

send_res = send(socket_foreign, (char*)(&g_curr_send_buf), size, 0);

In the omnipresent Hercules program running on PC :-) we got just "Ciao Amiga" continously, no "!!!".

I have tried and unplesant FOR cycle send 1 byte at time running for 'size', but I got mix-mashed output on Hercules side (eg. Ciao AmiCiao Amiga io Ami...).

Any clue regarding this?

I checked send buffers:

#define FNET_CFG_SOCKET_TCP_TX_BUF_SIZE

(2 * 1024)

Am I missing some very basic setting?

Thanks a lot for any help!

Luca O. \8^)

lucaognibene · ‎01-13-2014

Hello again!

Just wanna tell you I was somehow wrong: my colleague managed to send more than 10 bytes via TCP with the same board and FNET (running on a K60DN256Z).

My code is almost the same as his, but I have to check carefully some parameters...

Sorry for the inconvenience.

Cheers,

Luca O. \8^)

ARQuattr · ‎10-29-2013

I would like to use the FNET stack (specifically the bootloader) with a GSM module, which I access via the UART. I'm using a Simcom SIM900 and it uses AT commands to configure and connect, and offers a 'transparent' mode with which, as the documentation states, "All received data from the serial port will be treated as data packet to be transferred later...", but to establish the connection requires opening a port on the remove server first through AT commands. Is it possible to somehow open the port and then pass over communications to FNET?

Is this possible? Any advice on how to integrate this, or where to look in the stack?

Thanks,
Angelo

butok · ‎10-30-2013

Hi Angelo,

Sending AT command is relatively easy. Initialize a serial port, write AT commands to it and read/check a response.

The challenge is the data communication. You should implement PPP protocol set. Implementing it from scratch is very big task.

ARQuattr · ‎10-31-2013

Andrey, thank you, yes I already use this module for communicating with a server by AT commands, so I have no problem making a connection to a server port and sending or receiving packets. It's getting FNET working with it from that point I'm not sure about. When you say to implement PPP, is this something that is already supported by FNET, i.e. can I add PPP below TCP/IP? Or is this what you mean about having to write from scratch?

butok · ‎11-01-2013

http://en.wikipedia.org/wiki/Point-to-point_protocol

You should implement it from scratch, or reuse it if you will find/have a refernce with GPL or LGPL license.