The next step of my port-from-Arduino exercise is getting my microSD card adapter interface to work with the Seed. In Arduino-land I’m using the SdFat library with SPI. I tried SDMMC in DaisyExamples/seed with my card connected to SPI pins, with no success. Not a big surprise, since it seems to be expecting an SDIO connection. I want to do fairly simple card operations - read/write text files, get directory contents. Is there an easy way for me to do this? Thanks.
Well, I decided that throwing hardware at the problem is the way to go on this one - getting an SDIO breakout. I’m ordering a couple of these: Adafruit Micro SD SPI or SDIO Card Breakout Board - 3V ONLY! : ID 4682 : $2.95 : Adafruit Industries, Unique & fun DIY electronics and kits and hoping that I’ll get access to the FatFS library “out of the box”
Were you about to get the FatFS library + SDIO breakout board working out-of-the-box? I’m hoping to use and SD card and a similar breakout board in a project I’m working on.
I wired up the breakout board and uploaded the SDMMC example code to test, but haven’t gotten the connection to work. But I’m also coming to daisy as a relative novice.
I ordered the boards, and while I was waiting from them to arrive, discovered the QSPI flash memory peripheral on the Daisy. Ended up using that for patch storage; the SD boards are still unopened! If you get SDIO working with the Daisy, please share your experience (including any working code!). Good luck!
Hi! Very interested about this thread.
I had some issues with some SD card who appears as not readable by the SD slot from the pod. Are you sure your problem is not coming from the SD card?
I want to build my own sampler using a seed, but yeah, i would like to plug a SD card reader to it. I will order a compatible breakout board and will give it a try on my side. I also saw on the pod schematics that some SD card reader pin needs some resistor between them and the 3v3 VCC … maybe the issue came from here?
@YMNK I’m pretty sure the card isn’t the problem. At the very least, my laptop recognizes the card and it’s properly formatted. A while back, I also tried placing 47k resistors to match the schematic for the pod, but this also didn’t seem to have an effect.
My next step is to see if I can test the sd breakout board I’m using to make sure that’s not the issue. I have an STM32F4 Discovery Board laying around, so I’ll probably try and test the SD card reader with that.
I’ll report back if I figure anything out. Hopefully it’s a goof on my side.
Hi @jogawebb. I said that because I spent a lot of time stuck on a SD card not working on the Daisy Pod, but who was working fine with any computers … even if it was correctly formatted (FAT for windows).
I’m not a SD card expert but I know there’s some difference between a normal SD card (2GB) and SD card HC (16go). Also there’s something about High Speed, UHS-I, UHS-II, UHS-III …
Turns out that the classic SD card was never read by the Pod and the SDHC with UHS-III was totally fine.
Thanks for the heads up, the card I’m using is a 16gb SDHC with UHS-I, so maybe I’ll try swapping it out and see if it makes a difference.
I also tried checking against some test code with an arduino using the SPI interface, and that was able to read the card info just fine. I’m hoping it’s just something I’m overlooking 
I previously stumbled across this edge case: f_mount returned FR_NOT_READY which means the card is mounted but hasn’t completed its internal initialisation yet. You could start using it but on the first actual card access you would see a little delay until the card is finally ready. (Check the docs for f_mount)
In my code I wasn’t handling this case. I only checked the mounting like this:
if (f_mount(...) != FR_OK)
// failure
Since the return value was FR_NOT_READY, it seemed as if the card failed to mount which simply wasn’t true.
I observed this behaviour with old card whereas newer cards were quick enough to directly return FR_OK.
Maybe in your case it’s something similar?
I’ve finally gotten around to giving the SDIO breakout board a try, and I’m having exactly the same problem of FR_NOT_READY returned by f_mount using what seems to be the same type of card that @jogawebb is describing (a 16GB SanDisk Ultra), which I was also able to read using Arduino/SPI. I don’t have any “newer cards”; @TheSlowGrowth , can you suggest a specific card that has worked for you? Thanks!
BTW, I put the f_mount in a loop with a delay. It never gets to FR_OK, so the SDIO reader is currently non-operational for me.
Did you try reading and writing to the card? It may just be that f_mount never checks for card readiness again after the initial successful mounting.
Edit: did you probe the data lines yet? Does the card respond to any commands at all?
You could also step through the fatfs code to see where exactly it fails.
Yes, the SDMMC example that I’m trying does an fopen for write and then for read. Both fail. Based on your comment, I stepped into the fopen with the debugger, and could see that it fails on
if (fmt == 4) return FR_DISK_ERR; /* An error occured in the disk I/O layer */
in find_volume(). It looks to me like the mount has succeeded, but the routine fails on trying to load sector 0. Probing data lines is something I’ve not yet learned to do, and I’d have no idea what to look for.
Have you gotten these read/write operations to work with a card of this type? I’d be happy to order and try a different card type if you can give me a suggestion. Thanks.
@Elby It sounds like we’re having a pretty similar experience. I checked for FR_NOT_READY and, sure enough, that’s what was happening. I also added a long delay to give the card some more time, but I haven’t gotten successful read/write to happen yet.
Reading back over this thread, I see one comment from @YMNK that indicates that UHS-3 might be the key (rather than the UHS-1 that you and I are using @jogawebb ). This looks like it might do the trick: https://smile.amazon.com/SanDisk-Endurance-microSDHC-Adapter-Monitoring/dp/B07P14QHB7/ref=sr_1_5?crid=1T4O0IB1SABAH&dchild=1&keywords=micro%2Bsd%2Bcard%2B32gb%2Buhs%2B3&qid=1631651555&sr=8-5&th=1. If I don’t hear otherwise, I can order in the next 6 hours and have it by Thursday. I’ll report on results here.
1 Like
I’ve just ordered the SD slot on my side on the Adafruit website. I will be able to give it a test next week!
I can’t say much to SPI access to a MicroSD card, but if you are using the SDIO peripheral, and trying to get it to work on a breadboard, you’re likely running into an issue with the GPIO drive strength. I mentioned it a while back in a github issue.
Try changing these two assignments: here and here to GPIO_SPEED_FREQ_LOW and see if things work better.
If it helps, I’ll make a PR which maps the GPIO drive strength, to the clock frequency as I suggested in that comment.
Unfortunately, @recursinging , that doesn’t seem to make a difference, at least for me. I’d like to suggest that someone else having this problem try it as well, and validate what I’m finding. I changed the mount statement in SDMCC test code to:
FRESULT res = FR_NOT_READY;
while(res != FR_OK)
{
res = f_mount(&SDFatFS, SDPath, 1);
hw.PrintLine("Mount result: %d", res);
System::Delay(1000);
}
The first mount prints FR_NOT_READY (3), and then all subsequent mounts print FR_DISK_ERR (4). This happens exactly the same with both GPIO_SPEED_FREQ_LOW and with GPIO_SPEED_FREQ_VERY_HIGH. Neither case reads or writes successfully.
Hmm… Did you try configuring the peripheral with different clock speeds as well?
No, I hadn’t, and that is, indeed, the fix!! Thanks SO much!! For others that are struggling with this, here’s the block of code in SDMMC that I modified:
// Init SD Card
SdmmcHandler::Config sd_cfg;
sd_cfg.Defaults();
sd_cfg.speed = SdmmcHandler::Speed::SLOW;
sd.Init(sd_cfg);
That’s in addition to the changes to scmmc.cpp that @recursinging suggested.
2 Likes
Great, I’m glad it’s working for you.
Just to clarify what’s going on (at least as I’ve come to understand it), the GPIO_SPEED_FREQ_* configuration affects the “slew rate” of the GPIO signalling. The faster the GPIO speed, the lower the slew rate of the signal, and the sharper the edges.
Sharp signal edges can cause ringing, or oscillations after signal transitions at the resonant frequency of the parasitic capacitance and inductance of the circuit.
A breadboard, and jumper wires have more parasitic capacitance and inductance than a well designed PCB trace, which is why the default configuration of the SDIO peripheral works fine on the Pod, Patch, Petal, and Field, but not so well on a breadboard (or in my case, a not so well designed PCB trace).
You can counteract this by adding some small inline resistance to the signals paths. If you’re curious, give it a try, and you may be able to get the peripheral working at higher clock speeds.
2 Likes