SPI init (microcontroller) stuck in TimeoutWaitNotBusy,

[andreyk0]

Looked at the init sequence and saw 0xFF issued before CMD0, this PR fixes the issue for me.

Thanks!

[ost-ing]

Also facing this issue with an STM32H7. Trying to use this library with the SPI Block Device. I have confirmed my SPI works fine without this library. When using the library, SPI_CLK and SPI_CS are toggling properly, but no data is coming out of the SPI_MOSI line.

I tried your fix from your PR and it did work for me, thank you for that :)

Any reason why the PR was closed?

Kind regards

[andreyk0]

Hi, I closed PR because I've tried exact same code on a different microcontroller board and there was a different init issue there (that one looked like card wasn't ready to receive CMD0 right after CS was brought low, i.e. affected by this patch). Then I tried to find more docs / articles about SD and people recommend different things. What's done in this library matches at least some of those recommendations. In the end I just tried to grab more SD cards out of my junk box and the newer ones seemed to work Ok without the patch. The right thing to do is to obviously read the specs but those are very long and I'm yet to find a good concise doc that explains proper init that works for older and newer cards. Sorry.

[JoNil]

I just ran into this issue as well, i tried the path in the closed pr and that soled it for me as well. I'm running on an raspberry pi pico with an old 4GB sd card.

[kirbylife]

I had the same thing happen to me with a Raspberry Pi Pico, my SPI code works fine with other devices, I will try the PR to see if that solves the error for me.

[thejpster]

Do you have (weak) pull-ups on your SPI lines? I had terrible trouble without them.

[derchr]

The PR fixed it for me too, thanks!

[mdarrik]

So if this is helpful, I tested the code in the current version of the linked PR, and it didn't seem to work for me out of the box. What I found was that if I flashed an example using an Arduino example, this lib would work for me suddenly until I removed the card or the controller lost power.

However, if I wrote CMD0 over SPI before trying to initialize + acquire the block device, everything worked.

Looking into SDFat a bit more, it looks like it doesn't wait for ready if the command being sent is CMD0 or CMD12. So it might be worth merging the 2 approaches tried in the branch's history together: flushing the card & sending CMD0 without waiting for not busy.

Edit: branch with suggested fix applied: https://github.com/mdarrik/embedded-sdmmc-rs/tree/skip-wait-init-sequence

[thejpster]

Great. Any luck when testing that branch?

[mdarrik]

Yeah. The branch I shared I've been able to use pretty reliably the past few days. At least for the project I was using where the existing PR wasn't working.

[elpiel]

I have a bunch of MicroSD cards from quite old (with 1 GB) to a brand new SandDisk Extreme (64GB) that I can test this on.

For reference, the new SandDisk does not work currently.

[elpiel]

With the new SanDisk (64GB) it works! Here are 2 of the initial responses when acquire is called with @mdarrik branch which usually ends up causing TimeoutWaitNotBusy in the current implementation.

0.001253 WARN  Got response: 3f, trying again..
└─ embedded_sdmmc::sdmmc::{impl#2}::acquire_with_opts::{closure#0} @ /mnt/Disk/Projects/lechev.space/embedded-sdmmc-rs/src/sdmmc.rs:211
0.001429 WARN  Got response: 7f, trying again..
└─ embedded_sdmmc::sdmmc::{impl#2}::acquire_with_opts::{closure#0} @ /mnt/Disk/Projects/lechev.space/embedded-sdmmc-rs/src/sdmmc.rs:211

3f = 63 7f = 127

I'm not sure what those values mean and I couldn't find them in SdFat

[thejpster]

According to the error, that's an unexpected R1 response to a CMD0. Looking at https://www.sdcard.org/downloads/pls/pdf/?p=Part1_Physical_Layer_Simplified_Specification_Ver9.00.jpg&f=Part1_Physical_Layer_Simplified_Specification_Ver9.00.pdf&e=EN_SS1_9 Section 7.3.2.1, the R1 response is:

• Bit 7 - must be 0
• Bit 6 - Parameter Error
• Bit 5 - Address Error
• Bit 4 - Erase Sequence Error
• Bit 3 - COM CRC Error
• Bit 2 - Illegal Command
• Bit 1 - Erase Reset
• Bit 0 - In Idle State

We want 0x01. If we get 0xFF, the card is busy and hasn't responded yet. If we get anything else after sending CMD0 (GO_IDLE) I don't think there's anything we can do except try again.

[elpiel]

yes, I suspect this might be part of their proprietary technology as they mention that higher speeds require such one.

I just wanted to point out that this branch solved the issue for me. I could try and test other SD cards but if a brand new one has this issue then I guess that's enough of a validation for the fix? @thejpster do you have any other concerns?

[thejpster]

No, I'm fine with it.

[thejpster]

I think with the pending 0.5.0 release this is now better? Please try it!