I'm using TCPNET and the RTX kernel on an STR912 ARM9.
A simple question first: can TCPNET be configured to respond to a broadcast PING?
Second, I have noticed that sometimes the response time to PINGs gets erratic and long. Normally the response time is ~1ms, but sometimes (for no reason I have been able to debug yet) the response times go up to 1 or 2 seconds (frequently almost exactly 1 or 2 seconds).
The only cure seems to be to power-cycle my board. This happens both on my own board and on an STRB9 from Keil. When I was running the http demo I noticed that when the ping time goes up, the HTTP response also becomes very slow. What is happening?
Christopher Hicks ==
NORMAL:
hiss:~# ping 192.168.2.12 PING 192.168.2.12 (192.168.2.12) 56(84) bytes of data. 64 bytes from 192.168.2.12: icmp_seq=1 ttl=128 time=1.03 ms 64 bytes from 192.168.2.12: icmp_seq=2 ttl=128 time=0.967 ms 64 bytes from 192.168.2.12: icmp_seq=3 ttl=128 time=0.998 ms 64 bytes from 192.168.2.12: icmp_seq=4 ttl=128 time=1.00 ms 64 bytes from 192.168.2.12: icmp_seq=5 ttl=128 time=0.908 ms
SOMETIMES:
hiss:~# ping 192.168.2.12 PING 192.168.2.12 (192.168.2.12) 56(84) bytes of data. 64 bytes from 192.168.2.12: icmp_seq=1 ttl=128 time=352 ms 64 bytes from 192.168.2.12: icmp_seq=2 ttl=128 time=2001 ms 64 bytes from 192.168.2.12: icmp_seq=3 ttl=128 time=1940 ms 64 bytes from 192.168.2.12: icmp_seq=4 ttl=128 time=941 ms 64 bytes from 192.168.2.12: icmp_seq=5 ttl=128 time=1001 ms 64 bytes from 192.168.2.12: icmp_seq=6 ttl=128 time=1186 ms 64 bytes from 192.168.2.12: icmp_seq=7 ttl=128 time=1011 ms 64 bytes from 192.168.2.12: icmp_seq=8 ttl=128 time=510 ms
Hi Andrea
I have ammended the driver I was using (LPC23_EMAC.C Rev 3.05) as provided with MDK3.11 to include the extra While loop in the Ethernet Interrupt handler as you suggested. My initial testing indicates that you are correct with regard to the case of the old driver ignoring the reception of multiple frames - well done.
I have also ammended the EasyWeb demo provided with the MDK3.11 to run with the RL-ARM RTOS. This demo does not use the same LPC23EMAC.C Ethernet driver. Instead it uses a polling mechanism to check the CONSUMEINDEX and PRODUCE INDEX to determine if a frame has been received. I ran this application for a period of 72 hours with typical PING response times of 0.7mS (similar to the timings I am now receiving with the ammended LPC23_EMAC.C driver). These results strengthen your assumptions of the Interrupt driver not dealing correctly with the reception of multiple frames.
Thanks Andrea.
Des
Thank you all for your help. We have fixed the original LPC23_EMAC.c driver. It now works without problems. A fix will be available in the next upcoming RL-ARM release.
If you need an updated driver, please send email to support@keil.com
Franc