Samsung EVO Select 32GB does not initialize with CircuitPython 3.1.2 on Feather Express M4 with Adalogger

[Helitronix]

First reported here with all the details: https://forums.adafruit.com/viewtopic.php?f=60&t=147212

Basic summary is that the Feather Express M4 / Adalogger hardware works with other micro SD cards that I have now tried, but the Samsung EVO 32GB card fails to initialize with CircuitPython 3.1.2 and the February 4'2019 libraries. The card is properly initialized if I use the SD Cardinfo sample application in Arduino mode. So the hardware is working fine, but something isn't quite right in the CircuitPython stack with this card.

danhalbert asked that I submit the bug here. Thanks for your help!

[kattni]

I was unable to get the same SD card to initialise on the Grand Central running 4.x.alpha. I attributed it to the size at the time, however I don't have any smaller EVO SD cards to test, so I can't be certain. I was able to get an off-brand 8GB SD card to work successfully.

[makermelissa]

I should be getting my Grand Central in the next couple hours and I have some 32GB Samsung EVO cards that I could try.

[makermelissa]

Yeah, I had the same issue on a Grand Central running Beta 2 with the 32GB SD card. I'll have to pull out my collection and try various ones.

[Helitronix]

@kattni
@makermelissa

Thanks for your comments. I have a Transcend 8GB, Sandisk 4GB and Kingston 2GB that do work properly. Of course, the first card I tried was the new 32GB Samsung that didn't work. :-) I'm glad I found something that works, but it sure would be better if these Samsung cards worked, too.

[dhalbert]

Note this previous issue with 32GB Samsung EVO cards, which was fixed on M0.

adafruit/circuitpython#245

Probably worth retesting on an M0 to confirm it’s chip-specific.

[makermelissa]

Ok, I hooked up an SD Card breakout (I don't have the adalogger) to both a Feather M4 Express and a Feather M0 Express and get the following error on both with the 32GB Samsung EVO card:

OSError: timeout waiting for v2 card

Was able to get a SanDisk Ultra 16GB to read just fine. SanDisk Ultra 64GB resulted in no files showing due to a different filesystem, but not the error above.

I forgot to mention both of the feathers were running CP4 Beta 2.

[kattni]

Same issue reported on 4.0beta6 on PyPortal. #15

[devoh747]

The issue still exists in CP 4.0.2 and CP 4.1.0.rc1 using the 20190723 4.x libraries. I used a GrandCentral and a Samsung 32GB EVO. I verified the same setup works under Arduino example code "Datalogger" that is for any SD card.

[devoh747]

I have part of it figured out..

Some SD cards require the CRC info for CMD55 and ACMD41.. so in adafruit_sdcard.py
changing lines..

194 to self._cmd(55, 0 , 0x65)
195 to if self._cmd(41, 0x40000000, 0x77) == 0:

I'm not sure why line 195 was a _block_cmd before.. but making it a _cmd gets it past this. Also not sure why the value 0x200000 was used. The examples on the net use 0x40000000.

It works for my SanDisk 16GB like it did before... There is still an issue but now it is a hang
at line 156 if self._cmd(9, response_buf=csd) != 0:
for Samsung EVO 32GB.. I have not figured out why it hangs and that _cmd function is pretty difficult for a beginner to figure out. I do see a bunch of differences in how buf is setup in _cmd and _block_cmd.. I hope this is helpful.

[devoh747]

The issue is that Samsung EVO 32GB cards require all command codes to have a valid CRC. I used https://github.com/hazelnusse/crc7/blob/master/crc7.cc to calculate all CRC codes and it is now working. On line 195 I also changed one command from a _block_cmd to a _cmd. It would hang otherwise. This works for my SanDisk 16 GB card which worked before the fix as well and also works on my Samsung EVO 32GB. Please test this with all cards. The spec does say that by default all command code CRC values are ignored except CM0, CMD8 and I believe ACMD41.. It's just that Samsung decided to ignore the default and check all command CRC values.. I was not even able to force it off. Please test the heck out of this. My first fix!

[dhalbert]

We believe #20 fixes this.