DUE + Ethernet Shield for a WEB sever - SDFat.h problem - Ver 1.8.3

Hey Guys,
First time poster... I've been writing a WebServer (with SDFat.h) with Mega and needed to port it to DUE. When I ran the same program on a DUE it didn't work, as in the Device went as far as pinging and finding the file on the SD card but no further. Assuming its my code (which ran perfectly on Mega) I loaded the WebServer sample sketch to the DUE.

It did work fine, so to diagnose then I added SD.begin after the server to check the SD card, sure enough, found the SD card but it showed

server is at 255.255.255.255

After reading few posts I switched the setup order of Ethernet and SD (to check), then I got,

server is at 0.0.0.0.

Then went on to read few more posts and did some checking with driving pins 4,10, 53 high and low. But whatever the situation once the SD is initialized, I cannot get the Ethernet to work, its like its forced on the SPI bus.

Lastly I tried the official SD.h and it worked, the reason I want SDfat is its support for long file names.

My testing code,

#include <SPI.h>
#include <Ethernet.h>
//#include <SD.h>
#include <SdFat.h>
SdFat SD;

byte mac[] = { 0x90, 0xA2, 0xDA, 0x0E, 0xCA, 0x2F }; //Copied from internet
byte subnet[] = { 255, 255, 255, 0 };
byte gateway[] = { 192, 168, 8, 1 };
IPAddress ip(192, 168, 8, 123);


// Initialize the Ethernet server library (port 80 is default for HTTP)
EthernetServer server(80);

void setup() {
  // Open serial communications and wait for port to open:
  Serial.begin(9600);
  while (!Serial) {
    ; // wait for serial port to connect. Needed for native USB port only
  }
/*
  pinMode(4, OUTPUT);
  digitalWrite(4, HIGH);  
  pinMode(10, OUTPUT);
  digitalWrite(10, LOW);
  pinMode(53, OUTPUT);
  digitalWrite(53, HIGH);
*/
  Ethernet.begin(mac, ip, subnet, gateway);
  server.begin();
  Serial.print("server is at ");
  Serial.println(Ethernet.localIP());
/*
  pinMode(4, OUTPUT);
  digitalWrite(4, HIGH);  
  pinMode(10, OUTPUT);
  digitalWrite(10, HIGH);
  pinMode(53, OUTPUT);
  digitalWrite(53, HIGH);
*/
  if (!SD.begin(4)) {
    Serial.println("initialization failed!");
  }else{
    Serial.println("initialization done.");
    if (SD.exists("index.htm")) {
      Serial.println("Found a /index.htm file!");
    }
  }
/*
  pinMode(4, OUTPUT);
  digitalWrite(4, HIGH);  
  pinMode(10, OUTPUT);
  digitalWrite(10, LOW);
  pinMode(53, OUTPUT);
  digitalWrite(53, HIGH);
*/
}


void loop() {
  // listen for incoming clients
  EthernetClient client = server.available();
  if (client) {
    Serial.println("new client");
    // an http request ends with a blank line
    boolean currentLineIsBlank = true;
    while (client.connected()) {
      if (client.available()) {
        char c = client.read();
        Serial.write(c);
        // if you've gotten to the end of the line (received a newline
        // character) and the line is blank, the http request has ended,
        // so you can send a reply
        if (c == '\n' && currentLineIsBlank) {
          // send a standard http response header
          client.println("HTTP/1.1 200 OK");
          client.println("Content-Type: text/html");
          client.println("Connection: close");  // the connection will be closed after completion of the response
          client.println("Refresh: 5");  // refresh the page automatically every 5 sec
          client.println();
          client.println("<!DOCTYPE HTML>");
          client.println("<html>");
          // output the value of each analog input pin
          for (int analogChannel = 0; analogChannel < 6; analogChannel++) {
            int sensorReading = analogRead(analogChannel);
            client.print("analog input ");
            client.print(analogChannel);
            client.print(" is ");
            client.print(sensorReading);
            client.println("
");
          }
          client.println("</html>");
          break;
        }
        if (c == '\n') {
          // you're starting a new line
          currentLineIsBlank = true;
        } else if (c != '\r') {
          // you've gotten a character on the current line
          currentLineIsBlank = false;
        }
      }
    }
    // give the web browser time to receive the data
    delay(1);
    // close the connection:
    client.stop();
    Serial.println("client disconnected");
  }
}

This issue has been observed earlier
https://forum.arduino.cc/index.php?topic=146187.0

But SDFatConfig.h has changed since, though I changed below values to "1"

#define ENABLE_EXTENDED_TRANSFER_CLASS 0
#define USE_STANDARD_SPI_LIBRARY 0

I wasn't successful, If any one can, please let me know what could be happening and possibly how to get it sorted.

Thanks in advance.

You can't do this on a Due. There are two CPU pins connected to these. One is the SPI SD and ethernet SS, and the other is D4 and D10.

  pinMode(4, OUTPUT);
  digitalWrite(4, HIGH); 
  pinMode(10, OUTPUT);
  digitalWrite(10, LOW);

You can do this. Use weak pullups to disable the SPI devices.

  digitalWrite(4, HIGH); 
  digitalWrite(10, HIGH);

Do not set D4 or D10 as OUTPUT. This causes a pin conflict that could damage your Due.

Thanks SurferTim, but it didn't help.

On another note, while using SD.h

  Ethernet.begin(mac, ip, subnet, gateway);
  server.begin();
  Serial.print("server is at ");
  Serial.println(Ethernet.localIP());

At this point, after about 40s (while the SD card is in) the WebServer comes online (to the specified IP). But in my Monitor Console shows

"server is at 255.255.255.255"

I tried delaying the read but still the same result. This is just an observation.

You are correct. SDFat library does not work with the Due. SD library does.

SurferTim,
Thanks.

Hope @fat16lib will consider extending the support.

Best regards

I took a brief look at the source code, and it appears it was designed to work with the Due. There are comments in the code that refer to the SAM processor.

The indication I get when running the code is it is not releasing the MISO line on the SD card, which causes the 255.255.255.255 (MISO line held HIGH) response on the w5100. This would normally be caused by the SD slave select is being controlled incorrectly by the SdFat library.

Maybe you should post in the "Storage" section if you haven't already. That is where fat16lib hangs out.

Thanks for the insight...

This explains why, after the initialization of SD nothing else can access the SPI. Hoping that there will be a solution. For the moment the Mega with SD is out-performing the DUE with SD.h

I'll forward this on the Storage...

Regards