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
May you have lost the transmit interrupt, so that the stack only can send when it receives a packet and gets a receive interrupt?
In this case, the ping answer would hang in the stack until a new ping is received. In the same way, an http answer will hang until a new request or something else is seen.
Hi Christopher,
We experience a very similar behaviour here with a LPC2368 ARM7 based board.
I didn't do tests with the http demo, but only with our firmware. I was investigating on relationships with other task in our application, but your post suggests me that the problem could be somewhere else.
Did you get a deterministic path to make the ethernet performance fall down? As far as I can see I can make it happens with the following procedures: 1. by enabling tasks that require to run an ISR at relatively high frequency (every 20ms) 2. more simply by stopping the application anywhere with the debugger and making it run again a while after.
An interesting thing I noticed today is this: by disconnecting the eth cable while stopping the application and putting it back in place after restarting, the problem won't show up! If I just let the cable connected with the CPU stopped for a while, the slow down immediately appears, as soon as the application starts again.
I confirm that, once the performance decreases, nothing but a power cycle can put it back to full speed.
What version of TCPNet are you using? Are you targeting the http demo to the RTX RTOS or compiling as a standalone app?
I don't know enough of the LPC2368 architecture, but... Could this be due to some misconfiguration in the CPU internal MAC or the DMA module used by the MAC?
Does anybody out there have the same problem?
TIA
View all questions in Keil forum