KSDK ethernet example results in crash

[peterruesch]

Hi,

i wanted to try the lwip + freertos example coming with KSDK 1.3 on the TWR-K65 + TWR-SER module.

The example is located in /opt/Freescale/KSDK_1.3.0/examples/twrk65f180m/demo_apps/lwip/lwip_tcpecho_demo/tcpecho_rtos/tcpecho_freertos/kds

Basically, it works. you can ping the board.

but as soon as i put it under some stress, it reliably stops working.

I'm using echoping to send some traffic to the target.

echoping -s 50000 -n 20 -w 0.1 192.168.2.102

this should send a message of ~50k size every 100 ms to the target. repeating 20 times.

but in gets a answer to the echo request only 5-6 times before  the example target stops responding.

Sometimes the program just gets trapped in the DefaultISR Handler or it just does not respond on ethernet requests anymore. It just refuses to react even to normal ping requests.

this happens in release and debug builds.

attached is a wireshark session of the procedure. Can anyone recreate this problem and suggest a fix for it ?

best regards.

Peter

Original Attachment has been moved to: echoping_filtered.pcapng.zip

[DavidS]

Hi Peter,

I'm running your example and if I have the "-w 0.1" it does stop working usually during the 3 transfer of 50,000 bytes.

If I use the command without "-w 0.1" (i.e. " echoping -s 50000 -n 10 192.168.0.222") it works.  Or if "-w X.Y") is greater than 2.2 but guessing this value is network dependent.

The echo example is simple and not setup to handle errors is my assumption.

So don't have an answer but some additional data points.

Regards,

David

PS

Thanks for the echoping mention.  I didn't have that tool but now do!

[peterruesch]

it seems that tselmeci​ is working on a fixed ethernet driver.:smileyhappy:

FreeRTOS Real Time Kernel (RTOS) / Discussion / Open Discussion and Support:TCP/IP stack performance...

[hirentailor]

Hello Peter Ruesch,

I am facing same problem.  Under stress testing, tcpecho_rtos demo stucks in defaultISR.

Did you find any solution for this? 

Regards

Hiren Tailor

[peterruesch]

me, once again...

I was writing to the lwip users mailing list to ask if they can tell me something about the occurring problem.

here is what they wrote:

Your Stack Trace Locks like your Ethernet Driver or ethernetif.c is not well implemented. Usually you should pass the received packet from the IRQ context to a task, which calls LWIP.

www.freertos.org/xTimerPendFunctionCallFromISR.html

Or use a queue for this. But be careful, the IRQ should only notify the existence of new packages and in the task you need to read as long as there is data available otherwise you will loose packages on heavy load.

Re: [lwip-users] illegal RTOS API call from ethernet receive interrupt

Could you please provide a properly working ethernet driver?

[peterruesch]

one problem might be, that the lwip stack tries to take a semaphore from within the Ethernet Receive ISR context.

this action blocks because the semaphore take action is not allowed from a ISR context and triggers a runtime assertion which freezes to system.

so... something wrong with the calling of FreeRTOS API funcitons...

[peterruesch]

David,

I want to use the example for a basis to start the development of an application. If one can kill the product simply by sending frequent packets, how embarrassing is this ?!

I mean, what is your suggestion here? "Try to send packets at a lower rate"? NO!

You cant even measure the ethernet performance with this example. This is what i actually wanted to do...

so could you please provide a working example for a lwip and FreeRTOS.

Glad to provide you some tools to test your examples :smileywink:

Happy to hear from you!

Best regards

Peter

[DavidS]

Hi Peter,

I too wish we have more performance test code for as many of the on-chip modules as possible and have passed that feedback on.  Thank you for it.

With respect to your lwip echo issue, I am not expert in Ethernet but simply was testing the example under different conditions.  I do not know what the "-w 0.1" is doing to halt operations on the device side but will pass this information on to KSDK engineers as hopefully a test case they can include and design examples to as method of process improvement.

So again you feedback is helping to make KSDK better.  Thank you.

Regards,

David