microSD support in MOD5441X and NANO54415

[ellisonsoftware]

Are microSDHC class 10 cards compatible with the microSD slot on the MOD5441X and NANO54415?

[ellisonsoftware]

I was able to answer most of this question from the NetBurner MOD54415 web page. Under the Specifications tab:

Flash Card Support

FAT32 support for SD Cards up to 8GB (requires exclusive use of SPI signals). Card types include SD/MMC (up to 2GB) and SDHC.

Thus, it appears I can use a microSDHC card up to 8GB with FAT32.

The supported transfer speed, e.g class 10 is minimum of 10MBS, is still an open question.

Additionally, is there an available file system alternative to FAT32 providing support beyond 8GB?

[ellisonsoftware]

Hmmm... there is information in the EFFS-ProgramsGuide regarding maximum card size that contradicts the information on the MOD54415 web page:

2.1.4 SD/MMC Card Compatibility

The SD/MMC must support native SPI mode transfers, which is common for most SD/MMC cards. Up to 2GB is supported for standard SD/MMC and up to 32GB is supported for SDHC.

I wonder, which is correct for the MOD54415?

[dciliske]

I can confirm that the filesystem will handle 16 GB cards; I haven't tried a 32 GB card because I simply don't have one. That said, I have not tried to use said card with > 8GB of data on it...

As for the speed class, that simply defines the minimum "maximum transfer speed"; so, yes, class 10 cards would be usable.

-Dan

[ellisonsoftware]

Dan,

All microSD and microSDHC cards have the same physical format, regardless of storage capacity.

You have touched upon the critical aspect- what will happen when you try to store more than 8GB of data on your 16GB microSDHC card. If the EFFS manual is to be believed, you will be able to store more than 8GB. If the MOD54415 web page specifications are accurate, then you will not be able to store more than 8GB.

Either way, there is a specification/documentation discrepancy that can be corrected.

I just ordered some 8GB microSDHC cards as this appears to be the greatest common denominator

[dciliske]

I agree that there is a descrepancy, but if memory serves me, this is due to the EFFS documentation itself having the same discrepancy. While I have dived some in the filesystem, I don't have nearly a deep enough knowledge of the source to empirically evaluate the issue.

[d9_]

I just got SanDisk Ultra microSDHC 32GB Class 10/UHS1 and it seems to work fine with MOD54415 rev 1.5 I have.
Do we have any kind of reference/standard test program to check r/w performance and/or anything else?

[pbreed]

Presently the 54415 micro SD card is running in SPI mode... (to be identical to all our other SD card drivers)

Freescale wired the SD card driver and SPI driver to the same pins, alas they did it in a way that the
hardware is incompatible... (IE a pin has to be physically moved switching from SD to SPI etc...)
So it is unlikely that the class of card will have ANY effect on the R/W speed as presently set up...

We are working to correct this alas we have nothing to share or report yet ans since the SPI works its not a real high priority ...

Paul

[Ridgeglider]

Quite a while ago I believe Larry Gitlitz posted an SD card speed test that allowed you to vary the size of data written to the card. I seem to recollect that it was far more efficient to write a single large chunk of data, say >8Kb rather than lots of small ~80 character strings. I'll see if I can track that code down next week. If I succeed, I'll repost it. Also, in my experience performance degrades markedly when the number of files in a directory gets large. This seems to be because the directory gets searched either when creating a new file or when opening an existing file. If there are lots of files, this search just takes longer. Also, if you are data logging, I find that it naturally improves throughput to keep files open while logging as the repeat acts of f_open()/f_close() require significant overhead. The downside of keeping files open is that data that you think is recorded may in fact not be written. You can use f_flush() to force the writes a little faster than using f_close() followed by f_open(). When I leave files open this way, I usually add two chinks of code. The first is some sort of PIT time triggered flush operation. The second is code to force a write by flushing and file close prior to any shutdown or AutoUpdate:

Code: Select all

update_shutdown_func = MyFileCloseFunction;

Finally, the EFFS example code includes quite a few printfs() that I often comment to speed things up.

[joshuaberry]

Hi,
Thought I'd add to this post seeing as though it isn't too old.

I have been using a SanDisk Ultra microSDHC 32GB Class 10/UHS1 (same as d9_) and it has been working fine (writing and reading), however when using f_getfreespace() I am getting strange results.
When there is less than around 4GB of data on the card the 'used' space is correct. However when I add more data to it the values become more 'strange', with the 'total' space always the same. For example, with about 7.3GB of data on the card this function is returning:
1812.463 GB total space, 3104.940 GB free space, 3002.490 GB used space

I have a 4 GB card in another module (also MOD54415) and it returns numbers that are correct. Does this look familiar to anyone?