Weird issue with 2GB SD card
macca
Posts: 780
Hi,
I have recently purchased a couple of no-brand 2GB SD cards from eBay that shows a weird issue: the cards works perfectly on Windows, Linux and on a Canon camera, but fails to work on any other non-PC devices such as a Propeller with an SD card socket, an Arduino UNO with the Datalogger shield and a SD2IEC device (Commodore 64 disk emulator).
I have setup a quick test program with a Propeller and a SD socket. The card answers correctly to all commands, but when I try to read a block it returns garbled data, no matter what I do, the data is always garbled. I always read block 0 just to not mess with the addressing and the card is clean. Just to have an idea, it is like the data is encrypted somehow (but it is not). The same test program (or any other SD card utility) works perfectly with a 1GB Transcend card.
I tried to format the card with the SD Card Formatter utility without changes.
Searching on the 'net doesn't show any useful results, generally the cards works or fails from the beginning, not just the data block read commands.
Is there someone that has experienced a similar issue with SD cards ?
Thanks for any help.
I have recently purchased a couple of no-brand 2GB SD cards from eBay that shows a weird issue: the cards works perfectly on Windows, Linux and on a Canon camera, but fails to work on any other non-PC devices such as a Propeller with an SD card socket, an Arduino UNO with the Datalogger shield and a SD2IEC device (Commodore 64 disk emulator).
I have setup a quick test program with a Propeller and a SD socket. The card answers correctly to all commands, but when I try to read a block it returns garbled data, no matter what I do, the data is always garbled. I always read block 0 just to not mess with the addressing and the card is clean. Just to have an idea, it is like the data is encrypted somehow (but it is not). The same test program (or any other SD card utility) works perfectly with a 1GB Transcend card.
I tried to format the card with the SD Card Formatter utility without changes.
Searching on the 'net doesn't show any useful results, generally the cards works or fails from the beginning, not just the data block read commands.
Is there someone that has experienced a similar issue with SD cards ?
Thanks for any help.
Comments
These were common a number of years ago.
Why oh why oh why. For the price of a pizza I can pick up SanDisk 8GB or 16GB. Skip the pizza, not the good SD card.
Maybe these SD cards do not support SPI access. The PC and your Camera use SD mode, and the non-PC devices use the SPI mode.
Andy
If it doesn't support SPI it should not return an error or something unreadable for other commands other than CMD0 ?
All commands returns a response, I can read CSD, CID and OCR. Even the data block follows the protocol (few FF followed by the FE start token, 512 bytes data, 2 CRC).
It is about 4 months that I don't eat pizza (and I'm in Italy...). They looked good to be used for SD2IEC and MaxDuino devices and I purchased along with other memory devices (that shows other problems...). Of course now I'll stay away from these no-brand devices.
What does Windows to be spoofed ? All documents I found lists the same exact initialization sequence and AFAIK, there is nothing sent to the card that could identify the host. Maybe it is the adapter wiring that is different. All SD cards I have works, and some are very old, only these shows this problem.
No, that's not the case, the size is reported correctly (or I hope so), I have put some files on them and are all working. Of course I haven't filled them completely so maybe they are 512MB instead of 2GB, but the problem I have is that I can't read any data from them.
To give you an idea, this is a log of the commands and responses:
SD SPI Test Send CMD0 [40 00000000 95] R1 = 01 Send CMD8 [48 000001AA 87] R1 = 01 00 00 01 AA Send CMD55 [77 00000000 65] R1 = 01 Send CMD41 [69 00000000 E5] R1 = 01 Send CMD55 [77 00000000 65] R1 = 01 Send CMD41 [69 00000000 E5] R1 = 01 Send CMD55 [77 00000000 65] R1 = 01 Send CMD41 [69 00000000 E5] R1 = 00 Send CMD9 [49 00000000 AF] R1 = 00 CSD = 00 7F 00 32 53 5A 83 B6 6E BB FF 9F 16 80 00 87 F4F3 Send CMD10 [4A 00000000 1B] R1 = 00 CID = 00 30 00 41 50 50 53 44 00 00 00 09 9A 01 44 4D CAB9 Send CMD58 [7A 00000000 FD] R1 = 00 OCR = 80 FF 80 00 Send CMD17 [51 00000000 55] R1 = 00 63 A0 A7 88 B7 8B 23 02 55 C9 B7 6B B5 BD E4 EC | c.....#.U..k.... AD 88 46 17 01 F2 5E 9D 09 A3 4B E1 57 C3 47 BA | ..F...^...K.W.G. C4 B0 5A A3 3D 49 73 36 EE F3 FE C8 FD 6D 7E 25 | ..Z.=Is6.....m~% 50 34 A6 77 4E C2 9E BA 4C F8 61 B1 00 22 87 1E | P4.wN...L.a..".. B3 FA EE 18 29 38 E2 69 FB CD 9E E4 13 92 94 32 | ....)8.i.......2 75 4B 83 B6 11 90 6A F7 9F 93 4E E9 3E AD 99 77 | uK....j...N.>..w 81 7A DC 68 6D 49 F0 27 24 60 08 0B 84 1F 94 EB | .z.hmI.'$`...... 49 45 43 C1 2B EC B8 39 77 E0 69 03 7D 46 29 C3 | IEC.+..9w.i.}F). 5D 69 36 A7 6A B2 96 21 C5 FA 56 E6 BD A6 89 35 | ]i6.j..!..V....5 34 7E C1 CB B6 F2 97 68 1D F2 95 4E D6 EA 70 54 | 4~.....h...N..pT 76 0A 0F 2A 93 FF DC B1 11 21 B9 1C EC 1E F4 37 | v..*.....!.....7 EA 15 1D 4D 69 C4 8F 97 06 0D 03 82 8C 13 DB 12 | ...Mi........... 37 29 88 37 58 14 74 50 CA EF FF A9 C8 57 72 B8 | 7).7X.tP.....Wr. D0 6D F0 0A 53 D9 C0 DF F4 C4 ED C6 02 49 A5 CF | .m..S........I.. E7 45 BA 57 6D B8 D8 F9 DB 1F 30 EE 6A 13 7C C7 | .E.Wm.....0.j.|. 35 47 5E 36 B7 72 8C F7 A7 AB 28 AD 40 C9 C7 9A | 5G^6.r....(.@... 4C 65 F6 1D 9B 77 1D 92 D6 CB 82 0A A4 E4 46 66 | Le...w........Ff F2 6C E7 9B F5 74 3E 39 E3 32 43 52 F4 8C A5 E2 | .l...t>9.2CR.... D8 84 D3 E0 15 5C BD 3F 9F 2D CB 01 FE 5A 90 AA | .....\.?.-...Z.. 63 7E AB 27 80 20 F9 8D 49 7B DE A7 C1 EB 4C 40 | c~.'. ..I{....L@ F4 23 20 AE F8 88 63 BB A3 E8 E4 8A D3 81 43 A9 | .# ...c.......C. BA DE 33 AA 08 C8 11 91 7B D2 B2 82 06 2A F7 4B | ..3.....{....*.K C7 F7 8F E4 1B FB 88 91 75 B7 CF 09 C3 FE D6 6D | ........u......m 33 EA 32 2C 09 74 1F 53 55 9C 62 2E 95 B1 DF BC | 3.2,.t.SU.b..... 77 B5 D3 AB B8 8F DB 4A 51 6A B5 E0 26 F5 B0 53 | w......JQj..&..S FF EE 2F 06 13 AC 33 F8 FE D8 60 43 28 1A 9E FB | ../...3...`C(... CF B9 DD 09 4A D9 26 77 89 8F 89 5D 58 C1 AA 23 | ....J.&w...]X..# 07 85 71 C1 0E 23 AD 16 E9 82 2B 58 4A A8 1A 2A | ..q..#....+XJ..* 98 28 65 2F 9C AA D9 ED 62 84 61 26 82 49 C5 93 | .(e/....b.a&.I.. 7F 24 2E 50 52 74 22 BE D0 76 E5 EA A9 18 EC 08 | .$.PRt"..v...... 16 6B 6C 9B 69 2E FD 72 A5 B1 48 51 87 80 27 F1 | .kl.i..r..HQ..'. 14 59 BD 29 F7 9A 31 40 FE B6 5F 94 1D 6E 2A BF | .Y.)..1@.._..n*.As you can see, all commands works correctly, but reading sector zero (which should be the MBR) returns garbled data. The same commands works correctly with all other cards I have.
If I read the card from Linux using dd the sector data is correct.
That happens with every non-PC device I have (except the camera).
Ok looks like you are sending the correct crc for each command. Only command 0 and 8 requires the correct crc so try sending crc=$87 or $95 on the other commands in case command 17 crc is wrong.
Also i see you are sending cmd 55 then 41 three times. I’ve only ever sent them once.
What program are you using to drive the SD card? Do you have any pullups on the sd card pins? Do you have a 10uF and 100nF X7R right at the sd power pins? What is the length of the tracks/wires from P1 to SD card?
However I accept that there is an academic challenge here. Why does it seem to work in a PC but not on the Prop. It seems to respond over SPI but remember that SD cards are not the same as SDHC cards. With the old SD cards the initialization is a little different plus they accessed memory in bytes rather than blocks. But I remember many years ago when 2GB were very hard to get, that I could only get these no-name ones, so I ordered 100 of them at a good price since I needed them for an older product. They seemed to work, but the customer sent them all back to me because they weren't working properly. I had to go and chase down some other 2GB card which at least had a brand name, although not a premium one.
I think they were actually crippled SDHC cards rather than the older SD, that was the main problem and perhaps that is what is happening here.
So looking through that initialization sequence it should be CMD0, CMD8, then CMD58 is recommended but ACMD41 is next etc. Not CMD55 which is an application specific command.
BTW, as long as the CMD0 and CMD8 CRCs are correct, then it doesn't matter what the crc is after that. Since CMD0 and CMD8 are fixed, just use $95 for CMD0 and $87 for CMD8 and anything else.
I have added the correct crc just in case it wasn't exactly following the specs, but also with the crc set for commands 0 and 8 only and using FF for all others doesn't make any difference. CMD17 crc looks good to me, what should it be ?
The specs say that it should be resent until the response is 00 which means the card is initialized. This is the only difference I can see from other cards, the initialization takes a lot of time, up to 20-25 seconds from the first attempt at power up. After that it takes 2-3 attempts. This is also a difference with the PC, when I put the card on the SD slot it is seen immediately, clearly there is something different either with the initialization or how the connector is wired.
I wrote a simple test program in C, also tested with SD-MMC_FATEngine in spin but it is a nightmare to debug that because it uses abort statements that make things a bit hard to track.
The circuit is very simple, tracks are a couple of cm from the Propeller, I don't have capacitors near the SD socket, I can try to add one if could be a power glitch.
I asked if someone had a similar experience, just that. I know I have thrown away some money and clearly I can't use these cards for what I want to do, but I wasn't expecting that kind of problem and now I'm just curious to see if it can be fixed. If not, ok, not a problem.
Yes, ACMD41 is 55 followed by 41, I haven't prefixed it with an A.
The CSD from my 64GB card.
More info:
TAQOZ# .DISK --- CARD: SANDISK SD SC64G REV$80 #35190404 DATE:2018 /10 *** OCR *** VALUE........................... $C0FF_8000 RANGE........................... 2.7V to 3.6V *** CSD *** CARD TYPE....................... SDHC LATENCY......................... 1ms+1400 clocks SPEED........................... 50MHz CLASSES......................... 0 1 0 1 1 0 1 1 0 1 0 1 BLKLEN.......................... 512 SIZE............................ 62,367MB Iread Vmin...................... 10ma Iread Vmax...................... 25ma Iwrite Vmin..................... 60ma Iwrite Vmax..................... 35ma *** SPEEDS *** LATENCY......................... 473us,255us,255us,272us,255us,311us,310us,300us, SECTOR.......................... 469us,488us,489us,506us,487us,544us,541us,531us, BLOCKS.......................... 2,109kB/s @200MHz *** MBR *** PARTITION....................... 0 00 INACTIVE FILE SYSTEM..................... FAT32 LBA CHS START....................... 1023,254,63 CHS END......................... 0,0,0 FIRST SECTOR.................... $0000_8000 TOTAL SECTORS................... 124,702,720 = 63,847MB 00170: 0000_0000 0000_0001 0002_0000 506F_7250 '............ProP' *** FAT32 *** OEM............................. TAQOZ P2 Byte/Sect....................... 512 Sect/Clust...................... 64 = 32KB FATs............................ 2 Media........................... F8 Sect/Track...................... $003F Heads........................... $00FF Hidden Sectors.................. 32,768 = 16MB Sect/Part....................... 124,702,720 = 63,847MB Sect/FAT........................ 15,222 = 7MB Flags........................... 0 Ver............................. 00 00 ROOT Cluster.................... $0000_0002 SECTOR: $0000_F70C INFO Sector..................... $0001 = $0000_8001 Backup Sector................... $0006 = $0000_8006 res............................. 00 00 00 00 00 00 00 00 00 00 00 00 Drive#.......................... 128 Ext sig......................... $29 OK! Part Serial#.................... $6269_0201 #1651048961 Volume Name..................... P2 CARD FAT32 ok TAQOZ# $F70C OPEN-SECTOR --- ok TAQOZ# 0 $40 SD DUMP --- 00000: 52 4F 4F 54 44 49 52 20 20 20 20 08 00 00 00 00 'ROOTDIR .....' 00010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 '................' 00020: 54 41 51 4F 5A 20 20 20 52 4F 4D 20 00 00 00 00 'TAQOZ ROM ....' 00030: 21 00 AE 50 00 00 00 00 21 00 03 00 00 00 02 00 '!..P....!.......' okYou definitely need bypass and bulk caps right at the SD pins. I've seen short traces (not a few cm) from the PS fail. This is fundamental 101.
The SD card is supposed to respond with busy until it's ready. Never sent the commands more than once. I typically see delays sub 1 second until the card is ready.
As for the PC, it is likely not using SPI but the 4bit parallel mode (sort of SPI but the card is in a completely different mode after the first command(s).)
I don't send the correct crc after cmd0 and cmd8. If you do, then you are probably telling the card that crc will always be used, and if it's wrong it may fail.
@macca - what test program are you using? Some older drivers only expected SD cards for instance, and some of the newer ones only expect SDHC etc.
You can turn it on in SPI mode if you want, but we don't.
From the SD Spec:
That's interesting, I've always used bypass only. Pity I have a test board already at the manufacturer's site. Next time I'll keep in mind. Thanks.
Massimo
About the original question, scrambled data, I wonder if it could have something to do with setup time? Setup time violations can definitely scramble data. However, that doesn't seem a likely explanation either, when reading a block that is supposed to be all or mostly zeros.