-
Notifications
You must be signed in to change notification settings - Fork 7.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failed to initlialize/mount 32GB and 64GB sdcards (IDFGH-9144) #10542
Comments
@listout Here are a few things you can do to troubleshoot this:
|
|
There can be multiple reasons for the issue at this stage of card initialization process, most common ones are:
To figure out which of these is the case we need to know whether
Usually the easiest way is to check that using a logic analyzer. If you have access to a known-good hardware (like ESP32-WROVER-KIT board), testing the card with that hardware can also provide a clue. |
@igrr I've managed to get my hands on a Logic Analyzer. I'm not sure how to share the data with you. I'm using salae software where I can either export as csv or save the session. I'm attaching SS and save session for a working vs non-working card. Hope this helps in debugging. Channel 0 was my MOSI and 1 was MISO Not working Card SS Saved Sessions: saves.zip |
I also encountered the same problem. Any update about this? |
ACMD41 argument is different between SD mode and SPI mode. In SPI mode, the only non-zero bit may be the HCS bit. Unlike the SD mode, the bits reflecting the host's OCR should be zero. Previously, we used to set these bits the same way as for the SD mode. This has caused certain cards to fail initializing, apparently their controllers have checked the ACMD41 argument more strictly and refused to finish initialization, resulting in an error such as sdmmc_common: sdmmc_init_ocr: send_op_cond (1) returned 0x107 (Note that this error may have other causes than the one fixed in this commit. For example, if the card doesn't have a sufficient and stable power supply, it may also fail to complete the internal initialization process, and will never clear the busy flag in R1 response.) Closes #6686 Closes #10542
ACMD41 argument is different between SD mode and SPI mode. In SPI mode, the only non-zero bit may be the HCS bit. Unlike the SD mode, the bits reflecting the host's OCR should be zero. Previously, we used to set these bits the same way as for the SD mode. This has caused certain cards to fail initializing, apparently their controllers have checked the ACMD41 argument more strictly and refused to finish initialization, resulting in an error such as sdmmc_common: sdmmc_init_ocr: send_op_cond (1) returned 0x107 (Note that this error may have other causes than the one fixed in this commit. For example, if the card doesn't have a sufficient and stable power supply, it may also fail to complete the internal initialization process, and will never clear the busy flag in R1 response.) Closes #6686 Closes #10542
ACMD41 argument is different between SD mode and SPI mode. In SPI mode, the only non-zero bit may be the HCS bit. Unlike the SD mode, the bits reflecting the host's OCR should be zero. Previously, we used to set these bits the same way as for the SD mode. This has caused certain cards to fail initializing, apparently their controllers have checked the ACMD41 argument more strictly and refused to finish initialization, resulting in an error such as sdmmc_common: sdmmc_init_ocr: send_op_cond (1) returned 0x107 (Note that this error may have other causes than the one fixed in this commit. For example, if the card doesn't have a sufficient and stable power supply, it may also fail to complete the internal initialization process, and will never clear the busy flag in R1 response.) Closes #6686 Closes #10542
ACMD41 argument is different between SD mode and SPI mode. In SPI mode, the only non-zero bit may be the HCS bit. Unlike the SD mode, the bits reflecting the host's OCR should be zero. Previously, we used to set these bits the same way as for the SD mode. This has caused certain cards to fail initializing, apparently their controllers have checked the ACMD41 argument more strictly and refused to finish initialization, resulting in an error such as sdmmc_common: sdmmc_init_ocr: send_op_cond (1) returned 0x107 (Note that this error may have other causes than the one fixed in this commit. For example, if the card doesn't have a sufficient and stable power supply, it may also fail to complete the internal initialization process, and will never clear the busy flag in R1 response.) Closes #6686 Closes #10542
ACMD41 argument is different between SD mode and SPI mode. In SPI mode, the only non-zero bit may be the HCS bit. Unlike the SD mode, the bits reflecting the host's OCR should be zero. Previously, we used to set these bits the same way as for the SD mode. This has caused certain cards to fail initializing, apparently their controllers have checked the ACMD41 argument more strictly and refused to finish initialization, resulting in an error such as sdmmc_common: sdmmc_init_ocr: send_op_cond (1) returned 0x107 (Note that this error may have other causes than the one fixed in this commit. For example, if the card doesn't have a sufficient and stable power supply, it may also fail to complete the internal initialization process, and will never clear the busy flag in R1 response.) Closes espressif#6686 Closes espressif#10542
Answers checklist.
IDF version.
v5.0
Operating System used.
Linux
How did you build your project?
Command line with idf.py
If you are using Windows, please specify command line type.
None
Development Kit.
ESP32-PICO-DevKitM-2
Power Supply used.
USB
What is the expected behavior?
Mount/initialize sd card successfully.
What is the actual behavior?
Cannout mount/initialize SD card. Initialization fails with
sdmmc_common: sdmmc_init_ocr: send_op_cond (1) returned 0x107
.Similar issue to this thread on forum.
Steps to reproduce.
Debug Logs.
More Information.
SD card used was SanDisk Ultra microSDHC UHS-I card of 32 GB, same issue with 64 GB. Adapter was just a generic micro sdcard adapter found on Amazon.
The text was updated successfully, but these errors were encountered: