Weird issue with 2GB SD card

macca · 2020-06-11 09:21

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.

Cluso99 · 2020-06-11 10:45

Sounds like you might have one of the fake cards that spoof windows

These were common a number of years ago.

Peter Jakacki · 2020-06-11 11:55

macca wrote: »

Hi,
I have recently purchased a couple of no-brand 2GB SD cards from eBay

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.

Ariba · 2020-06-11 13:02

macca wrote: »

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).
...

Thanks for any help.

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

macca · 2020-06-11 15:05

Ariba wrote:

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.

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).

Peter Jakacki wrote:

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.

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.

Cluso99 wrote:

Sounds like you might have one of the fake cards that spoof windows
These were common a number of years ago.

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.

Cluso99 · 2020-06-12 08:22

The fake SD cards that were available years ago reported the fake size to windows and formatted as though they worked. But they were tiny sizes and once you put data files on them they crashed. The fact that they spoofed windows allowed vendors in the back alleys to fool buyers that they were legitimate even tho they weren’t.

macca · 2020-06-12 09:13

Cluso99 wrote: »

The fake SD cards that were available years ago reported the fake size to windows and formatted as though they worked. But they were tiny sizes and once you put data files on them th ET y crashed. The fact that they spoofed windows by vendors in the back alleys was used to sell them.

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.

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000080  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000100  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000120  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000130  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000140  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000150  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000160  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000170  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000180  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000190  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001b0  00 00 00 00 00 00 00 00  40 df c7 cc 00 00 00 02  |........@.......|
000001c0  06 00 06 3f ff c4 83 00  00 00 3d 5e 3b 00 00 00  |...?......=^;...|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|

That happens with every non-PC device I have (except the camera).

Cluso99 · 2020-06-12 11:03

Only guessing...
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?

Peter Jakacki · 2020-06-12 11:38

I don't get it. Why all this fuss over dollar store junk? All the local stores are trying to get rid of brand-name 16GB cards because they are "old". What does that say about 2GB no-names?

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.

macca · 2020-06-12 13:17

Cluso99 wrote: »

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.

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 ?

Also i see you are sending cmd 55 then 41 three times. I’ve only ever sent them once.

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.

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?

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.

Peter Jakacki wrote: »

I don't get it. Why all this fuss over dollar store junk? All the local stores are trying to get rid of brand-name 16GB cards because they are "old". What does that say about 2GB no-names?

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.

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.

Yes, ACMD41 is 55 followed by 41, I haven't prefixed it with an A.

Peter Jakacki · 2020-06-12 13:43

Ah yes, of course, ACMD41. CMD9 CSD info seems to indicate that it is an SDHC card, addressed in blocks rather than bytes (last byte $87 2 msbs). Normally 2GB cards were just plain byte addressable SD and the 2 top csd bits were 00.

The CSD from my 64GB card.

TAQOZ# csd 16 DUMP --- 
019A0: 40 0E 00 32  5B 59 00 01  DB D3 7F 80  0A 40 40 DF     '@..2[Y.......@@.' ok
TAQOZ# 127 126 CSD@ .BIN --- %01 ok

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....!.......' ok

Cluso99 · 2020-06-13 05:11

A few things here...

You 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.

Peter Jakacki · 2020-06-13 07:46

@Cluso - the card ignores the crc after cmd8 so it doesn't matter if you do it right or not.

@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.

Cluso99 · 2020-06-13 11:49

Peter, it’s my understanding crc is optional on sd SPI. As I don’t recall there being a command to enable it, I presume if you send crc then the card will determine that it is being used and as such will continue to check crc. Otherwise how would the card know to check crc on write sectors? I think crc is always sent from the card tho.

Peter Jakacki · 2020-06-13 11:57

Cluso99 wrote: »

Peter, it’s my understanding crc is optional on sd SPI. As I don’t recall there being a command to enable it, I presume if you send crc then the card will determine that it is being used and as such will continue to check crc. Otherwise how would the card know to check crc on write sectors? I think crc is always sent from the card tho.

You can turn it on in SPI mode if you want, but we don't.

From the SD Spec:

7.2.2 Bus Transfer Protection
Every SD Card command transferred on the bus is protected by CRC bits. In SPI mode, the SD Memory
Card offers a CRC ON mode which enables systems built with reliable data links to exclude the hardware
or firmware required for implementing the CRC generation and verification functions.
In the CRC OFF mode, the CRC bits of the command are defined as 'don't care' for the transmitter and
ignored by the receiver.
The SPI interface is initialized in the CRC OFF mode in default. However, the RESET command (CMD0)
that is used to switch the card to SPI mode, is received by the card while in SD mode and, therefore,
shall have a valid CRC field.
Since CMD0 has no arguments, the content of all the fields, including the CRC field, are constants and
need not be calculated in run time. A valid reset command is:
0x40, 0x0, 0x0, 0x0, 0x0, 0x95
After the card is put into SPI mode, CRC check for all commands including CMD0 will be done according
to CMD59 setting.
The host can turn the CRC option on and off using the CRC_ON_OFF command (CMD59). Host should
enable CRC verification before issuing ACMD41.
The CMD8 CRC verification is always enabled. The Host shall set correct CRC in the argument of CMD8.
If CRC error is detected, card returns CRC error in R1 response regardless of command index.

Cluso99 · 2020-06-13 12:29

Thanks Peter

max72 · 2020-06-13 12:52

Cluso99 wrote: »

A few things here...
You 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.

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

Tracy Allen · 2020-06-17 17:29

The bulk capacitor is most important if you have to cold insert the card, or, if the power to the card is turned on and off programmatically. The cards draw a substantial inrush current, several hundred mA, when power is applied. That current can be supplied by ~100µF placed near the SD pins, and or, better yet, by a current limiting circuit/FET. In normal operation, the card draws ~100mA peak for writing data.

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.

Weird issue with 2GB SD card

Comments