FAT32 implementation using TM4C123GXL

Nazmul Hasan said:

make a data logger with 4GB SDHC (FAT32) card

Few days past I raised the (possible) "SDHC" issue here - w/vendor's Amit.

Appears now that you may assist Amit - and others here, too.  Have you access to the older, simpler SD card?  (w/out the HC performance nomenclature)  If so - kindly try your code (modified to support any change in capacity w/the SD device) and report how - or if - it runs.

Past posters - here & elsewhere - encountered issues w/the newer SDHC cards.  I "flagged" this issue as SDHC has (long now) "won this war" - and only the oldest, smallest capacity SD cards - still fly the (mostly abandoned) SD flag... 

Should SDHC (not) yet be supported - such appears to be a major weakness - and (some) attention should be directed to it's full/proper support...

Thank you cb1. I haven't try with the simpler SD yet.
Of course, i will report when i'm done.

Cheers!

Good for you, Nazmul - that should prove useful to you and others.

More light must shine upon this SDHC vs. SD card issue before vendor will "mobilize" and lead to a solution.

Good luck w/your "plain" SD card attempt - your results will be both of interest & value - thank you...

BTW - if (others) have realized success w/SDHC cards - and this vendor's M4 MCUs - might you detail & report facts here?  Again, thanks...

Hello cb1, Nazmul,

I tried the sd_card example with a SDHC card (8Gb) and it works fine. I am not sure if the FAT32 is there on the card or FAT16 but all data from fat_fs and the card read show a FAT32

Regards
Amit

Amit Ashara said:

I tried the sd_card example with a SDHC card (8Gb) and it works fine.

Hi Amit,

Again - "above/beyond" response by our forum master!   Thank you.

Now I've checked w/several clients - employing your MCUs - and (indeed) some report "issues" when moving from (past) SD cards to newer (and larger) SDHC cards.  And - this "hiccup" is not confined just to your MCUs - other ARM brands have also experienced some difficulty in the upward migration.

Perhaps this points to the type/quality/specification of the individual SDHC card.   May we ask the brand and part no. of the device you've tested?  (on another ARM forum we haunt - some SDHC cards have registered as "difficult" and/or "issue prone."  While simpler SD cards (all) passed.)

Yet another issue lurks - are there not SDHC cards which target different end-uses - and users?   (I'm thinking of camera-storage devices - as one example)  There also may be a variation in access speeds - across types & makers - of (otherwise) very similar SDHC cards.

And - this simple plot may thicken even further - not all SDHC card users demand (nor even want) FAT and/or PC compatibility!   Might it be that transactions to the SDHC cards are complicated/burdened (slowed) by aspects of FAT compliance?  Again - while convenient - not all users demand PC compatibility - especially if such capability erodes data transfer and/or error "rates!..."

We do appreciate your quick response - however a single, reported success may not provide all of the "surety" which your client-users rightly seek...

Hello cb1

What I have is a UNIREX 8GB uSDHC. I checked on my PC and it has a FAT32 File System. So I wrote a few text files to the card. Connected the uSDHC card to the DK-TM4C129 and ran the sd_card application code.

Unfortunately, I do not have SDHC card other than the one I mentioned and the example application does limit it to the FAT File System. In the past I have used a SD Card for music storage and streaming (albeit another uP altogether) without have a File System and instead relying on headers.

Regards
Amit

Hi Amit,

Happy to hear your success with SDHC.  :)

By this time, I tried to read/write the older SD card with TM4C123GXL successfully. It's time to move SDHC.  Did you define the _USE_FAT32 symbol for SDHC? Documentation of FATFS told to use this symbol to work with FAT32 system.

Again, Thank you!

Hello Nazmul

No, I did not define the _USE_FAT32. May be I need to try some other SDHC cards

Regards
Amit

Hello Cb1, Amit,

It's working with my 4 GB SDHC as well as 16(!!!) GB SDHC from Transcend. It's a miracle!!! Problem was in my configuration.

From my research,

1. The Third party FatFs lib support all of the file system (FAT12/FAT16/FAT32), So it should work with the cards that support these file system. (Lib also capable of Handle HDD with ATMega64 'from document').

2. So as far i know the differences between these cards (SD, SDHC) as well as SDXC are the Compatibility, Speed, Capacity etc.

Thanks.

Hello Nazmul,

Thanks for the confirmation for SDHC.

Regards
Amit

Nazmul Hasan said:

It's a miracle!!! Problem was in my configuration.

I think not - friend Nazmul - your focus & systematic test/verify led to your success.  Proud of you - happy for you - good job!

That said - enough of our "Tiva/LX4F based" clients have squawked about SDHC "issues" - where NONE existed under plain vanilla, SD card.  

The desire to, "Call this SDHC issue resolved" (while understandable) does not meet (reasonable) scientific nor business-case scrutiny.

Again - this, SDHC "sensitivity" visits many ARM vendors.    As I've past stressed - this is no knock upon Amit nor this vendor - instead it's a plea for a (more proper) wider investigation of the SDHC "terrain" - so that user-clients do not suffer (avoidable) delay/frustration. 

Bulk of our firm's clients - using LX4F, LM3S, & TM4C - report issues w/SDHC when capacity is high (say 16GB & up) and performance is high. (say intended for digital camera)  

Might a more comforting, more robust test see TM4C connect & transact properly - over time - with the "largest capacity, fastest SDHC" cards commonly available w/in the North American market?  (assume that's where "biggest/fastest" SDHC resides)

Good science does not (usually) result from "quick/dirty/so very limited" tests - as reported here.   Unknown is (how or if) this vendor has reviewed & contrasted past SD spec w/newer SDHC - and if individual SDHC card makers are - at all times - in full compliance.  (one notes that RS232 was proposed as a "standard" and that over the years - many "unique" protocols & implementations - emerged.   Might the same be happening here?)

Closing this SDHC issue - based upon so few (successful) data points - may not prove, "best/brightest."