3
\$\begingroup\$

I'm writing an SDMMC driver for my C++ RTOS for microcontrollers 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.

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'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 (;

\$\endgroup\$
4
  • \$\begingroup\$ In all likelihood the driver code simply wasn't written to be able to support more than one concurrent instance. As you've observed there's apparently no hardware technical reason. \$\endgroup\$
    – brhans
    Commented Feb 8, 2019 at 12:39
  • 1
    \$\begingroup\$ @brhans - the problem here is that the Reference Manual for STM32F7 I mentioned is for the hardware part only, it has nothing to do with the software part (which is entirely on the developers side). \$\endgroup\$ Commented Feb 8, 2019 at 13:03
  • \$\begingroup\$ I missed the part where you're writing the drivers yourself ... in that case, no idea. \$\endgroup\$
    – brhans
    Commented Feb 8, 2019 at 13:27
  • \$\begingroup\$ If it is just for you to decide the class hierarchy, I would simply go for the most flexible solution. You might later want to port your system on other kind of microcontrollers which don't have this limitation. \$\endgroup\$
    – dim
    Commented Feb 8, 2019 at 20:23

1 Answer 1

1
\$\begingroup\$

My humble 50ct (since I just investigate a problem with SD card's CMD signal): SD cards do not have an open-drain mode, so the specification states that (at least) CMD lines for multiple cards need to be separated. Thus, it might be possible to drive several cards when you provide the CMD signal multiplexer logic externally, that you need to control on every card switch.

I don't know whether IO lines can be connected together. Maybe.

The bus setup is basically done in the MCI driver during Initialization(), followed by several calls to Control() (triggered by the file system's fmount() call). That is where bus speed, operating mode etc. are set in the processor registers. So I guess that when you want to access several cards, you'd need to mount/unmount the respective card between the switches to have the registers set correctly.

Just a few thoughts...

\$\endgroup\$
1
  • \$\begingroup\$ Although it is hard to find the latest full specification, you can search for a leaked secure digital card product manual such as this which contains an old version of the full specification. In it you can find the omitted sections 3.2 "SD Bus Topology" and 3.4.3 "Bus Signal Line Load". The diagram in 3.2 shows separate CMD and DAT lines, but it is also possible to use a single DAT bus in SD mode (not UHS or PCIE) as long as the signal integrity problems are sorted out. \$\endgroup\$
    – jy3u4ocy
    Commented Aug 22, 2022 at 2:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.