Having issues with DFRobot_0669 & SD

[jim lee]

As far as I can tell I've commented out everything to do with my DFR0bot code. But SD.begin() always returns a fail.
I've looked at the chip select, mosi & miso signals and from what I can tell, they look fine. When I roll the display back into the code, it works and draws. I can see the chip select lines alternate as they should between the Display and the SD drive. I can see the mosi talk to the SD drive and the SD drive answer back. At the DIN pin (12 - on my T3.2) But it's like the Teensy can't hear it.

Any thoughts?

The test code

//#include <DFRobot_0669.h>
#include <SD.h>

// For DFRobot_0669
#define DSP_CS    10
#define SD_CS     4
#define DSP_RST   26



void setup() {
  
   Serial.begin(9600);
   delay(2000);
   /*
   Serial.println("Allocation of screen");
   screen = (displayObj*) new DFRobot_0669(DSP_CS,DSP_RST);
   Serial.println("screen allocated");
   screen->begin();
   Serial.println("begin called");
   screen->fillScreen(&green);
   Serial.println("screen green?");
   */
   if (!SD.begin(SD_CS)) {                                        // With icons, we now MUST have an SD card.
      Serial.println("NO SD CARD!");                              // Send an error out the serial port.
      //screen->setCursor(10,10);     // Move cursor to the top left.
      //screen->setTextColor(&red); // Drawing in white..
      //screen->setTextSize(2);       // Big enough to notice.
      //screen->drawText("NO SD CARD!");     // Draw the error message.
   } else {
      //screen->setCursor(10,10);     // Move cursor to the top left.
      //screen->setTextColor(&black); // Drawing in white..
      //screen->setTextSize(2);       // Big enough to notice.
      //screen->drawText("FOUND SD CARD!");     // Draw the error message.
   }
}

void loop() {
  

}

Thanks!
-jim lee

 

[jmarsh]

Does the DSP_CS line have a pull-up on it? Since in the code you posted it's not being driven at all by the MCU, possibly reading as low (active) to the slave device.

 

[jim lee]

I don't do anything to it but pass it on to SD.begin(); Kinda' the standard way. And we didn't see anything on the scope that would make us think it's floating.

Actually, not being a wire guy. I don't really know. I can set it up with INPUT_PULLUP and see if that helps? But no, On second thought.. It starts as an output so.. That'll probably just mess things up more.

 

[jmarsh]

I asked about DSP_CS, not SD_CS. You may have commented out all the display code but presumably it's still connected to the SPI bus, which means its CS line should be driven high to stop it answering...
If it is high then I would suspect the display is one of the dodgy models that still drives the SPI MISO line even when the display isn't the currently selected device, instead of tri-stating.

 

[jim lee]

Ah! Sorry, my mistake. The DSP_CS looked fine. High at the right times, low at the right times. We plotted both on the screen at the same time to make sure they were working together.

 

[jim lee]

I was able to find the source code. (Macs hide it pretty well) I was able to trace it this far..

//----------------------------------------------------------------------------
  /** Initialize SD card and file system for SPI mode.
   *
   * \param[in] spiConfig SPI configuration.
   * \return true for success or false for failure.
   */
  bool begin(SdSpiConfig spiConfig) {
     Serial.println("Is there where SDFat.begin() goes III?");
    spiConfigBackupPin = spiConfig.csPin;
    spiConfigBackupOptions = spiConfig.options;
    spiConfigBackupClock = spiConfig.maxSck;
    spiConfigBackupPort = spiConfig.spiPort;
    return cardBegin(spiConfig) && Vol::begin(m_card);
  }

It looks like cardBegin(spiConfig) is fine I assume Vol::begin(m_card); But I'm having trouble finding class Vol.

 

[jim lee]

Reduced the test code..

#include <SD.h>

#define SD_CS     4

void setup() {
  
   Serial.begin(9600);
   delay(2000);                  // Wait for the Damn Serial to come alive..
   while (!SD.begin(SD_CS)) {                         
      Serial.println("unable to find SD card!");
      delay(500);
   }
}

void loop() { }

Now I can "see" that the two devices are talking, because the while loop changes the looping speed if the SD card is in or out. Meaning the code path is different. Tracking this down is like trying to figure out who owns what company. When when they don't want anyone to know.

Anyone know anything about this SD, SDFat, ExFatLib code that can shed some light on this? I'm out of my yard here.

Thanks!


-jim lee