Go Down

Topic: SD Card - MISO doesn't release [Bad MISO, Bad MISO!!] (Read 16730 times) previous topic - next topic

oric_dan

I [was] having the same problem as described in this old thread by MarkT [from 15 Sept 2011]. Why hasn't this problem been resolved in the IDE SD library?

http://forum.arduino.cc/index.php?topic=72446.0

For reference, all of the example sketches in the SD library run fine, so the SD Card is formatted ok, and has files on it to be read, my Arduinos work, the CS pins are set appropriately, D10 is set to OUTPUT, &etc, &etc, &etc.

Notes:
- IDE v.1.0.5
- SanDisk Micro SD card, 4GB and 8GB
- tried on 2 different UNO boards, one board with SD socket built-in,
   and also using Sparkfu SD shield [CS=D8].

I finally fixed the problem by tracking down the 3-YO thread, and following MarkT's comments, by adding the following commands at the end of the example sketch, eg CardInfo,
Code: [Select]
 
  digitalWrite(8,HIGH);
  SPI.transfer(0xAA);


Why hasn't this problem been resolved in the IDE SD library?

Why isn't there a note on the Arduino SD pages telling how to fix it?

SurferTim

I use the SD card with the ethernet shield and the wifi shield. Both work without that "fix".

oric_dan

I use the SD card with the ethernet shield and the wifi shield. Both work without that "fix".
I was hoping someone would point that out. Why there, but not for this case? Can you test an SD card without ethernet present?

SurferTim

#3
Nov 01, 2014, 10:54 pm Last Edit: Nov 01, 2014, 10:57 pm by SurferTim
What do you mean "without the ethernet present"? I tested the SD cards by disabling the ethernet or wifi SPI and they worked ok. I don't have a SD module or shield without any other function.

I hear of a lot of people here having trouble with SD modules that do not have a logic level converter.

edit: If the MISO line was going to be a problem, it would be when working with another SPI device like the w5100 or HDG104.

fat16lib

Quote
Why hasn't this problem been resolved in the IDE SD library?
This problem impacts few devices since few send data to the master on the first byte of a transaction.  The SD MISO goes high-Z after the first transfer.

Also, the old version of SdFat in SD.h has many other unfixed bugs.  This is why I added an SD.h compatible API to SdFat http://forum.arduino.cc/index.php?topic=274784.0.

I fixed SdFat just after MarkT's post.

oric_dan

Quote
This problem impacts few devices since few send data to the master on the first byte of a transaction.
Hmm, I should think this would have affected pretty much everyone who's ever tried using the IDE SD library with an SD card. They probably just didn't know MISO was breaking bad.

But thanks for the updated files - will take a [very LONGGGGG] while to go through them. Is there a chance the IDE libraries will be fixed one day?

SurferTim

#6
Nov 01, 2014, 11:13 pm Last Edit: Nov 01, 2014, 11:39 pm by SurferTim
Quote from: fat16lib
This problem impacts few devices since few send data to the master on the first byte of a transaction.  The SD MISO goes high-Z after the first transfer.
That is only during a SD transfer, correct? If the SD SPI slave select is HIGH, the MISO line should stay high-Z during another device SPI transfer. It does (apparently) when working with the w5100 and HDG104.

edit: Just ran a test with my web server code. It reads 64 bytes at a time from the SD card before sending the array to the w5100. I checked the level of the SD slave select (D4) after every call to myFile.read(), and it was always HIGH. That means if the MISO line is malfunctioning, it would be a hardware problem with the SD card itself, not the SD library.

That test was using IDE v1.0.5.

fat16lib

Quote
I checked the level of the SD slave select (D4) after every call to myFile.read(), and it was always HIGH. That means if the MISO line is malfunctioning, it would be a hardware problem with the SD card itself, not the SD library.
No, SD.h has a bug.  I wrote the bug and fixed it in newer versions of SdFat.

You must send clocks to an SD with chips select high to cause the SD card to release MISO.  SD cards release MISO quickly, after one or two clocks (I don't remember which) so even devices that send one or two don't care bits work OK, like some ADCs.

I think MMC cards need a whole byte of clocks.

SurferTim

Quote
You must send clocks to an SD with chips select high to cause the SD card to release MISO.
So you must send an additional byte to the SD to get it to release the MOSI line after the slave select goes HIGH? Is that one particular card, or all cards? Do you have a link to a reference covering that?

fat16lib

Quote
Is that one particular card, or all cards? Do you have a link to a reference covering that?
It is true for all cards.  Here is a link http://elm-chan.org/docs/mmc/mmc_e.html.  

See the section "Cosideration on Multi-slave Configuration"

The image shows release of MISO for SD and MMC cards.  See the right side where CS is high. The SD releases after one clock and the MMC after eight.

The left side shows how clocks are needed after CS is low before checking MISO for busy.

SurferTim

I just found that same requirement on the SanDisk data sheet. Thanks!

That gets you karma +1

oric_dan

What do you mean "without the ethernet present"? I tested the SD cards by disabling the ethernet or wifi SPI and they worked ok. I don't have a SD module or shield without any other function.
What I was meant was to see if you couldn't repeat the problem on a board "without" ethernet on it.

Quote
edit: If the MISO line was going to be a problem, it would be when working with another SPI device like the w5100 or HDG104.
I imagine they found and patched the problem in the ethernet library when writing the code to control the W5100 chip. It would have been immediately apparent that the SD card was not releasing MISO. That's how I found it - by trying to operate the SD card and RFM radios off the same SPI port.

Bill [Greiman] definitely deserves a few karmas for building the entire SD card thing, but I'm also gonna give MarkT a few just for finding the problem and pointing out a fix for it ----> already 3 years ago.

I'm still totally PO'ed this hasn't been fixed in the IDE after all this time. Jeez Louise.


SurferTim

#12
Nov 02, 2014, 03:48 am Last Edit: Nov 02, 2014, 04:06 am by SurferTim
Quote
I imagine they found and patched the problem in the ethernet library when writing the code to control the W5100 chip.
I am pretty familiar with the w5100, and I do not believe it has the MISO problem. It's timing shows when the slave select goes HIGH, the MISO line is released (high-Z).

That is why I was surprised to see that with the SD card. I haven't seen any other devices that do not release the MISO when the slave select goes HIGH.

Seems like a waste of time to send another byte every time I want to write or read one byte. Is this the "fix"?

edit: I checked the SPI timing data for the w5100, and it does release the MISO line when the slave select goes HIGH. It requires no additional clock cycles.

oric_dan

Alright, I dug out my ethernet shield, plugged it into my UNO board, and compiled SD example CardInfo. The shield uses D10 for the W5100 CS and D4 for the SD card, and D10 is apparently not being exercised by the CardInfo sketch.

Lo and behold, MISO stays HIGH after running the sketch. And adding SPI.transfer(0xAA) at the end of the sketch fixes the problem. Try it yourself, and see what happens on your board.

SurferTim

#14
Nov 02, 2014, 01:34 pm Last Edit: Nov 02, 2014, 02:24 pm by SurferTim
If what fat16lib posted is true, then all that would be needed is this:
Code: [Select]
digitalWrite(SCK,HIGH);
digitalWrite(SCK,LOW);

I'll try this first.

edit: That didn't work. Your fix worked, and this worked:
Code: [Select]
SPI.setDataMode(SPI_MODE3);
SPI.setDataMode(SPI_MODE0);

I don't know which is faster.

Go Up