resolve msc sdcard example conflict with host espcially macos#533
resolve msc sdcard example conflict with host espcially macos#533
Conversation
- use SDIO (pio) for rp2040/rp2350 - remove printing flash/sdcard contents to Serial since it conflict with host, which can cause conflict in spi/sdio transport and/or correupt cache,sector
|
I'm not seeing the SD card on MacOS, but the flash continues to be shared successfullly. Just to confirm I'm running this PR's updated sketch and updated SdFat. I can dig more into what macOS thinks is going on. Moving the same board to my Ubuntu laptop I see the microSD being shared. I can read / write files without issue. |
|
After removing power from the Metro RP2040 and bringing it back to macOS a working read/write auto-mounted microSD appeared. I'm guessing a hard reset is necessary since the board is correctly sharing the drive after being unplugged / replugged. I had been doing soft resets. I did a quick drive test with a 10MB file going through the Metro RP2040 microSD and compared with with a directly connected (remove the controller and use a USB adapter). Probably what you expect to see. Read speed is crazy fast, but that must be caching so not a fair comparison. |
|
Great, thank you for testing. you can try usign the old SPI by comment out the SDIO_CMD/CLK/DATA_PIN and define the SDCARD_CS to see if the speed is actual improved using new SDIO (pio) |
|
I disabled SDIO and gave SPI a try. That was a good test. SPI is 6x slower than SDIO |
|
Card reader is usb highspeed while rp2040 is full speed 12 Mbit/s i.e 1.5 MB/s so 1.25Mbyte is as good as you can get. I think we can merge this now. Thank you very much for your effort to try and test this issue @ladyada we get at least 3x for sdcard using pio as sdio. Note that somehow I cannot get metro rp2350 working with it. Maybe I miss some settings, will try to fix it next week |
|
hmm it should work but to be honest we didn't try it, do you want to buy https://www.adafruit.com/product/4682 and try wiring it up to any other pins |
|
yeah, not sure why, will test it further, and make an PR to fix later. |
|
@ladyada I used an exterrnal sdcard breakout with pin 22,23,8,9,10,11 and it seems to work well. I think the upstream SdFat currently does not support GPIO that is larger than 31/32 g_pio->input_sync_bypass |=
(1 << g_clkPin) | (1 << g_cmdPin) | (0XF << g_dat0Pin);I will file an issue and try to see if we can make a PR to upstream |
|
@ladyada once I have manage to fix the GPIO > 32 issue with adafruit/SdFat#35, I just realize that upstream just fixed it a few days ago, though it is pushed to SdFat-beta repo greiman/SdFat-beta@e8208b1 which is scheduled to release as 2.3.1 soon. Instead of waiting, I think we can just go ahead and merge with SdFat-beta for now and do the sync later on if there is any other commit. |
|
yes please! thank you :) |
|
update: I am backing off from SdFat-beta, since there is lots of refactor and rename, which is time-consuming to cherry pick and re-sync. It is probably faster to apply simple fix in adafruit/SdFat#35 and do simple sync/merge with upstream later :) |
|
thats fine |
|
https://github.com/adafruit/SdFat/releases/tag/2.3.53 is released and fixed issue with high GPIO for now, we will sync with upstream when it is released later. |
|
I had the opportunity to do an updated read / write test using the RP2350 changes @hathach has recently made to the Adafruit SdFat. I tried using my fastest microSD. |
|
superb! thank you @mikeysklar for detail testing. |
|
yay thanks for the thorough test. cc @caternuson ^ |

@mikeysklar let me know if this works for you (you need to update Sdfat to v2.3.50)
PS: The conflict happen with macos more often since macos does lots of hidden writing of meta data file e.g
.DS_Store