Ethernet (W5100) works on Uno but not on Mega1280

Development Tools IDE 1.x
1

UPDATE: The problem was fixed when I tried a different Mega1280 board. So I'm guessing it is a faulty Mega1280 board.

I have two of the new Mega-compatible Ethernet shields based on the W5100 chip. One is connected to an Uno and the other to a Mega1280. I'm using the Arduino-22 software on Windows XP. The WebServer example works fine on the Uno but not on the Mega1280.

I only made one change to the code:

  1. Set pin 4 as output and high. This is recommended in the documentation if you are not using the shield's microSD card. I think it basically makes sure the microSD card doesn't try to talk on the SPI bus. (It also doesn't work even if I don't include this code.)

Inserted into setup()
pinMode(4, OUTPUT);
digitalWrite(4, HIGH);

The only difference between the Uno and Mega1280 code was that I changed the MAC and IP addresses to be different. When I compiled for Mega1280, I had it set as such; and similarly for Uno. I used the appropriate COM port for each one.

I've tried a hundred different things, including wiring various 10-13 pins to 50-53, as was necessary in older shields. From what I've read, that shouldn't be necessary though. I also tried swapping the shields/cables/etc.

I also tried to use the nmap program to do an arp-ping in order to see if the MAC address part was working. nmap said the host wasn't up, but I honestly didn't really know what I was doing.

I would greatly appreciate any suggestions.

Addendum: On the Uno I can telnet to port 80 and get the webpage; but the connection is not established for the Mega1280. (I mention this because this link http://arduino.cc/forum/index.php/topic,57972.0.html discusses a problem that sounds similar, but his network connection works.)

Also, I realized it would probably have been better to submit my post to the Networking forum section. If a moderator wants to move it, I certainly wouldn't mind.

2

I know nothing of the subject but did a quick search on W5100 shields and there was this section shown:

Compatibility
Compatible with official Arduino models and equivalent boards such as our TwentyTen that use the standard shield header format. Tested and confirmed to work with many variants, including Duemilanove, Uno, TwentyTen, Pro, Seeeduino, and Netduino. Not directly compatible with the Arduino Mega, although it can be made to work using the same modification as the official Ethernet shield discussed here: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1239058804/0

So you might want to read that posting link to see what the compatablity problem/fixes are for using with mega boards.

Lefty

3

I see you found Thomas33's post. I did too. Too bad he didn't post his solution.

But the fix for me was here:
http://arduino.cc/forum/index.php/topic,68624.0.html

Maybe it will help you too.

@retrolefty: I guess I am still the lead dog.

The bug and fix have been reported.
http://code.google.com/p/arduino/issues/detail?id=605&start=200

Add: If the bug report sounds a lot like "we've been lucky until now", you are correct. There is one more bug still in the ethernet code that is waiting to bite all of us some day. On that one, we are still lucky. I've got it out and will report it later when I have checked it out better.

4

SurferTim:
But the fix for me was here:
http://arduino.cc/forum/index.php/topic,68624.0.html

Thanks for the help! I tried to wade my way through the posts, but I'm still unclear about what specific steps I need to take in order to fix the problem. I tried replacing the __SOCKET_REGISTER16 macro, but it still doesn't work. Is there something else I should do?

I'm also confused about whether the patches apply. At one point you seemed to indicate that your problem occurred on Linux but not on Windows (I'm using Windows, although I would happily reboot to Linux if it made my problem go away). Also, it seemed that the problem occurred in avr-gcc 4.5.x, but perhaps not in the 4.3.2 that the Windows version of Arduino-22 ships with.

5

This code determines if the error I corrected exists on your system. If the 'available' always shows larger than 256, then the fix should work for you. The ip I selected is google. The pin 13 LED should blink once per second. Change the ip, subnet, and gateway to conform to your network.

#include <SPI.h>
#include <Client.h>
#include <Ethernet.h>
#include <Server.h>
#include <Udp.h>

byte mac[] = { 0x90, 0xA2, 0xDA, 0x00, 0x59, 0x67 };  
byte ip[] = { 192, 168, 2, 2 };    
byte gateway[] = { 192, 168, 2, 1 };
byte subnet[] = { 255, 255, 255, 0 };
// www.google.com ip
byte server[] = { 74, 125, 113, 103 };

Client client(server,80);

int loopCount = 0;

void setup()
{
  
  Ethernet.begin(mac, ip, gateway, subnet); 
  Serial.begin(9600);
  pinMode(13,OUTPUT);
  
  if (client.connect()) {
    Serial.println("connected");
  } else {
    Serial.println("connection failed");
  }
}

void loop()
{
  int thisByte;
  int newCount = 0;    

  if(client.connected())
  {
    newCount = client.available();

//    if(newCount > 0) thisByte = client.read();    

    Serial.print("Available ");
    Serial.println(newCount, DEC);
  }
  else if(loopCount == 0)
  {
    // if not connected, attempt to reconnect
    client.stop();

    Serial.print("Connecting...");
    delay(10);
    
    if (client.connect()) {
      Serial.println("ok");
    } else {
      Serial.println("failed.");
      delay(10);
    }
  }

  // heartbeat
  if(loopCount > 8)
  {
    digitalWrite(13,HIGH); 
    loopCount = 0;
  }
  else
  {
    loopCount = loopCount++;
  }

  if(loopCount == 4)
  {
    digitalWrite(13,LOW); 
  }

  delay(100);
}
6

SurferTim:
This code determines if the error I corrected exists on your system. If the 'available' always shows larger than 256

I don't even get that far. I get "connection failed". (I have appropriate network settings.) The ethernet shield LEDs show LINK, 100Mbps, FullDuplex. Since you've read through the network code, do you have any ideas for how I could test subsystems? If I don't have any concrete options, I might just punt and buy another Uno; I'd prefer not to, but I have a deadline for my project.

I keep returning to the fact that it works on the Uno but not on the Mega1280. The only spot I see where the code differs is in the initSS, setSS, resetSS code. Besides the different pin-number assignments and memory capacities, does the Atmega328 platform differ from the 1280 in ways that would affect the compilation?

I also read through the bug report a bit more. I can't argue with your finding that it fixed your problem, but it surprises me that the conversion from uint8_t (return of readSn()) to uint16_t (variable "res") would leave uninitialized high-order bits (whereas I would expect that behavior when casting uint8_t* to uint16_t*). That would require extra steps to clear those bits in the common case of legitimate type casts.

7

Legitimate type cast. That is the problem here. If you take a look at w5100.h and socket.cpp, there are type casts in abundance. That is where I have already found another type cast that will some day cause problems.

I use type casts very sparingly. But when changing from one data type to another, like this, I use it. I know how to clear the upper byte.
Shift 8 bits left
or
&0xFF