Teensy 4.1 SD-card extension issue



I am asking about this issue partly because I think it may be of interest for PRJC too look into as well.
Might also not be, I suppose :)

We are in a situation where we have had to extend the Teensy 4.1 SD card slot using an extension cable connected via the on-board SDIO socket (SdioTeensy.c in effect).
We initially did this using a hand-built 1.27mm ribbon cable attached to an µSD shaped board on one end and a board with an SD-card socket on the other.
This worked well.

We later upgraded the cable to a production-friendly Rigid+FlexPCB which, due to it's thinner structure, has slightly higher capacitance.
This cable does not work at all.

What is interesting is that the cable does work perfectly with Teensy 3.2, Teensy 3.6, other custom microcontroller boards as well as every PC USB SD-card reader we've tested - the cable fails exclusively with Teensy4.1.

We have, of course, played around with drive strengths on the SD pins, print debugging over USB serial, and scope measurements of the signals.

It turns out that failures most often occur as early as the 400kHz initial rate, but sometimes we get all the way to running at 25MHz high-speed for some short duration before it fails. Some Teensy 4.1s consistently don't manage to get even a single transaction through.

The signals and the eye diagram are, as expected, absolutely pristine in 400kHz mode.
Ringing (measured with a 200MHz scope) does not indicate this to be an issue.
At 25MHz there is natural degradation of the eye diagram, but nothing that would typically warrant suspicion.
Drive-strength changes have the expected impact on signal transitions, but little to no effect on the problem across the full range of configurable strengths.

We have attempted to get suggestions from NXP support, which yielded no results.

It has later been shown that the initial ribbon cable, even though it appeared to work well, also has issues (again, with Teensy 4.1 only).
Sometimes, although quite rarely, communications do fail - which has warranted us to implement a re-initialize and retry functionality that works around most of these issues.
We've not error checked our file.printf calls (which I am not exactly certain how to do at this point) so this still came back to bite us recently.
Sometimes the system ends up in a state where every call to write data takes approximately 1 second before returning.
This, of course, appears to hang the system when a large number of writes are done in direct succession.
After dumping the stack using an interrupt we found that this time is spent in waitTimeout (via isBusyTransferComplete, waitTransferComplete, SdioCard::writeSector, etc.).

That's what I've got at this point - here's hoping for any sort of suggestion on reconfiguring the SD card peripheral to better cope with this situation, which seems obviously possible given that it works with "everything" else.

NXP supports suggestion of "don't use the cable" is not really an option :)

Thanks for your time!
Are you 100% sure the issues go away when you use the card slot directly? I had issues with the Audio library where SD access from sketch and playback (interrupt) code gave a 1 second hang at the exact same place in the code. This is unsurprising, as the timeout is 1 second, and simultaneous access from foreground and interrupt code is not supported...

Does your extender setup have reservoir and / or decoupling capacitors near the SD card? The card can take large gulps of current when operating, which might bounce the ground reference enough to affect signal integrity. I'd be surprised if that was relevant during the initial setup phase, but I don't know enough about card internals to know whether they might do Flash reads at that time, maybe they do.

This could be entirely irrelevant, as you haven't posted a complete example sketch which demonstrates the problem, or shown a picture and schematic of your hardware.
Maybe unrelated, but I recently made some improvements to Teensy's copy of SdFat for startup with very old cards. Also merged an improvement for cards that claim 50 MHz but don't reply properly.

So far no Teensyduino release (not even a beta version) has these, so today the only way to get it from github.

Why certain very old cards need the workaround after CMD8 is still a mystery. Maybe it's a sign of something slightly wrong much deeper? I only have 2 cards which reproduce that problem. I also have fairly limited time to deep dive into such a rare problem, but as you can see from the github commit, I did at least come up with a workaround that works for the 2 cards I can test even if I didn't have time to dig much deeper for the root cause.

If none of this helps, could I talk you into sending me 1 or 2 of the problematic extension cables? I can't promise any particular time frame for testing it, but without the hardware to reproduce the issue I can assure you I'll never be able to do more than guess (eg, this message).

Edit: this is the thread where the questionable 50 MHz cards were discussed. Not sure if any of that applies... just more guesswork.
Last edited:
hoping for any sort of suggestion on reconfiguring the SD card peripheral to better cope with this situation

While I really doubt this will make any difference, you can configure whether SdFat uses FIFO or DMA. See the SdFat_Usage example for the special syntax to configure this detail.

Maybe unrelated, but I recently made some improvements to Teensy's copy of SdFat for startup with very old cards. Also merged an improvement for cards that claim 50 MHz but don't reply properly.


We are testing with several different cards from several different manufacturers - most of them quite new.

In my journeys to troubleshoot this, I've tried decreasing the speed to 25MHz.
This was before we discovered that communication often fails already at 400kHz speed and we never really get to CMD6 most of the time.

I will try all suggestions, including FIFO mode, and report back.