How do you *emulate an SD card using bit banging*?

I.e. you have an ARM chip plugged in as SD card to a host machine, and that host machine (e.g. Windows whatever) will see a block device/disk however that disk's contents is delivered by the ARM chip software, and it would source the content from anywhere, e.g. from its own memory or even an SD card that it itself has.


I addressed this briefly in the viewtopic.php?f=2&t=2693&p=47799#p47799 post but maybe best move the topic here.

In broad terms, I think you'd need to be programming in bare metal, which you can do on the Pi and would do anyway on a simpler ARM board. I think you'd need to act as an SPI slave, which is annoying because you won't get any hardware help. I suspect you'd have to react as fast as the host sends queries, which would mean no time to forward the inputs to a connected SD Card. Unless you forward by bit-banging to the connected card too!

The starting point then is to choose your ARM platform and find some bare metal tutorial. See if you can act as a dumb SPI peripheral first, perhaps: return a constant value, or a counter value. You'll almost certainly need to figure out how to drive your host as a general SPI master before moving up to using it to connect your emulated SD Card.

You might find some useful hints in the PiTubeDirect project, which acts as a bit-banged 8-bit peripheral on a 2MHz host bus.
https://github.com/hoglet67/PiTubeDirect

I see some info about SD Card interfacing here:
http://elm-chan.org/docs/mmc/mmc_e.html

All that said, I'll defer to anyone who's actually tried to do some of this!

Oh, and welcome to the forum!

It turns out there could be a snag: SD Cards are supposed to support two protocols, and it's the host which chooses the protocol. It's also the host which runs the clock. So if the host chooses the more difficult protocol, or runs the clock rather fast, your task becomes much harder.

There are a couple of pointers here
http://electronics.stackexchange.com/qu ... -emulation

(Actually might not be so bad, if the host interrogates the card to see what it can do, you just need to tell it not to do anything too complicated or rapid.)

The challenge -- and Ed touched on this -- is responding with sufficient speed. The SD card is a slave, expected to respond almost instantly every time the master issues a clock pulse. Although the ARM may be capable of achieving this, it might not be easy. Remember there's no RDY line the ARM can pull low, requesting that the host allow extra time. Therefore every timing deadline must be met -- 99.9% isn't good enough.

(Having said that, it's possible some hosts are less demanding than others, timing-wise. But specifications might be hard to come by. And anyway you might not be satisfied with a solution that only works with certain hosts.)

One option to consider is using an actual SD card, attached (with a multiplexer) to create a two-port configuration. This would allow the ARM and the host computer to take turns accessing the SD card. I'd use something like a 74CBT3257, a multiplexer implemented using FET switches (which are bidirectional).

On the plus side, the dual-port idea resolves timing issues, since the timing is that of an actual SD card. On the down side, it's impossible for both computers to access the SD card simultaneously, so you need a clear idea of who gets access when. Simple cases might be easily manageable. An example of simple is when the ARM loads the SD card first, then there's a one-time changeover to allow the host to have access.

cheers -- and welcome!
Jeff

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

I expect this could turn out to be quite an adventure. There are SD Card specs downloadable at
https://www.sdcard.org/downloads/pls/
and I think we need Part 1 and Part A2. To look like a modern card, it looks like you have to operate at least with a 25MHz clock from the host - that's almost certainly too fast for software bit-banging. But there are indications that you could arrange to look like a very old card, which must be able to accept only up to 400kHz clock. It seems that the initialisation sequence is always run at 400kHz, and the card supplies the information for the speed of the full speed clock.

Possibly useful search terms:
Clock Control Register
SDCLK Frequency Select
Base Clock Frequency For SD Clock
Clock Frequency identification Mode FOD
CSD Register
TRAN_SPEED