Author Topic: Does anyone actually still use MMC cards? How about "very small" SD cards?  (Read 4236 times)

0 Members and 1 Guest are viewing this topic.

Offline Freddie ChopinTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: pl
I'm writing a driver for SD/MMC cards (in SDMMC mode, not SPI mode) for my C++ RTOS and this code works fine for SD v2.0 cards. I'm at the stage of writing unit tests and it turned out to be quite complex, mainly for two reasons:
- at my desk I have no MMC cards and no "old" SD v1.0 cards, so I actually don't know whether this code works for such cards at all,
- all the complexities required for supporting 3 different types of cards with one source file make the code really convoluted.

So it took a small step back and started rethinking basic assumptions. This in turn made me question whether there is actually any point in trying to support MMC cards and "old" SD v1.0 cards. According to my research and experience MMC cards are actually "dead" for like 10 years at least. If you want, you can buy a 512 MB MMC card (used or "new") for sth like ~10 €. If you try really REALLY hard maybe you'll find a 1 GB MMC card. At the same time for half this price you can buy a new 32 GB SD card almost anywhere. Then there are "old" SD v1.0 cards. If I read the specs right, the SD v2.0 standard was published 13 years ago, which is like "forever" for software and at least "very long time ago" for embedded electronics. As for the prices, a 32 MB SD card (used or "new") costs more or less the same as a 32 GB new one.

But anything I come up with will still be just my personal opinion, so I decided to ask - whether anyone actually still uses MMC or "old" SD v1.0 cards for anything or can I safely assume that these are extinct and belong only in the museums? (; My RTOS is very unlikely to be used in an old/existing project (you rarely change such a core component, especially in a mature project) and for a new project this seems natural to also use a "new" type of memory card anyway...

Thanks for any opinions!
 

Online Kleinstein

  • Super Contributor
  • ***
  • Posts: 14073
  • Country: de
I would consider the old MMC cards obsolete and essentially extinct in the wild. So I see no real need to support this old format anymore. Only something like a dedicated card reader may still want to support the old format - just to recover old data, though those cards are not really good for long time storage.

Old SD V1.0 may be rare, but here it may be difficult to see the difference. So there is a small chance they may be used by accident. So there should be at least a kind of warning, error detection.
 

Offline magic

  • Super Contributor
  • ***
  • Posts: 6733
  • Country: pl
I have some old SDs for those devices that don't take SDHC and even my 16MB MMC found use as a bootdisk for one ARM machine.

I wouldn't stick any of them into a modern device for real data storage, but if it only needs the card to store a kernel image or otherwise no more than a few (hundred) megs, I would rather pull one of my old cards than go buy another SDHC.

If you need cards for testing, 2GB are still being sold for pre-SDHC devices and surely cheaper than 10€ if you don't mind onehunglow brands. Used cards ought to be available for peanuts on certain auction site.
 

Offline Freddie ChopinTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: pl
If you need cards for testing, 2GB are still being sold for pre-SDHC devices and surely cheaper than 10€ if you don't mind onehunglow brands. Used cards ought to be available for peanuts on certain auction site.
I have two 2 GB cards and both of them are SD v2.0 (;

The SD v2.0 specification was published in 2006, so to get a SD v1.0 you have to get something older and definitely smaller than 2 GB.
 

Offline amyk

  • Super Contributor
  • ***
  • Posts: 8240
eMMC is still available and uses the same basic protocol in a different package.
I have not read the specs in a while but I remember the versions being backwards-compatible.
 

Offline magic

  • Super Contributor
  • ***
  • Posts: 6733
  • Country: pl
What's the difference between "standard capacity" 2.0/3.0 and 1.x? I thought there is only the CSD version field and it is 0 for SC cards regardless of what spec they are made to and something else for HC/XC.

And by the way, there are cards up to 4GB which work with pre-2006 devices. I could swear they ought to use the version 0 CSD from 1.x spec because otherwise those devices wouldn't parse them, but I have one such card and its CSD reported by Linux shows version 1 and the HC/XC layout. Maybe Linux lies or I did something wrong :wtf:
 

Offline Freddie ChopinTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: pl
eMMC is still available and uses the same basic protocol in a different package.
I have not read the specs in a while but I remember the versions being backwards-compatible.
But eMMC is something completely different and I imagine that a separate driver for eMMC is much better than trying to pretend that a removable microSD card in a socket is the same thing as an eMMC chip soldered to the PCB (;

What's the difference between "standard capacity" 2.0/3.0 and 1.x? I thought there is only the CSD version field and it is 0 for SC cards regardless of what spec they are made to and something else for HC/XC.
The difference between v1.0 and v2.0 is mostly in the supported commands, which affects initialization procedure. For example v1.0 does not have CMD8 and for v2.0 it is mandatory to issue this command between CMD0 and ACMD41. What is in the CSD_STRUCTURE bitfield is something completely different - in fact the 2 GB cards which I have (v2.0) both have CSD_STRUCTURE equal to 0. SD specification is a real mess...
« Last Edit: March 16, 2019, 07:21:37 pm by Freddie Chopin »
 

Online mariush

  • Super Contributor
  • ***
  • Posts: 4983
  • Country: ro
  • .
Well, I still have the 32 MB SD card that came in the package with my Canon Powershot A580 : https://www.amazon.com/Canon-SDC-32M-Digital-Powershot-Cameras/dp/B008IA1R56

Not sure if it's SD 1.0 or 2.0, don't know how to determine that.
But, if you can't source your own SD 1.0 cards and this one is SD 1.0, I'm willing to mail it to you.

I bought the camera around 2009 so I suspect it may be SD 2.0
 

Offline Synthtech

  • Regular Contributor
  • *
  • Posts: 222
  • Country: au
Lots of synthesizers and high end music workstations are still in use that use used MMC, CF and SD cards. And these machines often only work with the early smaller capacity cards. Much like the way that some equipment (Rigol scopes) needs old, small capacity USB thumb drives of they just won’t recognise the media.
« Last Edit: March 16, 2019, 07:47:56 pm by Synthtech »
 

Offline Freddie ChopinTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: pl
But, if you can't source your own SD 1.0 cards and this one is SD 1.0, I'm willing to mail it to you.
Thanks for the offer - I'll keep it in mind if such need arises!

Lots of synthesizers and high end music workstations are still in use that use use MMC, CF and SD cards.
Maybe the question was not entirely clear, so I'll try to refine it a bit. I'm sure there are devices which are still manufactured which use MMC cards or very VERY small SD cards, but I'm rather wondering whether anyone would choose such a card when starting a new project from scratch.
 

Online mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13695
  • Country: gb
    • Mike's Electric Stuff
I've noticed that newer cards can be a lot slower in SPI mode, both for read and especially write, like a factor of 5-8x worse. I suspect the latter may be a block-size issue, the cards having a larger actual block than 512 bytes and using some form of inefficient emulation.
It can be quite hard to find old "real" 256/512M cards  - I suspect a lot of what's out there are bigger cards that have been re-configured to look like the smaller old ones.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline magic

  • Super Contributor
  • ***
  • Posts: 6733
  • Country: pl
The difference between v1.0 and v2.0 is mostly in the supported commands, which affects initialization procedure. For example v1.0 does not have CMD8 and for v2.0 it is mandatory to issue this command between CMD0 and ACMD41. What is in the CSD_STRUCTURE bitfield is something completely different - in fact the 2 GB cards which I have (v2.0) both have CSD_STRUCTURE equal to 0. SD specification is a real mess...
Makes sense, I wasn't aware the differences already start at early init.
I guess it now explains why my 4GB SDSC presents itself as SDHC to Linux - it detects a 2.0 host probing it and goes SDHC for compatibility with the 2.0 spec, which forbids 4GB SDSC cards. Smart little card.

BTW, if CMD8 is the only difference I wouldn't worry too much about compatibility. It seems you are supposed to notice that the card responds "invalid command" to CMD8 and simply proceed to issue ACMD41 without the "high capacity" bit set. I'm not even sure if SDSC v2 cards like those you have even bother responding to CMD8 at all? Certainly CMD8 isn't required for their operation, because they work on v1 hosts.
 

Offline Freddie ChopinTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: pl
No, trust me, CMD8 is just the first difference you notice. v2.0 cards can work with 50 MHz clock (also in SPI mode!), but to use it, you have to first switch the card to "high speed" mode with CMD6, which is supported only in v1.1 cards, but v1.1 spec was released just a few months before v2.0, so I guess there finding such card would be even harder than v1.0 (;

BTW - v2.0 cards obviously respond to CMD8 - there is no rule that SC cards are v1.0 and HC cards are v2.0. There are SC cards which are also v2.0 and these would be all the cards you can actually buy in the shops (; In the SD spec there is a description of "SD_SPEC, SD_SPEC3, SD_SPEC4, SD_SPECX" fields and this chapter explains some of the differences between the versions. To find more you have to browse through the whole document, but the other major thing missing in v1.0 is the support for 50 MHz clock.
 

Offline magic

  • Super Contributor
  • ***
  • Posts: 6733
  • Country: pl
I guess it all depends on who your users are.

If it's some toy OS for hobbyists I guess it's no big deal to tell them to buy a card made in this decade or eff off.
If it's for a commercial product, it may be worth doing it right. A few customers will inevitably stick old cards in it and complain.
Even if current production 2GB cards are v2 it doesn't mean there are no 2GB cards made before 2006 waiting to bite you. It only makes it harder to source specimens for compatibility tests ;)

There is the option to leave the code as is, implementing v1 support only theoretically per the spec, and wait for bug reports to come in >:D

And whatever you do, please do not take the Panasonic route and display "insert card again"  when you don't like the filesystem it's formatted with :rant:
 

Offline Nerull

  • Frequent Contributor
  • **
  • Posts: 694
But eMMC is something completely different and I imagine that a separate driver for eMMC is much better than trying to pretend that a removable microSD card in a socket is the same thing as an eMMC chip soldered to the PCB (;

The trick for dumping the NAND flash of a Nintendo 3DS is to solder wires from a SD adapter onto the eMMC chip and then plug it into an SD reader.
 

Offline Peabody

  • Super Contributor
  • ***
  • Posts: 1965
  • Country: us
I'm working on an SD card bootloader for MSP430 processors.  I think Dave uses a similar firmware update system for his new meter.  Anyway, the smallest card I can find on Ebay is 128MB SD for about $1 each.  I've ordered a couple to test.

For bootloader purposes, I'm assuming the card would be provided along with the device, so the developer would be sure in advance it would work with the bootloader.  I'm trying to limit the bootloader to 1K, and may need to limit it to standard SD cards, not SDHC.  That would support SD up to 2GB, which I think are still widely available at low cost online.  Of course we're talking about firmware files of 16K or so, so any card is going to be way too big.  And for this purpose speed isn't an issue.  The risk is that SD may at some point no longer be manufactured.  Then I would need to make the bootloader larger, or re-write it for SDHC only.

I would say if MMC cards aren't avilable for purchase anymore, it would make sense not to support them.  I haven't seen one in some time, and I assume they haven't been manufactured in the last couple decades.
 

Offline bleckers

  • Contributor
  • Posts: 35
  • Country: au
If I was using this, it would definitely be for a new design, rather than trying to make it work with an older embedded system, which means I'm also buying whatever cards are available today. I'd say take the approach of, what is the earliest microcontroller you are looking to officially support, then support peripherals and standards akin to that device.

This is not to say someone can't implement and test the required functionality themselves on an unsupported platform. Reading through the docs you state "Distortos aims to have all good features and none of the broken ones". If you keep this sort of mantra, you can focus on solid standards based design (which you are going to want with an RTOS) with a tick off device compatibility chart (tick, it supports SD 2.0, not ticked SD 1.0).

Focus on solid tested drivers and let the community implement any extended functionality (and/or have a separate extended/development/untested branch).

If you want to still support MMC, I'd keep the 2.0 driver as is, then maybe have a separate untested 1.0 driver that users could configure in and test to use instead.

Something to think about however is that some people might want to use the cards in SPI/1bit mode (peripheral/pin constraints), so a separate driver could be developed to support this too.
« Last Edit: May 08, 2019, 02:21:21 am by bleckers »
 

Offline Freddie ChopinTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: pl
Thanks for all your ideas and opinions. In the end I did what most people suggested here - I just dropped support for MMC (which was incomplete anyway) and for SD version 1.0 (which was untested) and left only SD version 2.0 support.

Something to think about however is that some people might want to use the cards in SPI/1bit mode (peripheral/pin constraints), so a separate driver could be developed to support this too.
Exactly what I did (; There is one separate driver for SD card which uses SDMMC interface (configurable 1/4 bit mode) and another separate driver which uses SPI interface. While the former one (SDMMC) works like a charm, the latter (SPI) sometimes doesn't work (the card is not detected) - it seems that SPI mode for SD cards is a bit tricky...

http://distortos.org/api-reference/classdistortos_1_1devices_1_1_sd_card.html
https://github.com/DISTORTEC/distortos/blob/master/include/distortos/devices/memory/SdCard.hpp
https://github.com/DISTORTEC/distortos/blob/master/source/devices/memory/SdCard.cpp

http://distortos.org/api-reference/classdistortos_1_1devices_1_1_sd_card_spi_based.html
https://github.com/DISTORTEC/distortos/blob/master/include/distortos/devices/memory/SdCardSpiBased.hpp
https://github.com/DISTORTEC/distortos/blob/master/source/devices/memory/SdCardSpiBased.cpp
 

Offline Peabody

  • Super Contributor
  • ***
  • Posts: 1965
  • Country: us
There is one separate driver for SD card which uses SDMMC interface (configurable 1/4 bit mode) and another separate driver which uses SPI interface. While the former one (SDMMC) works like a charm, the latter (SPI) sometimes doesn't work (the card is not detected) - it seems that SPI mode for SD cards is a bit tricky...


When working on my bootloader, I ran across some good information in a forum post that solved my problem with non-responding cards using SPI:

 > After the last SD Memory Card bus transaction, the host is
 > required to provide 8 (eight) clock cycles for the card to
 > complete the operation before shutting down the clock.

 > It could work without it, but since 8 cycles = 1 SPI output
 > byte, it won't hurt much and it's just good to have it.

It appears that some cards just require more clocks to respond to commands properly, and I actually ran across one of them.  It worked fine in my computer, but not in my bootloader.

I had already adopted the idea of briefly toggling the CS line high, then back low, at the beginning of each command since I read that some cards need that (instead of just tying CS low all the time).  So I added transmitting one byte of 0xFF just before toggling the CS line, and the flaky card then worked properly.  So instead of sending an extra byte at the end of each command, I send it just before the beginning of the next command, and that works so far.

I'll attach the flow chart I followed for SD v1 and v2 and for SDHC.  I didn't support MMC or SDXC.
 
The following users thanked this post: oPossum

Offline Freddie ChopinTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: pl
> After the last SD Memory Card bus transaction, the host is
 > required to provide 8 (eight) clock cycles for the card to
 > complete the operation before shutting down the clock.
I've also seen this somewhere and I actually use this too.

Quote
It appears that some cards just require more clocks to respond to commands properly, and I actually ran across one of them.  It worked fine in my computer, but not in my bootloader.
You mean that you had to increase the number of clocks between command and response from the typical 8 bytes (64 clocks)? What value did you use?

Quote
I had already adopted the idea of briefly toggling the CS line high, then back low, at the beginning of each command since I read that some cards need that (instead of just tying CS low all the time).
Yeah, I do it too.

The main problem in nailing down the issue is that it usually happens during initialization and also it happens pretty rarely (like 1 in 10 times or even less). Usually removing the card and inserting it again fixes the issue instantly, so there's also a possibility that some signal integrity issues are the problem here. This is even more likely because I retry the initialization 100 times before giving up... Maybe I'll try sending an empty byte also before each command (;
 

Offline Peabody

  • Super Contributor
  • ***
  • Posts: 1965
  • Country: us

You mean that you had to increase the number of clocks between command and response from the typical 8 bytes (64 clocks)? What value did you use?

No. I send the six bytes of the command (1 command, 4 argument, 1 CRC), then I continue to send up to 10 FFs until I get a response that isn't FF.   So I don't actually know how many it takes to get a non-FF response.  It could be the first byte after the command, or the 10th.

But then immediately before I toggle the CS line for the next command, I send one FF byte.  That's what made the goofy card work.  Apparently it needed those 8 clocks to complete whatever it was doing and prepare for the next command.  If I didn't do that, I would get a response to CMD0, but nothing after that.

Quote

The main problem in nailing down the issue is that it usually happens during initialization and also it happens pretty rarely (like 1 in 10 times or even less). Usually removing the card and inserting it again fixes the issue instantly, so there's also a possibility that some signal integrity issues are the problem here. This is even more likely because I retry the initialization 100 times before giving up... Maybe I'll try sending an empty byte also before each command (;

The problem I had wasn't intermittent at all.  The card never worked at all until I started sending that extra byte.  It needed the extra byte AFTER it had responded to the command, but before the next command.  So your issue may be something different.

My code is in MSP430 assembler, so not likely to be of much use to you, but you're welcome to take a look.   I used no libraries, so absolutely everything is in the source file.  It's pretty well commented.

I should say, though, that like you, I didn't have an SD v1 to test, and still don't, so I don't know if my code actually works with v1 cards.  But it does work with SD v2 and SDHC.
 
https://github.com/gbhug5a/SD-Card-Bootloader-for-MSP430
« Last Edit: May 08, 2019, 06:15:45 pm by Peabody »
 

Offline Freddie ChopinTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: pl
No. I send the six bytes of the command (1 command, 4 argument, 1 CRC), then I continue to send up to 10 FFs until I get a response that isn't FF.   So I don't actually know how many it takes to get a non-FF response.  It could be the first byte after the command, or the 10th.
So you actually extended that a bit, as the spec says the card must respond after no more than 8 bytes (9 bytes in case of some special commands which need a "stuff byte") (;

Quote
My code is in MSP430 assembler, so not likely to be of much use to you, but you're welcome to take a look.   I used no libraries, so absolutely everything is in the source file.  It's pretty well commented.
Thanks, I'll have a look (; Last time I used MSP430 assembly was a long time ago (;
 

Offline Peabody

  • Super Contributor
  • ***
  • Posts: 1965
  • Country: us

Thanks, I'll have a look (; Last time I used MSP430 assembly was a long time ago (;


The last time I played any of your piano works was a long time ago.  :-)  But I bet they would come back to me.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf