I’m trying to add SD card storage to my SBC, bit-banging SPI over a 65C22. I’ve cleared the first hurdle of basic communication with the device, but I’m failing at the second, which is getting the card to initialize. Here’s what I’m doing, in case there are any gotchas that jump out to anyone:

I’m using an Adafruit micro-SD breakout board (https://www.adafruit.com/product/254). The CD, CS, MISO, and MISO lines are tied to +5 through 10kOhm resistors. CLK, MOSI, and CS are attached bits 0, 1, and 2 of port B on my 65C22; MISO is bit 7.

After 80 clock pulses, I send CMD0 with CS low and get back a 0x01 response, as expected. I send FF with CS high, and then with CS low again, send CMD8 with parameter 0x1AA. I get back 0x01 with the parameter mirrored. So far, so good.

I then start looping, sending CMD55 (with a zero’d parameter block) and then ACMD41 (with bit 20 of the parameter block set, to select the operating voltage). However, even after hundreds of loops, I never any response other than 0x01 (idle). (I’m uncertain if this parameter for ACMD41 matters. I was using a zero block before and it behaved the same way; some online source suggested the parameter issue).

I send an FF with CS held high before each command block is sent.

I’ve tried this with multiple SD cards; they’re all formatted to FAT16, and so limited to 2GB, although they actually have capacities of 16G and 32G. I’ve checked through other people’s code and don’t see any problematic differences from mine; in fact, I extracted the initialization code from Dolo Miah’s code and it seems to have the same results (or lack thereof) as mine. (Further indication that the basic card communication is working is that I get an appropriate response if I send a CMD58 to read the OCR.)

I’m hoping that someone with more experience in this area can make some suggestions for ways I might try to diagnose or resolve this problem!

One thing that struck me is that the effective frequency at which data is being sent and received is around 80kHz. Could it be that that’s just too slow to work with modern cards? Communication seems to be working okay, though, so perhaps I should look somewhere else for the problem?

--p.

According to (link), it should be bit 30 that is set, not 20.

It also states that "The initialization process can take hundreds of milliseconds (large cards tend to longer), so that this is a consideration to determin[e] the time out value."

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

I only need that bit 30 set for high-capacity cards. I'll confess I haven't been sure whether these are technically high capacity or not, but I'll try it anyway. (When I read OCR with CMD58, it doesn't seem to signal that the card is high-capacity, but perhaps that's something I need to set myself. Worth a go.)

I was bearing in mind the "multiple hundreds of ms" warning -- it's been having plenty of time (a second or more). But patience is indeed a virtue...

--p.

_________________
Mite 6502: http://www.dourish.com/projects/mite.html

I did read that some cards use the clock to do their processing with, so if you drive in a slow clock it will take longer. I suppose it's possible there is even a minimum frequency, so you could perhaps find a way to clock faster (maybe even in idle periods when you have nothing else to do.)

I would be sure that a high capacity card is still high capacity even if you only put a small filesystem on it.

BigEd/Alarm Siren, you totally called it. I wasn't following the instructions for "high capacity" cards... although I suspect that, these days, pretty much any card you pick up is a high capacity card (and I should have noted the SDHC logo on the packaging).

It's working now -- thanks!

--p.

_________________
Mite 6502: http://www.dourish.com/projects/mite.html

That's great!

dourish, this is something I've been interested in for a long time but just haven't gotten around to working out. When you get everything going and debugged, I look forward to your posting all your code and other relevant info.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

What Garth said: something I've been interested in for a long time but haven't gotten around to working out! Do please share your progress when you're ready.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Sure, guys, happy to. Right now, I'm building support in via my FORTH implementation, but it should be usable in other ways too. Once I've got reading, writing, and some basic FAT16 support going, I'll post it.

_________________
Mite 6502: http://www.dourish.com/projects/mite.html

By definition, any SD card with a capacity greater than 4GB is high capacity, because standard SD cannot support larger capacities. Most 4GB cards are also SDHC, though they do not technically have to be.

I believe that SDXC cards are >32GB, though they're exactly the same as SDHC except they have a variable block size, whereas SDHC's is fixed. So, if you treat all cards as having variable block sizes, you automatically support both HC and XC.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

I second that. Because of the 32 bit address barrier cards up to 4GB are addressed by the address of the first byte of the block (e.g. $600 addresses block 3 with blocksize = 512) while cards > 4GB are addressed by block number and the blocksize is fixed at 512.

SDXC cards come formatted with the proprietary exFAT and aren't supported by many vendors because of the Microsoft license fee. With non Microsoft tools these cards can usually be reformatted to FAT16. There is no physical barrier to force you to use exFAT.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

Not exactly - the difference between SDHC and SDXC on a physical level is limited. The main difference is that the c_size field is increased from 16 to 22 bits, and internally that corresponds to a maximum capacity change from 32GB to 2TB. Both SDHC and SDXC use the same fixed size blocks.

(For some reason this information is now increasingly difficult to find on the net, even Wikipedia is down to talking about speed and filesystems, not technical specificiations.)

I was always under the impression that SD, at least, had fixed size blocks whilst SDHC and SDXC did not. In practice, SDHC cards always had the same block size which led to incompatibilities when larger cards were brought out which needed to increase the block size to allow for the extra space, but older card readers assumed the block size instead of actually checking it. That, and the switch to the exFAT filesystems, was what I believed was the fundamental difference between SDHC and SDXC. Obviously I was mistaken.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

Hi dourish, I noticed you tried using my code and it didn't seem to help. So I have been using 1GB cards (FAT16 format) and they worked - but I confess that the initialisation was simplified it so the point it would work with what I had. In particular they do not set bit 30 of the ACMD41 parameter..

So you did indeed need to set bit 30 (i.e. 0x40000000) because you have a high capacity card to get it to respond, which is what I suspected. But I remember seeing so many conflicting and confusing instructions on the web, I was just happy to get the cards I had to initialise. I have also done other naughty things like assuming the MBR sector number. But I may look at this again in case I need to use different SD cards.

Hopefully other bits of code were useful for you. If you are looking in to FAT16, then the sdfs.s code provides the basic capabilities I needed, with some constraints (no directories, short file names, no timestamp). It's a fairly small footprint with these restrictions, which was a consideration for me due to 16KB ROM. One day I may actually implement ROM bank switching and update the FAT16 handling to support directories.

Cheers, Dolo