Maximum Capacity for microSD Card used with Arduino+SD module: 2GB or 32GB?

Using Arduino Storage
1

Hi all

Many times, when I see a microSD card module for Arduino,
the product page says "Max. card size is 2GB".
Once I also saw 4GB being mentioned.

But when searching with google for the words arduino microsd size limit,
I saw in several places 32GB being mentioned, and not 2GB.. and also not 4..

So why do the modules specify that value?
Are they incorrect?

I should mention that most microSD odules don't contain any IC on them,
they just seem to be a breakout module for the microSD card metal slot, which has SMD legs.
So thuis means that the module should not have any effect of the card Type/Capacity,
and it is all affected by the MCU, and by the Library being used.

Please help me solve this,
since the 2GB limit is problematic,
not because I need to store larger amounts of data,
but because 2GB cards (or less) are rare, and hard to find,
and even if you find them, they will be expensive because of their rarity...

Thank you

2

I can't think of a reason why the module would have anything to do with maximum size. That would be a library limitation. However, SD cards are 3.3V devices. So if you are using them with a 5V Arduino, you would need to use a microSD module that has the level-shifter I/C on it and a 3.3V voltage regulator. Even so, that has nothing to do with maximum card size.

3

So all these modules' specifications are mostlikely wrong?

4

card5:
So why do the modules specify that value?
Are they incorrect?

Most likely because those modules aren't more than just physical and electrical adapters, there's no "brain" on those. So the controller unit is the limit.

This limit actually comes from software (library) support and SPI support on the card. For example: the SD library is compatible up to SDHC, thus up to 32 GB cards.
Although I'm not sure if SdFat handles SDXC (up to 2 TB), or even if XC cards support SPI at all.

5

I see, thank you very much.

OK, then I can safely buy upto 32GB cards.
It's better, because the 16GB/32GB sizes are cheaper today than the old sizes of 2GB and less.

6

I don't think you'll have a problem. I've tested an 8GB SDHC card with some of the SD example sketches, and it works fine.

1 Like
7

Great.

BTW, I read in this forum, in an old post, that SD/microSD cards have a 16KB block size.
Does this mean that If I write 1 Byte to the card, a whole 16KB block needs to be written be cause of that?

8

SD cards have a sector size of 512 or 1024 bytes, or perhaps more for XD and such, and this is defined by the card manufacturer. 16K would be the cluster size (typically 32 sectors), which is the smallest amount by which the space occupied by a file can be increased. That's a FAT thing. So if you create a new file, it will occupy at least one cluster. But if you are appending data to an existing file, it will fill up the current cluster before allocating another one. Sectors within a cluster are always consecutive. The clusters making up a file need not be consecutive. The File Allocation Table (FAT) is used to map the clusters in a file.

1 Like
9

Thank you for that Info.

I am aware to the sectors and clusters subjects,
but what about writing 1 byte?
Does it mean a whole block (whicever size it is) will have to be rewritten just because of it?

10

card5:
but what about writing 1 byte?
Does it mean a whole block (whicever size it is) will have to be rewritten just because of it?

Yes, but just a physical sector, not a whole filesystem-defined cluster (unless it's also set as 512 bytes). It's also because how NAND flash memories write data (page erase-program cycle).

11

Wow, this means writing byte after byte will be both slow, and also wear out the card.

Is there maybe some article about how to optimally write to a card using Arduino and a microSD card module?

12

card5:
Is there maybe some article about how to optimally write to a card using Arduino and a microSD card module?

Both SD and SdFat already do that, and in fact is the reason why they take a good chunk of RAM. By it's function is called a "disk cache" (often wrongly called a buffer), an space in RAM used to record pending changes to a disk sector, in order to waste less time and minimize wear by saving ("flushing") big changes at once instead of small consecutive ones.

So, writting a single byte should not update immediately the physical medium, unless:

  • The library has to work with another sector (every 512 bytes).
  • flush() is called afterwards.
  • The file is closed afterwards.

One downside of this is when those changes reside only in cache and for whatever reason the system powers-off or resets; the new data will be essentially lost.
Thus, with any mass-storage medium there's always that trade-off between reliability and performance.

13

Lucario448:
Both SD and SdFat already do that, and in fact is the reason why they take a good chunk of RAM.

Good to know this,
thank you very much Lucario448 for such useful information - spares me the need to write it.

Lucario448:
So, writting a single byte should not update immediately the physical medium, unless:

  • The library has to work with another sector (every 512 bytes).
  • flush() is called afterwards.
  • The file is closed afterwards.

The first one is interesting..
That's for example when the program writes in one location, and then wants to read or write from another location..
Tho for logging, this is rarely a problem.
I wonder If people who use Arduino ever stumble upon case #1
(or did you simply mean in #1 the case inwhich the buffer got full, and needs to be emptied?)

Lucario448:
One downside of this is when those changes reside only in cache and for whatever reason the system powers-off or resets; the new data will be essentially lost.

For this reason, a wize use of .flush() is needed,
for example, after a big write() of data, and before a big delay of not writing data..
Or, before performing an operation that is "risky", in terms of potentially causing any problem that might cause a reset/power-off/etc

14

card5:
I wonder If people who use Arduino ever stumble upon case #1
(or did you simply mean in #1 the case inwhich the buffer got full, and needs to be emptied?)

Yes, and they don't even have to realize that since it happens automatically when needed.
This situation most likely occurs when logging at a relatively high rate (like above 10 Hz), or downloading a bulk of data from an external source.

card5:
For this reason, a wize use of .flush() is needed,
for example, after a big write() of data, and before a big delay of not writing data..
Or, before performing an operation that is "risky", in terms of potentially causing any problem that might cause a reset/power-off/etc

Of course, because abusing this cause degraded performance and increased wear. So that's why I've said there's a trade-off.

15

I am curious about the Program-Erase cycles:

card5:
but what about writing 1 byte?
Does it mean a whole block (whicever size it is) will have to be rewritten just because of it?

Lucario448:
Yes, but just a physical sector, not a whole filesystem-defined cluster (unless it's also set as 512 bytes).
It's also because how NAND flash memories write data (page erase-program cycle).

Regarding these NAND Blocks/Pages,
is the size of them always 512Bytes, in all microSD cards no matter the card's capacity?
(meaning this 512 number is defined by the manufacturer of the microSD card, in hardware)
Or is this number affected by the user somehow, for example when Formatting the card?

(from what I remember from Format programs, you can only choose the Cluster size, not the Sector size..)

16

card5:
I am curious about the Program-Erase cycles

Long story short, NAND flash memories can "drain" individual bits from 1 to 0, but not the other way around. For that, you'll have to re-set all the bits of the page, then clear out the corresponding ones.

In a write cycle, re-setting the whole page (with 1s) is the "erase" stage; this is what takes most of the time and causes wear to a page. The "program" stage is simply clearing out (from 1 to 0) the neccesary bits in order to create the intended data to store.

card5:
is the size of them always 512Bytes, in all microSD cards no matter the card's capacity?
(meaning this 512 number is defined by the manufacturer of the microSD card, in hardware)

Not entirely sure. Either these boundaries are defined by the built-in controller (the chip who actually "talks" with the Arduino or any other card reader), or it's the actual (physical) page size of the memory itself.

In SDSC (cards up to 2 GB), it's actually possible to change the block size to a smaller one (although it's done virtually by the card's controller), and write a single byte like an EEPROM.
However, in SDHC (4-32 GB) and beyond, this is not possible anymore, and the block size is always fixed to 512 bytes.

card5:
Or is this number affected by the user somehow, for example when Formatting the card?

(from what I remember from Format programs, you can only choose the Cluster size, not the Sector size..)

No, that's something defined by software (high level); the sector size is indeed defined by hardware (low level).

In digital mass-storage devices, a cluster is just a software-defined group of contiguous hardware-defined sectors (hence its name), in order to simplify some the free space and file allocation management. Larger clusters means less filesystem's data structure and processing overhead (which may also translate in support for a bigger volume/partition), but at the same time potentially larger "slack" or "internal fragmentation" (wasted disk space, unusable by the filesystem) in small files.

That's why you can change the cluster size, and not the sector size.

17

Really interesting, thank you very much.

Lucario448:
In SDSC (cards up to 2 GB), it's actually possible to change the block size to a smaller one (although it's done virtually by the card's controller), and write a single byte like an EEPROM.
However, in SDHC (4-32 GB) and beyond, this is not possible anymore, and the block size is always fixed to 512 bytes.

That's nice, too bad this option was omitted.

BTW,
I saw a microSD card module, that claims to be High-Speed.
https://robotdyn.com/catalog/modules/memory/microsd-card-module.html

It seems that it contains a CD4050, for high-speed communication.

From what I understand, the CD4050 is a Buffer IC,
but the term "Buffer" can be quite misleading here, for people who come from the software field.
The IC cannot and doesn't store anything, it is just used for Level Conversion, from what I understand.

So when they say that using the CD4050 makes the module high-speed,
do they say it versus using Transistors for Level Conversion, like we see in other modules (that support 5v and don't have the CD4050)?
The Transistors are slower than the CD4050?

If indeed the CD4050 is faster than Transistors, I wonder if this extra speed is relevant to the speeds that we can get when using Arduino and a microSD card, which from what I understood are around 200KBps for writing, and 300KBps for reading..

Here is for example one with the SMD Transistors, that I bought several years ago:
https://www.itead.cc/prototyping/basic-module/sd-micro-sd-card-breakout-module.html

18

card5:
The IC cannot and doesn't store anything, it is just used for Level Conversion, from what I understand.

So when they say that using the CD4050 makes the module high-speed,
do they say it versus using Transistors for Level Conversion, like we see in other modules (that support 5v and don't have the CD4050)?
The Transistors are slower than the CD4050?

Maybe they are implying that? Who knows

Furthermore, every transistor has a minimum on/off time plus any stray capacitance; those factors do limit the working speed. For example: the typical ATmega328 runnning at 16 MHz can operate its SPI master controller up to 8 MHz (always half the system's frequency, also called "full speed" by the SPI library); thus any transistor used for level conversion must have an on/off time of at most 125 ns.

Slow transistors and high stray capacitances can cause from ocasional jitter (uneven pulse periods) to missing pulses (so out-of-sync communications and thus corrupted data), of course unless the working frequency is low enough.

card5:
If indeed the CD4050 is faster than Transistors, I wonder if this extra speed is relevant to the speeds that we can get when using Arduino and a microSD card, which from what I understood are around 200KBps for writing, and 300KBps for reading..

That's an average data rate, but the SPI lines will still be pulsing at 8 MHz for instance. It's not continuous because of all the processing involved between transfers.
Anyway, if you somehow manage to do it (e.g. via DMA), you wouldn't get the theoretical maximum (8 MHz = 8 Mbit/s = 1 MB/s) but close to. If processing isn't the delay, then the communitaction protocol (command, parameters, CRC if kept required, and response) and the card's controller busy state (for instance, applied when executing an erase-program cycle during a write operation) will be.

19

I see.

I think I will also buy the module with the CD4050,
for experimenting and comparing the max. speed it can give vs. the other microSD modules I have.

(when something costs 1$, it's hard to resist)

20

But isn't the CD4050 there as a level shifter - from 5V to 3.3V, not really as a buffer? I think most modules use the 74LVC125A, but the function is the same.