Problem With lwIP Demo On AT91SAM7x256-EK

Kernel
1

nobody wrote on Tuesday, July 18, 2006:

I have not been able to connect to the HTTP server in the lwIP demo. I suspect that the root of the problem is ‘operator error’ (*ahem*), so I’ll list what I’ve been trying and perhaps someone can help me see what I’m doing wrong.

-----

I’m using the AT91SAM7x256-EK with the CrossConnect programmer. The way I understand it, this is the same hardware setup as the one Richard describes on the page for the lwIP demo.

I connected the programmer’s USB cable from the board to a USB port on the back of my Windows PC and connected a crossover ethernet cable from the ethernet port on the board to the ethernet port on a second ethernet card installed in my PC.

I edited SAM7_EMAC.h so that:

* The ethernet address is the default address (0, 0xbd, 0x33, 0x06, 0x68, and 0x22)

* The IP address used by the board is 192.168.0.49

* The gateway address is 192.168.0.3 (this is a BS address, as I’m not interested in talking to different networks)

* The net mask is 255.255.255.0

In SAM7_EMAC.c, I did not edit the value of USE_RMII_INTERFACE (meaning that it is still 0).

As I alluded to earlier, my PC has two ethernet interfaces. One connects to the real network, and the other I use for projects like this. On that second ethernet card, I used the IP address 192.168.0.50, the subnet mask 255.255.255.0, and the gateway address 192.168.0.50 (which shouldn’t signify anything special, if I understand correctly. I haven’t gone out of my way to set up the interface to forward traffic or anything).

I loaded the rtosdemo.hzp file in Rowley CrossStudio and built it. It built with no errors. Then, I connected to the target using the CrossConnect, and selected ‘build and run’. The code built (again), was uploaded to the device, and verified, all with no errors.

I opened HyperTerminal and established a connection with the board (it was COM3 for me) and see the alphabet stream by like it should. The DS1-DS4 LEDs blinked as described on the page for the demo project. The DS6 LED (‘FULL DUPLEX’) was orange, and the DS7 and DS8 LEDs (‘SPEED 100’ and ‘LINK & ACT’) were solid green. When I entered ‘http://192.168.0.49’ into my browser, the DS8 LED blinked once immmediately, and then began blinking rapidly shortly thereafter. The browser timed out and did not bring up a page at all.

I tried examining the ‘status’ of the ethernet connection on the computer, and it (the Windows dialog generated from clicking ‘View status of this connection’) confirmed that packets were being sent and that none were being received. I checked the crossover cable to make sure it was wired correctly. It was. I tried disabling the primary ethernet address (for the real network), and trying again. Still no luck. I tried changing the first segment of the ethernet address to 0x08, and had no success. I tried changing USE_RMII_INTERFACE to 1, but that just made DS6-8 blink simultaneously and intermittently, so I’m guessing that was the board’s way of telling me that I want USE_RMII_INTERFACE set to 0.

The 192.168.x.x network is just the board and my PC, so there shouldn’t be any address conflicts. I also tried using a ‘straight’ cable to connect the board to a hub and using another straight cable to connect the hub to the PC (neither one in the ‘Uplink’ port).

I’m sure that I’m just doing something stupid, or that I’ve overlooked something simple. Either way, I’m out of ideas and would appreciate any input.

Thanks a bunch!

Mike Sheffler

2

rtel wrote on Tuesday, July 18, 2006:

This is a tricky one as you have already tried nearly everything I would have suggested.

The fact that your USB connection and LED’s are functioning as expected show that the program is built and downloaded fine so it must just be a network configuration issue.

The setup you describe (IP address, etc.) sounds fine.  I would stick with 00 being the first octet of the MAC address.

USE_RMII_INTERFACE should be zero, unless you are using one of the very early pre-production boards.

I would have postulated that it was a mix up somewhere between the two network cards, but the fact that you can see the LED’s blink when you expect them to would suggest otherwise.  It might be worth however installing Ethereal (if you have not already, http://www.ethereal.com/).  This will allow you to sniff the traffic on each network interface individually so you can ensure the traffic is going via the correct card.

Some random thoughts, comments:

+Which browser are you using?  I have tested with Internet Explorer and FireFox.

+Can you ping the SAM7X, or is there no response?

+Is it possible to place the card (temporarily and with appropriate IP address) on your primary network?

+Did you make any other changes to the code?  If you created some other tasks for example it is possible that it ran out of heap space so could not create all the server tasks.

A couple of things to try in addition to pinging and Ethereal:

1) In SAM7_EMAC_ISR.c, try setting a break point in vEMACISR().  This will show us whether or not you are getting interrupts from the EMAC peripheral.

2) In heap_2.c, at the end of the function pvPortMalloc() immediately before the return, add the following code:

if( pvReturn == NULL )
{
    asm volatile ("NOP");
}

and set a break point on the NOP.  If the break point is hit then you ran out of heap somewhere (should not happen if the code is not modified).

Regards.

3

nobody wrote on Tuesday, July 18, 2006:

Thanks for the suggestions. I haven’t modified the code at all, which is why I’m so confused.

I’ve tried both Internet Explorer and Firefox, both with no luck. I also tried pinging the board, with no response.

I was actually setting up Ethereal when I went to check on this message, so I’ll see what that has to tell me fairly soon. I can also try putting the board on the ‘real’ network to see if that makes any difference. Thanks for the suggestions as to where I can place some breakpoints.

I’ll try all of this stuff and report back. It *must* be some BS Microsoft networking problem. I have high hopes for what the packet sniffer will tell me.

Mike Sheffler

4

nobody wrote on Tuesday, July 18, 2006:

Oh, yeah, one other, probably silly, question: Should I leave emacETHADDR0 in SAM7_EMAC.h as ‘0’ (no quotes), or should it actually be 0x00 ?

Mike Sheffler

5

nobody wrote on Tuesday, July 18, 2006:

As long as its not character zero (with the quotes ‘0’), then either 0 or 0x00 should be the same.

6

nobody wrote on Tuesday, July 18, 2006:

Hmm. So I set up Ethereal and tried browsing to 192.168.0.49 (the IP address of the board). All I picked up were ARP requests. Basically, my computer just said, “Hey, I’m at 192.168.0.50. Does anybody know who 192.168.0.49 is?” over and over. I never saw any other packets, which seems to indicate the board is not talking at all. A couple of questions:

* Does anyone know why the demo might not respond to an ARP request? Perhaps there is a reason why it wouldn’t accept broadcast traffic, and so never saw it?

* Does anyone know what it means when LED DS8 (LINK&ACT) starts flashing repeatedly with a short period?

I’m going to try out Richard’s suggestions re: break points to see if that offers any insight.

Thanks!

Mike Sheffler

7

nobody wrote on Thursday, July 20, 2006:

I went and tried the breakpoints you suggested. I did break in vEMACISR(), so I’m definitely servicing interrupts related to the ethernet chip. Also, I did *not* break in the suggested block of code for pvPortMalloc(), so I’m not running out of heap.

I set a few breakpoints here and there and I can see that the device recognizes that ARP requests are being sent to it from my computer, but I haven’t been able to figure out yet why nothing is actually going out on the wire. Now, I’ve got another guy working with the same board on a different computer to see if he has the same problems.

If anyone has any suggestions as to how to procede, I’d love to hear your input.

Mike Sheffler

8

nobody wrote on Thursday, July 20, 2006:

How are you connected to the board?  With a crossover cable?

If not, make sure that you’re not connected through a switch, otherwise you wont see all the packets you’re interested in.

I wasted a day pulling my hair out while I was writing our TCP stack wondering why I couldn’t see packets and why it wasn’t working, of course it was, I just assumed it wasn’t because I couldn’t see some of packets on my host machine!

If you plug into a hub at least you know you’ll be seeing all packets to and from the device.

9

nobody wrote on Friday, July 21, 2006:

I’m sure you will have tried this already but I will say it anyway.

Place a break point in the Tx complete interrupt in the same ISR.  If you hit the break point then the sam things it has sent something which never made it onto the wire if you cannot see it with ethereal.

If the interrupt is never is never seen then set a break point in lEMACSend within sam7_emac.c.  You should see the arp response going to the dma if nothing else.

Some time back there was an issue with the mac address being sued where the sam would reply to the arp happily, but the router between the sam and pc did not let the repyly through.  So depending on which side of the router ethereal was placed you would or would not see the arp response.