STM32 SDMMC & SDIO - why max 1 SD card only?

[Freddie Chopin]

I'm writing an SDMMC driver for my C++ RTOS for microcontrollers - http://distortos.org/ - and there is one thing which really puzzles me, making it hard to decide about class hierarchy. In the Reference Manual for STM32F7 (but the same is true for other chips, both for SDMMC and SDIO peripherals) you can read the following at the very beginning:

The current version of the SDMMC supports only one SD/SDIO/MMC4.2 card at any one time and a stack of MMC4.1 or previous.

Where does this limitation come from? As far as I understand SD cards (which is hard given the "quality" of the SD documentation) using one card should look exactly the same as using ten - from the point of view of SDMMC peripheral this is just sending commands, receiving responses and transferring data blocks. To use more than 1 card you just need to make sure to "select" the proper one with CMD7 before talking to the selected card and that's it. But this selection process is done completely in software, in the higher layer than SDMMC driver.

I've found some clue in the mentioned SD documentation:

4.3.11 High-Speed Mode (25 MB/sec interface speed)
..
Because it is not possible to control two cards or more in the case that each of them has a different timing mode (Default and High-Speed mode) and in order to satisfy severe timing, the host shall drive only one card. CLK/CMD/DAT signal shall be connected in 1-to-1 between the host and the card.

But this (according to my understanding) affects high-speed mode only, you can stick to default-speed mode, which is (surprisingly (; ) the default mode after card power-up.

The reason why I'm asking this questions is because I cannot decide whether I should model the class hierarchy with assumption that the SDMMC peripheral IS the memory card, or maybe that SDMMC peripheral should be represented by dedicated "SD/MMC host" class, which may be associated later with a memory card object. The second model is much closer to the situation possible while using memory cards in SPI mode, where you can have as many as you like connected to the same SPI bus.

Thanks in advance for any information (;

[capt bullshot]

Can't help with your architectural decision, just my 2 cents:

I've rarely seen the need to use more than one SD card in an embedded system running on a typical uC, so why bother with more than one card?

From the HW side, these high speed modes will be difficult to layout if more than one SD socket is involved. I'd prefer a simple point-to-point layout over a bus structure in HW, so if your RTOS supports one card per controller, I'd be fine.

From the SW side, I'd prefer the most simple model, not the most sophisticated.

[Freddie Chopin]

While I generally agree, I have this deep urge to just know "why" (; But seriously - I'd really love to make decisions based on facts (which I'll hopefully learn) instead of just guesses and assumptions.

However it is true that a setup with more than 1 memory card socket would be hard to use, because you don't have a way to say "communicate with the card in this slot" (as in SPI by using "slave select" line) - from my understanding you would have to detect the cards in the ascending order of their CID and after inserting a new card you have to reset all the other cards and rediscover them again. which would then change RCA number each card has.

[amyk]

From the SW side, I'd prefer the most simple model, not the most sophisticated.

This can't be emphasised enough. There's been enough discussions here of bloated vendor abstraction libraries to read through already.

[Rerouter]

Its likely the common process of manufacturer library code, get it to a state where people can plug and play your product if there application lines up exactly with the spec sheet they gave the programmers on the day, an no further because that costs money.

To write software that can fully realise every function a microcontroller peripheral can do without bloating is hard. so my guess is they focused on 1 card, and stopped there, throw it on a dev board, tried it with a few cards they had lying around and called it done.

[Freddie Chopin]

To write software that can fully realise every function a microcontroller peripheral can do without bloating is hard. so my guess is they focused on 1 card, and stopped there, throw it on a dev board, tried it with a few cards they had lying around and called it done.

But the Reference Manual - from which the quoted limitation comes - is for the hardware only. There's no mention about vendor library code anywhere in the documentation for the hardware. These are two completely separate entities.

Even though the first page of the chapter about SDMMC peripheral says only 1 SD card can be used, this is what you can read further:

39.4.4 Card identification process

...

For the SD card, the identification process starts at clock rate F od , and the SDMMC_CMD line output drives are push-pull drivers instead of open-drain. The registration process is accomplished as follows:
1. The bus is activated.
2. The SDMMC card host broadcasts SD_APP_OP_COND (ACMD41).
3. The cards respond with the contents of their operation condition registers.
4. The incompatible cards are placed in the inactive state.
5. The SDMMC card host broadcasts ALL_SEND_CID (CMD2) to all active cards.
6. The cards send back their unique card identification numbers (CIDs) and enter the Identification state.
7. The SDMMC card host issues SET_RELATIVE_ADDR (CMD3) to an active card with an address. This new address is called the relative card address (RCA); it is shorter than the CID and addresses the card. The assigned card changes to the Standby state. The SDMMC card host can reissue this command to change the RCA. The RCA of the card is the last assigned value.
8. The SDMMC card host repeats steps 5 through 7 with all active cards.

So SDMMC supports only one card, yet they describe how to detect many... I really don't know what to think...

[amyk]

That might just be copy-pasted from either the SD spec or another doc where the peripheral does support multiple cards.

[Freddie Chopin]

That might just be copy-pasted from either the SD spec or another doc where the peripheral does support multiple cards.

This is another interesting thing - I've browsed other STM32 families, and each reference manual says the same thing - 1 peripheral == 1 SD card. This actually brought me to another question, whether this limitation is something STM32-specific, or maybe it's just the same everywhere, because somehow no one supports more than 1 card?

[obiwanjacobi]

The reason why I'm asking this questions is because I cannot decide whether I should model the class hierarchy with assumption that the SDMMC peripheral IS the memory card, or maybe that SDMMC peripheral should be represented by dedicated "SD/MMC host" class, which may be associated later with a memory card object. The second model is much closer to the situation possible while using memory cards in SPI mode, where you can have as many as you like connected to the same SPI bus.

Use templates to flip the hierarchy around by deriving from a template parameter.
Any peripheral can be represented by 3 main layers:

- driver: pin interfacing
- protocol: what do the bits mean/ how to interpret them
- usage: what you do with it

Any of these layers can be split further as the need arises.

Code: [Select]

template <class T>
class Usage : public T
{
// calls T::protocolFns
}

template <class T>
class Protocol : public T
{
// calls T::driverFns
}

class Driver
{
// calls regs etc.
}
Using this in a program would look something like:

Code: [Select]

typedef Usage<Protocol<Driver>> MyUseOfX;
MyUseOfX myX;
myX.usageFn();
+ Every layer can be extended or replaced
+ No virtuals / no overhead
+/- (depends) Memory usage over code size

So the idea is that you don't bake in a class hierarchy but leave that to the user/dev.
Browse my ATL library for examples.

[2c]

[Freddie Chopin]

Interesting approach, but this would mean at least double the work and that a lot of code would have to be in the headers, which I don't really like (;

[capt bullshot]

This is another interesting thing - I've browsed other STM32 families, and each reference manual says the same thing - 1 peripheral == 1 SD card. This actually brought me to another question, whether this limitation is something STM32-specific, or maybe it's just the same everywhere, because somehow no one supports more than 1 card?

That might be true. Most more complex peripherals like USB, Ethernet MAC and SDMMC are IP blocks that get re-used over many chips, and might not have been designed by STM themselves, but bought from some IP supplier. That IP supplier might have sold the same IP to other MCU manufacturers. Often these IP have hard configuration options, so one MCU manufacturer might support more than one SD card, the other one not.