Schematic error in T4.0 or T4.1 on SD pins

[FLL-Freak]

I have been having a hard time getting my T4.0 to talk to an SD card. A friend has a T4.1 that works fine.

I went back to review what I had done when I noticed an inconsistency in the published schematics for the T4.0 and T4.1
(https://www.pjrc.com/teensy/schematic.html)

T4.1 has DAT2 on SD_B0_04 and DAT3 on SD_B0_05. The T4.0 has these reversed.

If this just an error in the schematic? If not I could understand why my T4.0 is not working in that I have two of the data lines reversed.

[Silverlock]

The consensus on this thread was that it just was an error in the T4.0 schematic.

When you say you're "having a hard time getting my T4.0 to talk to an SD card", are you using the SDIO pads on the underside of the T4.0, or the SPI pins 10-13?

[FLL-Freak]

Somehow I keep losing replies to threads. Hopefully this is not a duplicate.

I am glad to hear that the schematic issue is likely just a documentation issue and not in the copper.
It does sadden me that this is not the cause of my grief. A two wire swap would have been simple. Oh well.

Yes I am trying to use the "SDIO" pins on the back of the T4.0.

<sidenote>
I do not think this is strictly SDIO but rather "4 bit SD serial".
SDIO cards (wifi, ethernet, ...) use the four bit serial for their interface and hence I think that is how it came to be called SDIO.
I could also be all wet.
</sidenote>

I tried to describe my issue in this thread: https://forum.pjrc.com/threads/63235...-SD-card-usage

I am become more convinced that I have a library issue. I read on a forum post here that we should be using the "beta" SD card library on Github.
I jumped straight to that and never could get a good connection. My friend using the T4.1 just used the default libraries.
So I have purchased a T4.1 and will use that as a comparison to my setup to see where I am going wrong.

[Silverlock]

I've been using an SDIO connected uSD card with the T4.0 and T4.1 and the SdFat-beta library, on a daily basis, for many months now. I imagine if there was an issue with the SdFat-beta library, I'd have run into it by now.

Just to clarify: this is the breakout board you're using: Adafruit Micro SD SPI or SDIO Card Breakout Board - 3V ONLY!?

For the T4.0, this is the breakout board I've been using: Chip Quick micro SD breakout.

One extra thing I have done in my T4.0 circuit is to give the uSD card its own 3.3V regulator so it wasn't dependent on the T4.0's 3.3V line. And I went a little overboard on the bypass caps. Clean power to the uSD card meant I had one less thing to worry about.

[FLL-Freak]

I did not mean to imply an error with the library but rather my use of it. I am sure that it is working for a good number of people.
(These people must be living a cleaner life than I am.)

By the time you get the library in the right place (Linux had some 'issues'), do the configuration (lots of knobs to turn), and then use it in a sample application there is a lot to go wrong.
If anyone would volunteer their config file for the beta library, I would love to see it.

That is indeed the breakout board I am using. The only thing on this board is a bypass cap and some pull up resistors on the signal lines.
I have used this board before for SPI only interface from a different ARM with success. Not the exact one, but the part number.

I am looking forward to getting the T4.1 in house (looks like 4 days from now) and having a go with it on a virgin PC.
Then I will try it on the PC I was using before. If that continues to work then I will start to compare the signals between the two boards to figure out the issue.

[KurtE]

Yep looks like a Bug on the schematic label of pins 38 and 39 on T4.

[Silverlock]

...do the configuration (lots of knobs to turn), and then use it in a sample application there is a lot to go wrong.
If anyone would volunteer their config file for the beta library, I would love to see it.

Right there could be a big part of your troubles. Don't change the config file. I've haven't. Use plain old SdFat file system in your program, and resist the temptation to turn knobs and twiddle with dials. The only thing you have to get set up properly (and this is in your program, not the library) is the proper initialisation in the SD.begin(...) call. I use

SdFat SD;
.
.
.
if (SD.begin(SdioConfig(FIFO_SDIO))) {
.
.
.

and that works fine on both the 4.0 and 4.1.

[FLL-Freak]

But the knobs and dials are soooo shiny and pretty... Must be there for a reason... Must turn and spin them... Must...

Ok, I will try it out of the box and see what happens.

[PaulStoffregen]

Confirmed, the schematic had an error for the signals connected to 38/DAT3 and 39/DAT3 on Teensy 4.0. I've updated it.

[FLL-Freak]

Thank you for fixing the schematic. That will reduce some confusion in the future.

[FLL-Freak]

I have restored my sdFat-beta to factory defaults. My hardware in a T4.0 with an AdaFruit sdcard breakout board as above.
The SD card is a SanDisk Ultra SDHC 16G card.
I ran the SdInfo demo (no changes) and got the following output on a freshly formatted card using the SdFormat utility. Any ideas?
I also ran the TeensySdioDemo and the results indicate a read failure but when I look on the disk, the file it writes to is missing "TeensyDemo.bin"

SdFat version: 2.0.0
Assuming an SDIO interface.

type any character to start
init time: 18 ms

Card type: SDHC

Manufacturer ID: 0X3
OEM ID: SD
Product: SC16G
Version: 8.0
Serial number: 0XF55D6E84
Manufacturing date: 2/2014

cardSize: 15931.54 MB (MB = 1,000,000 bytes)
flashEraseSize: 128 blocks
eraseSingleBlock: true

OCR: 0XC0FF8000

SD Partition Table
part,boot,bgnCHS[3],type,endCHS[3],start,length
1,0X0,0X82,0X3,0X0,0XC,0XFE,0XFF,0XFF,8192,31108096
2,0X0,0X0,0X0,0X0,0X0,0X0,0X0,0X0,0,0
3,0X0,0X0,0X0,0X0,0X0,0X0,0X0,0X0,0,0
4,0X0,0X0,0X0,0X0,0X0,0X0,0X0,0X0,0,0

volumeBegin failed. Is the card formatted?

type any character to start

[defragster]

I have SDFatBeta here and a T_4.0 on the FRDM4236 ( PCB with T_4.0 mapping pins and SDIO to a T_3.6 formfactor )

 Used: T:\tCode\libraries\SdFat-beta
 Not used: T:\tCode\libraries\SdFat_-_Adafruit_Fork
Using library SdFat-beta at version 2.0.0-beta.8 in folder: T:\tCode\libraries\SdFat-beta

I did SdFormatter on a 16GB card - it completed full format. :: "T:\tCode\libraries\SdFat-beta\examples\SdFormatter\SdFormatter.ino"

Then ran SdInfo: "T:\tCode\libraries\SdFat-beta\examples\SdInfo\SdInfo.ino"

SdFat version: 2.0.0

Assuming an SDIO interface.

type any character to start
init time: 13 ms

Card type: SDHC

Manufacturer ID: 0X3
OEM ID: SD
Product: SL16G
Version: 8.0
Serial number: 0X1D03BD28
Manufacturing date: 6/2015

cardSize: 15931.54 MB (MB = 1,000,000 bytes)
flashEraseSize: 128 blocks
eraseSingleBlock: true

OCR: 0XC0FF8000

SD Partition Table
part,boot,bgnCHS[3],type,endCHS[3],start,length
1,0X0,0X1,0X1,0X0,0XC,0XFE,0XFF,0XFF,8192,31108096
2,0X0,0X0,0X0,0X0,0X0,0X0,0X0,0X0,0,0
3,0X0,0X0,0X0,0X0,0X0,0X0,0X0,0X0,0,0
4,0X0,0X0,0X0,0X0,0X0,0X0,0X0,0X0,0,0

Scanning FAT, please wait.

Volume is FAT32
sectorsPerCluster: 64
clusterCount:      485936
freeClusterCount:  485935
fatStartSector:    8790
dataStartSector:   16384

type any character to start

@Paul - will note on TD_1.54b1 thread - both of the above worked on T_4.0 and T_4.1

[FLL-Freak]

Since @defragster showed me it was possible, I gave it another try tonight with the T4.0 and AdaFruit SD card on 1.5 inches of wire. Still no go. So I pulled out the logic analyzer and connected up 3 of the leads. Now it works fine. I played around a bit to find that if I attach a probe to the D0 (zero) lead the problem goes away. So I think all I am adding is a tiny bit of capacitance. I need to double check the Saleae Logic-8 documents to see what the lead loading is. Amazon claims I will have the T4.1 tomorrow by nightfall to try that out.

Now the AdaFruit SD card breakout has two decoupling caps an 47K pullups on all the data lines. Did some Googling and there does not seem to be any consensus on the need for them especially using 4 bit serial (SDIO) mode. Since the T4.1 does not have pullups, I am tempted to pull them off and see how it works that way. But they are tiny parts and getting them back on would be tough.

Any ideas?

[Silverlock]

The uSD breakout board that I use with the T4.0 has no pullups, and as you've already seen on the T4.1 schematics, the onboard uSD there has none either.

As for wire lengths, I've got a 2" FFC cable between the T4.0 and the main PCB, then probably the better part of another inch of traces on the PCB and the breakout board. So your 1.5" of wire shouldn't be a problem.

[KurtE]

Sorry, I may not be much help here, but earlier I did solder on cable connectors and the like on T4 and my own board and sometimes my soldering skills failed and I ended up with a short between a couple of the pins or a bad connection...

So you might want to check that out... Often times I will run a simple test sketch that @defragster and myself did that you can jumper from either +3.3v pin or GND pin to an IO pin and debug monitor will print out which pin went high or low... Also when we changed modes we would do some simple tests of setting one to set a pin to HIGH or LOW and check the pin next to it to see if it changed as well... Found a few issues that way.

Again it may not be your issue, but often times it helps to eliminate that you have something simple like a short or a pin not making connection, before you spend too much time debugging the harder things.

void setup() {
  Serial.begin(115200);
  while (!Serial && millis() < 4000 );
  Serial.println("Compile Time:: " __FILE__ " " __DATE__ " " __TIME__);
  Serial.printf("Num Digital Pins: %d\n", NUM_DIGITAL_PINS);

  testForShorts();
  
}

uint32_t cnt = 0;
void loop() {
  cnt++;
    allPinTest( cnt );
}

uint32_t pinLast[NUM_DIGITAL_PINS];
void allPinTest( uint32_t cnt ) {
  uint32_t ii, SET;
  Serial.print("PULLDOWN Start Vals:\n  ");
  SET = 0;
  Serial.print("PULLDOWN :: TEST to 3.3V\n  ");
  for ( ii = 0; ii < NUM_DIGITAL_PINS; ii++) {
    pinMode( ii, INPUT_PULLDOWN );
    delayMicroseconds( 5 );
    pinLast[ii] = digitalReadFast( ii );
    if (pinLast[ii]) {
      Serial.print("\nd#=");
      Serial.print( ii );
      Serial.print( " val=" );
    }
    Serial.print( pinLast[ii] );
    Serial.print(',');
  }
  Serial.println();
  Serial.println();
  while ( 1 ) {
    uint32_t jj, dd = 0, cc = 0, ee=4;
    cc = 0;
    for ( ii = 0; ii < NUM_DIGITAL_PINS; ii++) {
      jj = digitalReadFast( ii );
      if ( jj != pinLast[ii] ) {
        dd = 1;
        cc++;
        pinLast[ii] = jj;
        Serial.print("d#=");
        Serial.print( ii );
        if ( pinLast[ii] ) Serial.print( "\t" );
        Serial.print( " val=" );
        Serial.print( pinLast[ii] );
        Serial.print(',');
      }
      if ( cc > 1 && ee ) {
        Serial.println(">>> MULTI CHANGE !!");
        ee--;
      }
      if ( Serial.available() ) {
        while ( Serial.available() ) Serial.read();
        if ( 0 == SET ) {
          SET = 1;
          Serial.print("PULLUP :: TEST TO GND\n  ");
        }
        else {
          SET = 0;
          Serial.print("PULLDOWN :: TEST to 3.3V\n  ");
        }
        for ( ii = 0; ii < NUM_DIGITAL_PINS; ii++) {
          if ( 0 == SET )
            pinMode( ii, INPUT_PULLDOWN );
          else
            pinMode( ii, INPUT_PULLUP );
          delayMicroseconds( 20 );
          pinLast[ii] = digitalReadFast( ii );
          if (SET != pinLast[ii]) {
            Serial.print("d#=");
            Serial.print( ii );
            Serial.print( " val=" );
            Serial.println( pinLast[ii] );
          }
        }
      }
    }
    if ( dd ) {
      dd = 0;
      Serial.println();
      delay( 50 );
    }
  }
}

void testForShorts() {
  uint32_t ii;
  Serial.print("Quick Test for Shorts to adjacent pin");
  Serial.println("First pull pins down and see if the next one follows");
  for ( ii = 0; ii < NUM_DIGITAL_PINS-1; ii++) {
    pinMode( ii+1, INPUT_PULLDOWN );
    pinMode( ii, OUTPUT);
    digitalWrite(ii, HIGH);
    delayMicroseconds( 5 );
    if (digitalRead(ii+1)) {
      Serial.printf("%d:%d ", ii, ii+1);
    }
  }
  Serial.println("\n Now try Pull up and see if setting low follow");
  for ( ii = 0; ii < NUM_DIGITAL_PINS-1; ii++) {
    pinMode( ii+1, INPUT_PULLUP );
    pinMode( ii, OUTPUT);
    digitalWrite(ii, LOW);
    delayMicroseconds( 5 );
    if (!digitalRead(ii+1)) {
      Serial.printf("%d:%d ", ii, ii+1);
    }
  }
  Serial.println();  
}

[FLL-Freak]

Sorry, I may not be much help here, but earlier I did solder on cable connectors and the like on T4 and my own board and sometimes my soldering skills failed and I ended up with a short between a couple of the pins or a bad connection...

Trimmed

KurtE,

Thank you for the test program. I am sure it will come in handy. I do not think soldering is the issue. All the joints look perfect under a microscope. Not only that, but it works about 50% of the time without touching the setup in any way. And works better is adding some capacitance to Dzero.

All,

I bit the bullet and pulled the 47K pull ups off the board. That did not change anything in the least. I guess I will put down my pencil till my T4.1 board arrives tomorrow. There is always a small chance this is a bad board or SD card (I have a new one of those coming as well).

[FLL-Freak]

I got my T4,1 in today and the SD card works perfectly with it. Did not work on the T4.0 reliably. My connections to the SD card breakout where a series of discreet wires each about 2 inches long. These were bundled using lacing cord. From other posts it would seem like most people use a length of ribbon cable. I now suspect that my bundle is introducing some signal integrity issues. When I get a change, I will switch to ribbon cable. Need to order some of the right pitch.