Arduino-esp32: SD lib w/ card 'flakey'?

Created on 19 Mar 2017  Â·  104Comments  Â·  Source: espressif/arduino-esp32

heya im using known good hardware, with pullups on the SD CS line, no level shifters, PCB traces not jumpers - but getting 'flakiness' on init/mount

[E][sd_diskio.cpp:99] sdSelectCard(): timeout
[E][sd_diskio.cpp:708] sdcard_mount(): f_mount failed 0x(3)
Card Mount Failed

oddly, it works maybe 10% of the time. once it starts working, it 'keeps' working until a full power reset. if it doesn't work, sometimes hitting software reset helps, but usually not. this is with the SPI library - tried changing SPI speed in SD.begin() without any noticable changes. still investigating ... but making a note here in case others can reproduce

fyi, grabbing the non-optimized SD library works great with no hiccups - https://github.com/adafruit/arduino-esp32/tree/d602169ebcd126c309009e87c1e455f2c892d08f (yeah sorry it got smooshed in the upstream merge so please download the zip from that point to get the library files)

All 104 comments

Hm that is rather strange. I had gazillion of issues with SD_MMC and pullups but none with SD. I just connected the 4 data lines directly to SPI and that was it (I use SD->MicroSD with some wires soldered directly on the pads).
Which pins are you using?

static const uint8_t MOSI = 18;
static const uint8_t MISO = 19;
static const uint8_t SCK = 5;

and cs on any pin really, but im using
#define SD_CS 33

other than the SD card, all other SPI devices ive tested are working perfectly - TFT display, LoRa and RFM radio modules, VS1053

Done :)

looks good - would you like me to re-test?

Sure :) Confirmation is always good, but I was able to reproduce the issue and after the fix, was not able to anymore, regardless of what I did :) I wonder how it was working while I was developing the library?
BTW I tested with your pin configuration

void mountSdCard(){
    SPI.begin(5,19,18);
    if(!SD.begin(33)){
        Serial.println("Card Mount Failed");
        return;
    }
}

hiya - ok so for one of my feather setups, with cardcs on IO 27, it now works every time. on another feather, with cs on IO 14 it still doesnt work :/

Initializing SD card...[E][sd_diskio.cpp:99] sdSelectCard(): timeout
[W][sd_diskio.cpp:452] ff_sd_initialize(): GO_IDLE_STATE failed
[E][sd_diskio.cpp:724] sdcard_mount(): f_mount failed 0x(3)
failed!

maybe on io14 there is another issue? I mean, if SPI is properly configured, and you use pins below 34, the lib itself does not care which pin you have selected. It calls digitalWrite to control SS

yeah unknown. ill investigate more later... :)

Interesting, I am having the same problem. Using the TFT feather wing (CS 14), the SD card works about 50% of the time, using the music maker featherwing, I can't get the same SD card to work at all (also CS 14).

SPI works fine with graphics and music etc, it's just the SD card that is unreliable. If I wasn't having a similar problem (but not as bad) with the TFT featherwing, I'd suspect a bad reader on the music maker.

When I have a chance I'll try it with an M0 or a WICED, see if they work with the music maker.

I'm using the same pins as ladyada, coming from the adalogger featherwing, and I can't get the card to mount at all using:

#include <SD.h>
#include <SPI.h>

void setup() {
  Serial.begin(115200);
  SPI.begin(5, 19, 18);
  if (!SD.begin(33)) {
    Serial.println("Card Mount Failed");
  }
}

SD card works in an M0 datalogger, but no luck with the ESP32 :/

@me-no-dev hmm do you mind if we send you some hardware that you can test with? the SD card works if we use our ported 'arduino-SD-library' but not with the SD library ya'll included. so I think its some init thing?

@ladyada yes please! let's get this fixed :) How are we going to arrange this?

done :)

k email addr deleted, we'll reply

[E][sd_diskio.cpp:724] sdcard_mount(): f_mount failed 0x(3)
@me-no-dev thanks for this lib! Having the same issue here... Thought it was an issue with pull-up resistors at first but it doesn't seem to be. Any updates on this?

Things just showed up :) will solder the boards tonight and prep everything

That sounds exciting

yay - we have a full kit of cousre, and can try replicating any branches/fixes

So do we know where this issue comes from? What can I do to further test?

OK I need more info on the failing cards because here is my first result at this (Feather selected as board) Maybe there are particular steps to follow?:
fullsizerender 21
screen shot 2017-07-07 at 1 36 37 am
screen shot 2017-07-07 at 1 36 50 am

can you try a few times? also try plugging the esp32 into the tft feather and drawing a BMP from SD? that's the only thing i can say we tried and had difficulty with :)

I found with the tft feather, it works about 50% of the time.

I was using the music maker feather also, and it works 0% of the time with that (same pins).

I haven tried the data logger feather at all.

Nick Waterton P.Eng
Sent from my iPhone

On Jul 6, 2017, at 8:15 PM, ladyada <[email protected]notifications@github.com> wrote:

can you try a few times? also try plugging the esp32 into the tft feather and drawing a BMP from SD? that's the only thing i can say we tried and had difficulty with :)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/espressif/arduino-esp32/issues/272#issuecomment-313553163, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ALCUZxuQ_GO000hKaWuJXnqJDjV9h4vlks5sLXiYgaJpZM4MhlJK.

Unsubscribe from GE's commercial electronic messages: http://sc.ge.com/casl-unsubscribe
Désabonner des messages électroniques commerciaux de GE: http://sc.ge.com/
lcap-desabonnement

@NickWaterton Are you referring to the SD card slot on the music maker wing? The VS1053 part works fine using the ESP32-Radio project.

Hit a wall with the TFT Wing :) looking into it :)
@bbx10 yes, SD is the issue

@ladyada I seem to get intermittent issues wit the touch on the TFT as well. Like it will not start every once in a while. Have you notice this?

please try the latest commit :)

And here is a JPEG read from the SD card :)
fullsizerender 22

@me-no-dev Works fine with SD card slot on Feather Adalogger (CS=33) and Music Maker (CS=14).

@me-no-dev @ladyada Our config is custom, nothing to do with Feather. We have an ESP32-DevKitC with a WROOM-32, mounted on our PCB, and we've tried several different µSD/SD modules, all with the same intermittent mounting error:

  • Adafruit µSD module (https://www.adafruit.com/product/254)
  • "normal" SD module with adapter for µSD
  • Bare µSD module with 10k resistors as shown per this documentation
    Again no luck with any of those options. We have only this on the SPI bus.
    We have tried on our PCB and off of it on a breadboard with just the ESP32 and the SD module.

As a side note, when using an SPI-based LED matrix module (MAX7219) on the bus, trying to use the SD module crashes the ESP32. We had to remove the SD from our configuration which is pretty debilitating at the moment.

Any ideas where the solution might be?

@ladyada you said your port of the Adafruit SD library for Arduino boards worked 100%. I haven't seen that port anywhere, just the Arduino version. Do you have it on one of your repos?

@dstoiko did you try the latest commit? It's not a fix just for this board.

@dstoiko also I do not see you mention which pins you are using for SPI

Yes, the VS1053 works just fine. The SD card slot does not. I didn’t build the ESP32-Radio project, I’m streaming Bluetooth audio and playing it via the music maker. I noticed that the SD card slot doesn’t work though, so I tried it on a tft feather I have, and it works about 50% of the time.

I’m not using the sd card slot in my project, but I tried to get it to work (for testing) and couldn’t.

Nick Waterton P.Eng.
National Support Leader - Nuclear Medicine, PET and RP
GE Healthcare

M+1 416 859 8545
F +1 905 248 3089
E nick.[email protected]nick.waterton@med.ge.com

2300 Meadowvale Boulevard
Mississauga, ON L5N 5P9 Canada

GE imagination at work

From: bbx10 [mailto:[email protected]]
Sent: July-06-17 10:14 PM
To: espressif/arduino-esp32 arduino-esp32@noreply.github.com
Cc: Waterton, Nick (GE Healthcare) Nick.Waterton@med.ge.com; Mention mention@noreply.github.com
Subject: EXT: Re: [espressif/arduino-esp32] SD lib w/ card 'flakey'? (#272)

@NickWatertonhttps://github.com/nickwaterton Are you referring to the SD card slot on the music maker wing? The VS1053 part works fine using the ESP32-Radiohttps://github.com/Edzelf/ESP32-Radio project.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/espressif/arduino-esp32/issues/272#issuecomment-313568665, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ALCUZwKnKGDB3NyiMQoukQd5gzT8SGGIks5sLZRUgaJpZM4MhlJK.

Unsubscribe from GE's commercial electronic messages: http://sc.ge.com/casl-unsubscribe
Désabonner des messages électroniques commerciaux de GE: http://sc.ge.com/
lcap-desabonnement

@me-no-dev will try asap. We are using these pins:
MOSI -> 23
MISO -> 19
SCK -> 18
CS -> 5

@dstoiko pins look good! You and @NickWaterton should have success if using the latest code.

hiya!
@dstoiko yah the default SD library worked for us, see it in https://github.com/adafruit/arduino-esp32/tree/d602169ebcd126c309009e87c1e455f2c892d08f
@me-no-dev not sure about the touch screen, it does share SPI pins and also the touch chip is annoying in that it changes modes based on SPI floating voltages on bootup. ill take a look again soon!

@ladyada it's possible that it was caused by the sd card stuff ;) have not seen if happen since SD is working.

awesome :) you also have some fun hardware to try other stuff!

@ladyada yeah! thanks for that! So far I have tried all but the servo shield and is working as expected :)

In our WROVER_KIT fork of the ILI driver, I have implemented direct drawing of bmp and jpeg files and buffers. Maybe you will like to add this for the ESP32 platform to your ILI driver as well?

oh yah that would be awesome. if you can submit a PR and just make sure it still compiles for arduino. jpg decoding would be great and would probably work on other M4/high speed platforms!

There are two ways to do this. ESP32 has the decoder in ROM, but the code footprint is also small.
So either compile it only for ESP32 and use the functions in ROM, or also include the source for other compatible platforms. And I agree ;) definitely not an AVR territory :)

SD is working now correctly.

Just wanted to say the SD card is working correctly on the Musicmaker feather now also.

Working more reliably now, mounting consistently all the time. I still get an error when running the SDCard test code : [W][sd_diskio.cpp:137] sdCommand(): no token received... Any ideas?

Also, in this example the functions that open files dont close() them. Is that normal behavior? I thought you needed to close the file after writing to it at least.

Full serial monitor output:

SD Card Type: SDHC
SD Card Size: 15193MB
Listing directory: /
  FILE: /mode.txt  SIZE: 2
  FILE: /profile.txt  SIZE: 2
  FILE: /._profile.txt  SIZE: 4096
  FILE: /165166M.CSV  SIZE: 33
  FILE: /165166T.CSV  SIZE: 43
  DIR : /.Spotlight-V100
  DIR : /.fseventsd
  FILE: /165166C.CSV  SIZE: 16
  FILE: /165166A.CSV  SIZE: 13
  DIR : /.Trashes
  DIR : /.TemporaryItems
  DIR : /mydir
  FILE: /test.txt  SIZE: 0
  FILE: /foo.txt  SIZE: 13
Creating Dir: /mydir
Dir created
Listing directory: /
  FILE: /mode.txt  SIZE: 2
  FILE: /profile.txt  SIZE: 2
  FILE: /._profile.txt  SIZE: 4096
  FILE: /165166M.CSV  SIZE: 33
  FILE: /165166T.CSV  SIZE: 43
  DIR : /.Spotlight-V100
  DIR : /.fseventsd
  FILE: /165166C.CSV  SIZE: 16
  FILE: /165166A.CSV  SIZE: 13
  DIR : /.Trashes
  DIR : /.TemporaryItems
  DIR : /mydir
  FILE: /test.txt  SIZE: 0
  FILE: /foo.txt  SIZE: 13
Removing Dir: /mydir
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
rmdir failed
Listing directory: /
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
Writing file: /hello.txt
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[E][vfs_api.cpp:265] VFSFileImpl(): fopen(/sd/hello.txt) failed
Write failed
Appending to file: /hello.txt
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[E][vfs_api.cpp:265] VFSFileImpl(): fopen(/sd/hello.txt) failed
Append failed
Reading file: /hello.txt
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[E][vfs_api.cpp:64] open(): /sd/hello.txt does not exist
Failed to open file for reading
Deleting file: /foo.txt
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[E][vfs_api.cpp:135] remove(): /foo.txt does not exists or is directory
Delete failed
Renaming file /hello.txt to /foo.txt
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[E][vfs_api.cpp:96] rename(): /hello.txt does not exists
Rename failed
Reading file: /foo.txt
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[E][vfs_api.cpp:64] open(): /sd/foo.txt does not exist
Failed to open file for reading
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[E][vfs_api.cpp:64] open(): /sd/test.txt does not exist
Failed to open file for reading
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[W][sd_diskio.cpp:137] sdCommand(): no token received
[E][vfs_api.cpp:265] VFSFileImpl(): fopen(/sd/test.txt) failed
1048576 bytes written for 0 ms

Yes you need to close the file if you open it

@me-no-dev I was saying that because in the arduino-esp32 SD test example, file.close() is not used in the file manipulation functions readFile, writeFile and appendFile.

@dstoiko must be error on my end :(

@me-no-dev made a tiny PR for that

thank you @dstoiko merged :)

Wow, five months have been passed and the SD card problem persists now on MH-ET Live ESP32 Minikit.

@capedra wow... that could be so many things... what is "MH-ET Live ESP32 Minikit" anyway? And how come I can mount all of my cards on all of my dev boards?

@capedra well totally different issues ;) and I do not see a schematic where the card is connected or how are you trying to start it.

@capedra

#include <SD.h>
#include <SPI.h>

void setup() {
  Serial.begin(115200);
  SPI.begin(18, 19, 23);
  if (!SD.begin(5)) {
    Serial.println("Card Mount Failed");
  }
}

@me-no-dev
Hello Hristo, I changed the SD.cpp file and I found out that the following if condition is returning false:

if(!sdcard_mount(_pdrv, mountpoint))
>>>>>>>>>>>>>>>>>> !sdcard_mount(_pdrv, mountpoint)
Card Mount Failed

Update: time to debug sd_diskio.cpp file

Edit 2:

f_mount failed 0x(3)

@me-no-dev Apparently, this issue does not happen only with me: https://www.esp32.com/viewtopic.php?t=2592

@capedra how is the card formatted? how big is it? how do you init/mount it? show some code please!

@me-no-dev it's formatted as FAT32. It's a 16 GB card (SDHC).

I did it the exact way that you told me, but I tried another ways too:

#include <SD.h>
#include <SPI.h>
void setup() {
  Serial.begin(115200);
  Serial.println();
  Serial.println();
  SPI.begin(18, 19, 23);
  if (!SD.begin(5)) {
    Serial.println("Card Mount Failed");
  }
}

this same error persists using the codes below:

void setup() {
  Serial.begin(115200);
  SPI.begin(SCK, MISO, MOSI, SS); //SCK,MISO,MOSI,ss
  delay(10);
  if (!SD.begin(SS)) {
    Serial.println("Card Mount Failed");
    return;
  }
}

Even with this library below, I can't mount:

#include <SPI.h>
#include <mySD.h>

// set up variables using the SD utility library functions:
Sd2Card card;
SdVolume volume;
SdFile root;

// change this to match your SD shield or module;
// Arduino Ethernet shield: pin 4
// Adafruit SD shields and modules: pin 10
// Sparkfun SD shield: pin 8
const int chipSelect = 5;

void setup()
{

  // Open serial communications and wait for port to open:
  Serial.begin(115200);

  Serial.print("\nInitializing SD card...");
  // On the Ethernet Shield, CS is pin 4. It's set as an output by default.
  // Note that even if it's not used as the CS pin, the hardware SS pin
  // (10 on most Arduino boards, 53 on the Mega) must be left as an output
  // or the SD library functions will not work.
  pinMode(SS, OUTPUT);
  //pinMode(5, OUTPUT);

  // we'll use the initialization code from the utility libraries
  // since we're just testing if the card is working!
  // uint8_t init(uint8_t sckRateID, uint8_t chipSelectPin, int8_t mosiPin = -1, int8_t misoPin = -1, int8_t clockPin = -1);
  while (!card.init(SPI_HALF_SPEED, 5, 23, 19, 18)) { // (5, 23, 19, 18) <=> CS, MOSI, MISO, SCK
    Serial.println("initialization failed. Things to check:");
    Serial.println("* is a card is inserted?");
    Serial.println("* Is your wiring correct?");
    Serial.println("* did you change the chipSelect pin to match your shield or module?");
  }
}

I have to go now but I'll come back later. Thanks!

@me-no-dev I formatted it as FAT32 using SD Memory Card Formatter 5.0 for SD/SDHC/SDXC.
It's a 16 GB SDHC card which works pretty well with ESP-12 and SdFat library.

@igrr @me-no-dev @MHEtLive @ladyada it was working with your libraries (the espressif's library and ladyada's library: https://github.com/adafruit/arduino-esp32/tree/d602169ebcd126c309009e87c1e455f2c892d08f) after I formatted the card using "SD Memory Card Formatter 5.0 for SD/SDHC/SDXC". It does never work on pin 5 but it was working on pin 4, but as soon as I pressed the reset button, the card doesn't mount anymore, not even powering the ESP32 off/on. Did anyone solve that problem? I can't find the "f_mount" implementation, just the header file where this method/function is interfaced.

For me, it's getting clear that this must be an issue related to hardware. Please help!

@igrr @me-no-dev @ladyada I got the SD card working successfully on MicroPython after some days of struggle on Arduino IDE. Incredibly or not, I didn't even change the hardware. Thank you for your support!

pinMode(23,INPUT_PULLUP); (Most ESP32 MISO inputs are on Pin-23 solves most of these issues as MSIO must be held high when not in use. Especially pertinent for the MH-ET Live ESp32 board and using the Wemos SD Shield

@dstoiko Bump on your little question:

Working more reliably now, mounting consistently all the time. I still get an error when running the SDCard test code : [W][sd_diskio.cpp:137] sdCommand(): no token received... Any ideas?

It doesn't seem to cause any problem but it keeps annoying me in my debug. Have you found an answer? Else I'm just gonna remove that line from the sd_diskio.cpp...

I don’t have any issues with the library since I added a pull-up on the MISO line I’ve tried. 10K pull-up and the ESP32 internal pull-up and both work ok so I prefer the internal. Without the pull-up I get unreliable operation sometimes it works sometimes not.

I was having an issue with LoRa Feather M0 and a generic micro SD card reader module, Both LoRa and SD work independently but once put on the same SPI port the LoRa fails to initialize while SD card works well. If MISO or power of SD card is removed LoRa radio works again. After days of messing with the code, changing CS pins and adding delays or trying to add a new SPI port, I found a solution. The simple and curious fix was to add a series resistor between the SD card's MISO line, and the Feather M0 board's MISO. I tried 100k 10k 1k and 100 and 100 Ohms worked. Don't know why but the SD card seems to pull the bus low and stops dataflow pof LoRA without the resistor. The SD card works fine on the SPI bus every time but is interferes with LoRa!?!?!1

Adding a series resistor has the effect of producing a pseudo OR gate and most likely there is a design or fault on the SD card as when the SD card is not selected the MISO output should be tri-state and not loading the MISO line.

@me-no-dev I have a similar issue with a Lolin D32 Pro, a 16GB micro sd connected to the native SD socket of the board and a TFT with touch.

When the TFT touch CLK/clock is not connected to PIN18 (but the TFT itself is), the SD card initialises just fine (and the TFT works fine without the touch support). If I connect the TFT CLK pin to PIN18 (shared with the TFT CLK and the SD CLK), the card stops mounting with the following error:

[W][sd_diskio.cpp:517] ff_sd_initialize(): READ_OCR failed: 1FE0003
[E][sd_diskio.cpp:739] sdcard_mount(): f_mount failed 0x(3)
Card Mount Failed

The test code is just this:

#include "FS.h"
#include "SD.h"
#include "SPI.h"

void setup() {
  Serial.begin(115200);
  if (!SD.begin(4)) {
    Serial.println("Card Mount Failed");
  }

}

void loop() {
  delay(500);
  Serial.println("loop");
}

If i disconnect the Touch CLK, the SD mounts and weirdly enough, I can reconnect the touch CLK and reset via the pcb reset button and it will actually mount the SD card. However, a cold start (unplug power, plug it back) will cause the sd mount to fail again...

The Lolin D32 Pro has the required resistors on the SD card side so that's not the issue (https://wiki.wemos.cc/_media/products:d32:sch_d32_pro_v2.0.0.pdf)

I would appreciate any ideas you might have on this... i'm running out of stuff to try.

This is almost certainly a loading issue have you tried reducing the clk pull-up value, say adding a 4K7 resistor or another 10k in parallel.

Also, you could try enabling the ESP32 internal pull-ups on all master lines so SCK, MOSI, MISO and CS.
pinMode(MOSI, INPUT_PULLUP);
pinMode(MISO, INPUT_PULLUP);
pinMode(CS, INPUT_PULLUP);
pinMode(SCK, INPUT_PULLUP);

Then when or if the SPI library sends any line to a tristate, which I believe happens, the pins will be in a known state.

I have the same issue, with multiple ESP32 boards from different vendors (tried Adafruit and Lolin) with the same behaviour: using SD and any other SPI device on the same SPI bus does not work. Looking at the Espressif doc, I think there is the hint:

Currently SD SPI driver assumes that it can use the SPI controller exclusively, so applications which need to share SPI bus between SD cards and other peripherals need to make sure that SD card and other devices are not used at the same time from different tasks.

..which effectively needs you to use a sperate SPI if you want to use SD. There is no reason why this is in the doc, but I can confirm this behaviour. @G6EJD @ladyada

There is also an open issue on the Espressif repo: https://github.com/espressif/esp-idf/issues/1597 that has some background, see here: https://github.com/espressif/esp-idf/issues/1597#issuecomment-365364458. This looks like there is no easy fix here. I switched to MMC to access an SD card.

When the ESP32 starts it places gpio ports into tristate and I think it’s more likely that the SD reader/writer does not have pull-ups to keep it disabled during boot. The MISO line is especially susceptible from the SD MOSI driving it unintentionally. Out of interest the Lolin D32 Pro has an on-board SD-Card and it all works perfectly including their SPI based ili9341 tft display. I have not checked the schematic yet to see what they done to solve this issue.

@G6EJD on the Lolin, the CS lines from both the TFT and the SD are going into the Lolin ILI9341 module. I think that's what they're doing. The ILI9341 somehow checks the SD CS line. If that is the case, I would consider this a hack.

I've just checked then D32 Pro Schematic, it has been designed correctly. Crucially:
MOSI has a 10K pull-up
MISO has a 10K pull-up
SCK has a 10K pull-up
SD CS is on IO4 and has a 10K pull-up
TFT CS is on IO14 and has no pull-up
TOUCH CS is on IO12 and has no pull-up

SPI is a totem-pole driven system unlike I2C, there has to be a SCK provided by the SPI master, a master driven MOSI and a slave driven MISO. The CS is also driven by the master to select a slave and the MISO is tri-stated by the slave until it's CS is driven low by the master, enabling multiple SPI devices to be wire-or'd to MISO as only one CS can be active at a time.

A pull-up or pull-down value of say 10k, should be placed on at least the MISO and its sensible pull the other master generated signals into a default state (High) when the master outputs are tri-stated, such as when the ESP32 is reset, as this is what it does.

I checked the ili9341 board schematic and its CS is a straight through wired connection, no intermediate checking of states.

Clearly Lolin have their design correct.

@michaelkleinhenz as @me-no-dev mentioned on a diff issue for the Lolin board with the TFT and SD you should use SDMMC instead of SD for the SD access.

Hi,
I have also a problem with the built-in SD Card slot on my Lolin D32 Pro. When there is no TFT connected to the TFT port the SD Card slot is working fine and the card is recognized, but when i want to use both TFT and SD Card the mounting fails with the following error:

[W][sd_diskio.cpp:517] ff_sd_initialize(): READ_OCR failed: 1FE0003
[E][sd_diskio.cpp:739] sdcard_mount(): f_mount failed 0x(3)
Card Mount Failed

I literally tried everything and i just can't get both of them to work at the same time. I have also tried SDMMC instead of SD but the TFT starts to blink and it also fails with this error:

E (10784) sdmmc_common: sdmmc_init_ocr: send_op_cond (1) returned 0x107 
[E][SD_MMC.cpp:84] begin(): Failed to initialize the card (263). Make sure SD card lines have pull-up resistors in place.

Could some of you guys solve the issue? What else can i try to make it work?

@merdok I have given up on this. Looks like this is not possible as the SD hardware requires to be the only device on the bus. I switched to SD_MMC, which works, but you need to have the pins available for it, so id depends on what you're doing and which board you use. With SD_MMC, you basically directly connect the SD pins to your i/o and control the sd card directly over dedicated interfacing, not over a bus.

So it appears that you need to use a semaphore around the SDCard/Display write code segments to track which device is currently using the SPI bus, but no code examples are forthcoming on other forums.
To me this suggests an issue with the ili9341 or SD Card library as using multiple SPI bus devices should not be a problem, the PCB design seems OK and a similar arrangement works on the ESP8266, so could it be the CS lines are not being used correctly meaning the CS for TFT and CS for SD-Cards are the same when they should be different.

I do not really understand this... Did not Lolin test the D32 Pro with both SD card and TFT before releasing it?

@michaelkleinhenz but how do you use the SD_MMC library? I also tried it and it also fails. Or did you wire a new sd card port to the GPIOs for that?

@G6EJD If this is an issue with one the libraries then it should be easy to fix, right? I mean both of them are open source so it should be possible to adjust the code and see if that fixes the issue?

@merdok yes, I just haven't got the time right now to trace through the use of CS values to ensure they remain separate, as I'm still sure this is the issue. The Lolin D32 Pro schematic shows no SPI bus design or wiring issues that I can see.
What size SD card are you trying, I think the maximum size is 32GB?

@G6EJD Any chance you could have a look at it?
I did try 16GB and 32GB and both of them work, but just when i disconnect the Touch TFT...

Here's what I've found so-far:
Test Setup:
Wemos D1 Mini ESP8266 or ESP32 D3 Pro
Wemos 2.4"TFT
Wemos SD-Card Shield for Wemos D1 Mini
Adafruit_ILI9341 and Adafruit_GFX

  1. TFT (no SD-Card fitted) works on either ESP8266 or ESP32.
  2. SD-Card works on either ESP8266 or ESP32, but requires addition of #include
  3. ESP8266 + TFT + SD Card does not work. (Adafuit_ILI9341 lib)
  4. ESP32 + TFT + SD Card does not work. (Adafuit_ILI9341 lib)
  5. SD-Card examples do-not function if TFT not fitted but Adafruit_ILI9341 lib included.
  6. So now we can infer there is something in the Adafruit_ILI9341 library that is preventing SD-Card operations.
  7. A cursory look at the Adafruit_ILI9341 library compared to the SD-Card library does not reveal any obvious conflicts.
  8. Other tests conducted - added pull-ups (10K) to all SPI and CS data lines, made no difference.
  9. Slowed down the SPI bus - made no difference.
  10. Needs more time now...

There are a few projects around that use both ili9341 and SD Card, now they don't work once complied with the latest release of the libraries.

Oh, so i does not work also with the Wemos(Lolin) SD-Card Shield on the Wemos(Lolin) D1 Mini? I thought that this issue is just related to the Lolin D32 Pro with the built-in SD Card slot...

Also during my tests i had always the Adafruit_ILI9341 lib included and when i disconnected the TFT Touch shield the SD card was working, i also did leave the TFT init code inside. Now comes the interesting part, when i then hot plug the Touch TFT shield and do a reset with the onboard reset button, both the TFT and SD card work. But when i unplug the power cable and plug it back in the SD does not work again.

Isn't the issue that there are initially some wrong values set by either the Adafruit_ILI9341 or SD card lib when both of them are connected? I mean they both work together fine if you follow the steps which i mentioned above so this makes me think that this is just some issue with initialization.

I do not have enough skills to debug that two cases, but maybe you could do that and there will be something obvious?

I have concluded and observed the same a hot plug of the tft starts the sd card working again, this does indeed point to a device initiation issue and we have concluded the same. So yes, I have all Lolin components and they don’t work together (8266 or 32) there is nothing wrong that I can see with the hardware. Previously the two did work together now not.
In my tests I disconnected the TFT and with an include Adafruit_ili9341 SD operations stop or of course the same may happen in converse a working ili9341 might stop when the SD library is included.
I have no answers yet but will keep investigating. I have yet to go back in the versions of the libraries back to when it was all working. To me it seems to be either the TFT or SD have been initialised to be bus masters not slaves and hence won’t work together.

Hello guys. I noticed the thread is active again. Have you tried the solution I posted last year? In short: put a 100 ohm resistor in series with both the mosi and miso lines, I discovered this randomly but later found an explanation, it is to do with the fact that one of the devices (cannot remember which one probably sd controller chip) doesn’t have the standard tri-state I/O so even when the CS is pulled low, the data lines are low impedance. If only one device is on the bus it is not a problem but as soon as you add the second one the low impedance data lines pull the whole bus down introducing all sort of issues most noticeably problems in intialization of either salve devices on the bus even though they both work on their own on the bus. The resistor overcomes the issue in a very simple and crude way but it works. Hope it helps, happy to discuss it further.

P.s.the 100 ohm resistor is only needed on one of the data lines, either mosi or miso can’t remember which one but it is not a problem to put one on each data line

@G6EJD That is good that we came to the conclusion :) I hope this brings are more closer to a solution :)
Did with a previous version everything work? I noticed the issue around December last year so if it was working then it was before that.

@arash-pyk I did not try that, but it seems the hardware is correctly designed so why would we need to put an additional resistor there?

the issue I was having was to do with the internal design of the monolithic IC of the SD card controller and not the external components of the circuit. The solution is for people having problem with two slave devices on the SPI bus given that everything is properly setup, CS lines are managed correctly etc. give it a try, you only need to add the resistor to the second device on the bus.

Maybe it's a good idea to make a setup with 2 SD cards and a setup with 2 TFT's to make sure which device causes the trouble.

What is strange is that many projects/designs have been made that simultaneously display data from an SD card on a TFT and the hardware arrangement is identical. This does therefore point to a software issue. Today I’ll try an ILI9341 with in-built (unbuffered) SD (although not uSD) card reader to see if that still works.

I guess the issue is the the touch capability of the Lolin 2.4 Touch TFT shield. It uses an additional CS line as far as i know. I also have the Lolin 2.13 EPD shield which does not have touch and he SD card works without any issues together with the display.
That is why i guess other projects work (because those displays in the other projects does not have touch)

TF_CS is GPIO-12 and no conflict with other devices according to the schematic.

That is why this issue is so strange. Everything looks fine, so why it does not work?

Out of interest SD Library no-longer works on ESP8266, but works on ESP32; an Issue is already pending on here.

Was there ever a resolution to this issue?
I am coming from the micropython universe and I am experiencing the same exact problem.
https://forum.micropython.org/viewtopic.php?f=18&t=8352

Why was this post closed?

I still have the issue...

I've been working on this issue for weeks and can't find a solution.
Again... why was this post considered closed?

@merdok @GC-RnD Open a new issue and follow the issue template and you might get some assistance, commenting on an old/closed issue won't get much traction for you.

It’s generally a hardware problem, some designs work, some don’t. It was closed because there is no software issue. Usually the addition of pull-up resistor can help but in all cases the SD card needs to be buffered from the SPI bus to ensure correct operation and few if any are.

For reference I'm using a wemos Lolin D32 Pro v2.
Has all pull-ups.
Not able to use ili9341 and sd card on shared spi
Please explain "buffered from the SPI"
Do you mean separated not shared?

What happens is the display does not release the SPI lines and loads them, by a buffer I mean a isolation buffer frequently found on SD devices. For example take a look at separate SD cards on AliExpress you will find buffeted and unbuffered types, it is the latter required. If you purchase an ili9341 display with on-board SD card you will see a buffer device that separates the bus devices. Wemos made a mistake with these boards, you can use the SD card alone or Ili9341 alone but not together. The design is flawed.

You can see the buffer device at the bottom right corner: ï¿¡1.84 | Mini Data Logger Module Logging Shield for Arduino For Raspberry Pi Logging Recorder Data Logger Module Shield V1.0 SD Card
https://a.aliexpress.com/_dSRMQ5f

Some interface boards for SD card have a design error. The MISO line will be at ground level if no card is inserted. Even if the CS is not active. The enable input of the buffer for MISO is connected to ground and not to CS.

@G6EJD You say that this is a design error, but if you boot the Lolin d32 pro board without the screen connected and then connect the screen after the board has booted then magically both the screen and the sd card slot work together without issues. You can even reset the board with the on-board reset button and they will still work, but as soon as you disconnect the power completely they will not work and you have to repeat the process...

Could you please check the level of the MISO signal in various (working and not working) test situations? MOSI should be HIGH most of the time.

Same issue here, using TTGO V2.1 boards. But could solve it by moving to this lib:
https://github.com/nhatuan84/esp32-micro-sdcard

It works for SD access via SPI interface, while SD.cpp from arduino-esp32 doesn't.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jh83 picture jh83  Â·  124Comments

dsyleixa picture dsyleixa  Â·  65Comments

PhilColbert picture PhilColbert  Â·  125Comments

adamwilt picture adamwilt  Â·  63Comments

JohnGEyles picture JohnGEyles  Â·  53Comments