Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

SdFat library problems #3185

WilliamKWusik started this conversation in General
Oct 3, 2025 · 4 comments · 3 replies
Discussion options

Up until a few releases ago it was working. But as soon as I updated to 5.2.0, if I recall, it stops, had to install 5.0.0 to have it working again. Not sure on what I could gather and post here to help out. I will do a barebones test to see if maybe it's a ram corruption problem. Anyway, thanks for any input.

// SD Card Pins //
int _MISO = 16; // AKA SPI RX
int _MOSI = 19; // AKA SPI TX
int _CS = 17;
int _SCK = 18;
//
#include <SdFat.h>
SdFs SD;

SPI.setRX(_MISO);
SPI.setTX(_MOSI);
SPI.setSCK(_SCK);
//
if (!SD.begin(SdSpiConfig(_CS, DEDICATED_SPI, SPI_FULL_SPEED)))
{
// Failed! //
}

You must be logged in to vote

Replies: 4 comments 3 replies

Comment options

I also recall that 5.2.1 was working. 5.3.0 was when it failed the SdFat. But just going back to 5.2.1 or 5.2.0 didn't fix. Had to go way back to 5.0.0 and also delete the temp files.

You must be logged in to vote
0 replies
Comment options

I've just done the RP2040SDIO test (parallel SDIO, way faster than 1-bit SPI) and it ran fine. As did the bench example using both SDIO and plain SPI1.

My bench.ino diffs are below. All I did was set the proper CS pin, force FatType to 3 (so it uses SdFs like in your snippet), and set up the SPI1 port (I have a hardwired testboard w/this config).

earle@amd:~/Arduino/hardware/pico/rp2040$ diff ~/Arduino/bench/bench.ino libraries/SdFat/examples/bench/bench.ino 
10c10
< #define SD_FAT_TYPE 3
---
> 
32c32
< const uint8_t SD_CS_PIN = 13;
---
> const uint8_t SD_CS_PIN = SS;
58,60d57
< #define SD_CONFIG SdSpiConfig(SD_CS_PIN, DEDICATED_SPI, SPI_CLOCK, &SPI1)
< 
< 
144,147d140
< SPI1.setCS(13);
< SPI1.setMISO(12);
< SPI1.setMOSI(11);
< SPI1.setSCK(10);

That said, you really should consider using SDFS or SD from the core (which use the SdFat library underneath) to be compatible with the internal core File, Dir, etc.

5.0.0 brought in an updated SdFat library from upstream, and there was a minor change in 5.2.1 allowing SPI to be unidirectional, but otherwise that part of the core has been stable.

You must be logged in to vote
0 replies
Comment options

Thanks for looking into this. :-) I did a clean install of V5.0.0 and it worked. Updated to V5.3.0 and it stops working. Did another clean of V5.0.0 and it's back again. I will do more tests soon. Cheers.

You must be logged in to vote
2 replies
Comment options

What about 5.1.0? I'm thinking you could do a bisect test as a brute force way of finding where things go pear shaped in your setup. If 5.1.0 fails, but 5.0.0 doesn't, then the diff is one of the following commits (which don't look they have anything to do w/SPI or SD)
5.0.0...5.1.0

And if 5.1.0 works, give 5.2.1 a go. There the diffs are also pretty benign as far as I can see
5.1.0...5.2.1

If you can narrow it down to between releases, then if you can run the git you can single-step backwards from the failing release, one commit at a time.

But, again, I don't see anything that looks like it would affect SDFat.

Comment options

And the other thing would be for you to make a small, self-contained MCVE w/o other libraries/etc. that shows the problem. If it's reproducible outside of your setup, then it's much easier to figure out.

Comment options

BTW: right now I can't use SDIO, as I ran out of pins on my project. :-o

You must be logged in to vote
1 reply
Comment options

Oh well, always the next project with a RP2350B (48 GPIOs!). 😆 The core here works with either, 1-bit or 4-bit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Converted from issue

This discussion was converted from issue #3184 on October 03, 2025 23:48.

AltStyle によって変換されたページ (->オリジナル) /