K64F ethernet / lwip questions

[sullivanag]

I am currently evaluating the K64f board for use in an embedded system.  We need to continually send small packets over ethernet via tcp, roughly 57 bytes every 20 milliseconds.  I have adadpted one of the examples using the LWIP.  My code runs for varying amounts of time, and then I receive an error on the debug console.  I am using MCUxpresso and SDK.

The error is not always the same.  The last one I received was "unsent_oversize mismatch (pcb->unsent is NULL).  It is always something relating to one of the internal buffers.  I have tried tweaking the various buffs inside the lwipopts.h based on posts in this forum and other sources.  Nothing ever solves the problem, it just delays the inevitable.  I am at a loss as to how to correct this problem.  It appears the K64F is having trouble keeping up with ACK'ing the data.

I noticed the K64F board negotiates a 10M connection to the switch vice 100M.  Other posts I have found indicate the driver being used for the ethernet is polling vice being interrupt driven.

I really do not have a specific question.  What I would like to know is if the K64F can sustain the data rate we require?  Are there better ethernet drivers available for this board, or is the one provided in the tcpecho sample good enough?  I do not have much experience wrtiing code at this level.  If anyone can help shed some light, or point me in the right direction that would be great.

I can provide more information if needed.  

[mjbcswitzerland]

Hi Andrew

If you don't find a quick solution to your problem just use the uTasker project (either the open source version on GitHub  or the supported professional version if you have higher demands). As well as immediate optimised operation on K64F based boards It allows you to simulate the K64 and its Ethernet (plus TCP/IP stack) in real time in VisualStudio. It has low Flash and RAM footprint (eg. its HTTP server can support > 2'000 simultaneous connections at high speed).
There are various binary files at the links below showing various features of its integrated TCP/IP stack (also with seamless integration into its USB stack with RNDIS).

Regards

Mark

Complete K64 solutions, training and support:http://www.utasker.com/kinetis.html
Kinetis K64:
- http://www.utasker.com/kinetis/FRDM-K64F.html
- http://www.utasker.com/kinetis/TWR-K64F120M.html
- http://www.utasker.com/kinetis/TEENSY_3.5.html
- http://www.utasker.com/kinetis/Hexiwear-K64F.html
Docs at http://www.utasker.com/docs/documentation.html

[mjbcswitzerland]

Hi

I have attached  a FRDM-K64F binary that tests the case that you are interested in.

1. On the OpenSDA VCOM UART connection at 115kBaud (or on the K64's USB) there is a command line interface. Use menu '1' to configure the IP - whether it uses DHCP, fixed IP address etc. and save it. The default is 192.168.5 in case that already is suitable for the local network.
You can also control the Ethernet speed and duplex modes if you like - and it will show you the link speed and characteristics each time it connects or changes.
2. Type "quit" in the initial command line interface to allow a new connection to be established on Telnet instead.
3. Establish a Telnet connection to the board on its IP address (eg. from TeraTerm or from a Windows DOS shell).

4. In the same menu use the command "20ms" to start sending 57 bytes over the same TCP connection every 20ms. This will continue forever unless you type in "quit", in which case the output will switch to the UART connection. If you connect the K64's FS USB connection (which emulates as USB-CDC) and hit the enter key it will then switch the same output to this link.

While any of the connections are in operation you can also ping the board, connect to it via FTP or HTTP or Modbus TCP to see that the connection and operation is not affected by other services.

Note also that 57 bytes every 20ms is only 2'850 Byte/s or 22'800 bits/s. Therefore also the UART keeps up with this at 115200 Baud without any difficulty. The processor is in fact sleeping for 99.9% of the time doing such work (most operation is DMA driven) so there is no reason for any limitations with such requirements as the processor is doing extremely little work.

Regards

Mark

Test code reference:

            if (E_TIMER_TCP_TX == ucInputMessage[MSG_TIMER_EVENT]) { // on each 20ms timer event
                static CHAR cTestValue = '0';
                CHAR cBuffer[57 + 1];
                uMemset(cBuffer, cTestValue, (sizeof(cBuffer) - 1)); // construct a test pattern
                cBuffer[sizeof(cBuffer) - 1] = 0;
                fnDebugMsg(cBuffer);   // send to present output handle (Telnet TCP, UART or USB-CDC)
                if (++cTestValue > '9') {
                    cTestValue = '0';
                }
                uTaskerMonoTimer(OWN_TASK, (DELAY_LIMIT)(0.02 * SEC), E_TIMER_TCP_TX); // repeat every 20ms
            }

// Switch output to Telnet
DebugHandle == NETWORK_HANDLE;
// Switch output to UART
DebugHandle == SerialPortID;
//Switch output to USB-CDC
DebugHandle = USB_Handle;

‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

[sullivanag]

Mark,

Thank you so much for the help!  You really went above and beyond.  I'm more of an application developer, and do not have much embedded experience other than with VxWorks.  I have some other fires to put out here at my office, but I will try out uTasker with your test app in a day or two.  I'll report back with my findings.

Regards,

Andy

[sullivanag]

Hi Mark,

It has been a while since you helped me with my issue.  Since then I have had the chance to download the opensource uTasker project and evaluate it for my use.  I was successful at developing my own application using uTasker, and it is working great.  While testing I was even able to send data over LAN at twice the rate I need.

The use of uTasker has saved me a considerable amount of development time and effort.  I have found uTasker to be very feature rich, an excellent product!  We use Kinetis boards in our lab for various little projects, uTasker will certainly be something I will use for my future development.

Thank you for your help, it is very much appreciated.

Andy

[mjbcswitzerland]

Hi Andy

Thanks for the feedback and I am happy to hear that you could achieve your goals and save time in the process (you may also have noticed that the uTasker TCP/IP code size is about half that required by lwip as well as giving higher performance).

Although not everyone is prepared to test the project since it is not as well know as some others, those that do are typically pleasantly surprised with its features, efficiency and quality - and how it allows products to be developed faster and easier than when other libraries are chosen.

Regards

Mark