SPI woes - Ethernet shield vs. everything else

Hi Graham,

Yes I did try setting all the pins high but the problem remains unchanged. The only pin that makes any difference is setting pin 10 to output. That just kills the Ethernet card immediately, at initialisation, regardless of whether I then set the pin to high...

Initialising display...
Initialising SD card...
SD card initialised OK
Initialising Ethernet...

...and it's dead.


Hi John,


Specifically which Ethernet cards do you have, and which ethernet library are you using?


I have the standard "Ethernet R3" shield and I've also tried the "Ethernet Shield 2". Both behave in exactly the same way. The library is the one installed with the Arduino 1.6.8 IDE. Version 1.1.2 according to the library.properties file and that seems to be the current version on GitHub.



Maybe worth trying this one then, since it mentions now works at SPI 42Mhz, which is also oddly enough what the Font IC runs at....


Disappointing! Exactly the same results with the WIZ library. I have checked that the new library is definitely being compiled in (via a Serial.print within the library) and I've configured it per the instructions to use the R3 Ethernet shield. I have yet to try it on the Ethernet 2 shield but it's not looking promising.

I must be doing something stupid but I cannot for the life of me work out what it is.


** Update: exactly the same results with the Ethernet 2 card. :(

I am running out of ideas.....

Oh by the way, after my lengthy reply to your lengthy reply, STM32 stuff..... there will very soon be a DUE replacement with almost the exact hardware!! Now THAT will be nice.... do a search for Arduino Star OTTO.


Thanks for trying Graham. The Star OTTO (what an odd name) does indeed look interesting, as does the EtherDue (if I can ever get a reply from the supplier). No doubt each will bring all sorts of new things that don't quite work as expected...

Is this 5 inch TFT using RA8875?

The RA8875 has a known problem where it can not tri-state its MISO pin. A separate tri-state buffer is usually required if the RA8875 is used together with any other SPI chips.

Sometimes it can work, when another chip also drives MISO, but the result is an incorrect voltage for logic high and low, so whether it works depends on the MISO receiver circuitry in your Arduino. I've heard reports of 2 RA8875 (but not 3) working on Mega, but failing on Teensy 3.2. No idea about Due.

Star Otto looks like powerful hardware, but it's made by that "other" Arduino. Maybe it'll turn out to be an awesome product, but given their dismal performance on the software side so far (mostly copying everything from Ardiuno.cc with only minor tweaks), might be best to take a wait-and-see approach. The market is already filled with extremely powerful STM32-based boards that don't have good Arduino compatibility.

Hi Paul,

No, John is not using RA8875, it is 5" CPLD.

The problem I gather you are already aware of in passing, SdFat/Ethernet and SPI issues. John and I have been in communication with this issue, but I suggested he contact you directly as your understanding of the SPI library for DUE is clearly much better than mine.

The problem John is having is getting sdfat and ethernet to co-exist, since UTFT_GHL uses the same DMA code used by sdfat, it stands to reason my library will cause the same fatal error. But WHAT is the problem? Are you aware of any way (with transactions or otherwise) of getting Ethernet to not die during a SdFat file write?

We have already tried digitalPin(Ethernet_CS, HIGH); before an SD operation and digitalPin(SD_CS, HIGH) before any ethernet operations, but to no avail, that I am afraid is where my SPI knowledge ends...

Hope you can shed some light on this issue!?




Maybe try using SD instead of SdFat?

Ok Thank you.

That doesn't really get to the bottom of the problem, but since nobody appears to want to I guess I am not surprised.



Hi Paul,

Thank you for engaging with us on this. As Graham says, I have the CTE CPLD display and use UTFT_GHL to drive it. I have tried SD and it does indeed work OK with Ethernet. That's what I was originally using but it still leaves the issue of getting the display flash to work as well.

It's still not clear to me whether the issue is in the Ethernet library or in SdFat/UTFT_GHL. I suppose Graham could try using the SD SPI interface code instead.



ghlawrence2000: That doesn't really get to the bottom of the problem

What if the problem is a resource conflict between SdFat and one of these other libs? If using SD makes things work, why can you accept that as a solution?

Or do you expect "get to the bottom of the problem" to involve someone actually digging into the low-level details of these libs and editing them to work together?

I regularly do that for Teensy boards, but I'm not going to do it for Arduino Due. Maybe someone from Arduino who supports Due might be interested in such work?

OK Paul. I am sorry to have troubled you.


F****ng good job we got to the bottom of the problem then John, with that level of help? I am inspired by Paul's reaction! Hope you are too? :P



PS, Do you recall what I said about experts needing the same hardware and issues, then they 'might' help you? ..... :( To be honest, I am not surprised...

-1 to Paul

Graham and I have been working on this problem off an on for most of today and we have some partial success to report. By changing a parameter in UTFT_GHL and another, related one in SdFat we have managed to get Ethernet, SdFat and UTFT_GHL to work together properly with IP traffic.

As is so often the case, what we hoped would be a complete fix turns out not to be and there is still a problem when handling UDP traffic. I cannot quite see why what we assume to be an SPI problem would be sensitive to different types of network traffic and it may be that this is merely an artefact of some other problem. The code looks pretty fiendish and as I mentioned in my first post, I am no C expert (most of my programming was done years ago in assembler). Nonetheless, we hope to make further progress in due course.

I would like to publicly thank Graham for his considerable effort on this problem today.


You are very welcome John!! Thanks for the support and assistance you provided too!!



I use an ethernet shield and SD together on a Due. Both work fine.

The secret is D10. Do not set it to OUTPUT. It will lock up the w5100. Use the weak pullup on D10 to disable the w5100. Here is the setup I use that works.

void setup()


  // disable w5100 SPI while starting SD
  digitalWrite(10, HIGH);
  Serial.print(F("Starting Sd.."));

  if(!SD.begin(4)) {
  else {

  Ethernet.begin(mac, ip, gateway, gateway, subnet);



edit: Here is my Due/ethernet shield/SD web server in action.

Hi Tim,

Thank you.

Will be tomorrow or later now before can check notes with John.

We have got to the bottom of most of the problems, now something most peculiar is happening with UTFT after SD writes, whether using the SD or SdFat libraries. Most strange!

I will be the proud owner of a flashy new Ethernet 2 shield in the next few days, so then I can deal with this stuff myself, and not trouble anybody else...



You shouldn't have any problem with the ethernet 2 shield (w5500) if you use the Wiznet library for it. I use it with the w5100 and it works fine on both the mega and Due. https://github.com/Wiznet/WIZ_Ethernet_Library

edit: I just tried the Due with SdFat rather than the standard SD library and it didn't do well. It initializes the SD, opens a file, but won't read from it. ??