Sansa Clip+ Don't Recognize SD card

[Echo]

Hi all.
I'm new to rockbox and already having problems, hope someone could help.
I got a new Sansa Clip+ 4GB and a SanDisk Ultra 64 GB micro SD card.
I formated The SD card to fat32 using mkdosfs -F 32 on my ubuntu.

The original SanDisk firmware recognized the SD card.
After switching to rockbox 3.13 the SD card isn't recognized anymore.
When I plug in the Clip to my computer, it recognizes 2 devices, one of 4 GB (the clip) and one of 60 GB (the sd card) (Even after rockbox).

I found this patch http://www.rockbox.org/tracker/task/11798 but it no longer works since the version is too advanced.
I know a thing or two about programming but I never worked with SD card drivers or protocols.

Please help me, I'm all out of music

Peace And Love
Raz

[saratoga]

If you look on the left of the screen you can see that the patch in that task was added to rockbox in December 2010.

If the card works with Rockbox in USB mode I suspect everything is working. Does the microsd1 entry show up in the file menu?

[Echo]

Hi, thanks for the fast reply,
I noticed it was inserted in 2010 but there was another patch in the reply there that I wasn't sure if that one entered or not.
Any way this doesn't work so it does not metter.

I don't see a MicroSD1 entry in the files menu and not in the system/rockbox info/MSD

Peace And Love
Raz

[Julian67]

By coincidence today I took delivery of a SanDisk Ultra 64 GB micro SD, this one: http://www.amazon.co.uk/gp/product/B0084DWD4Q

In Debian stable I installed the exfat utils so the card's file system could be recognised.  It then mounted OK.  Then I formatted it in Debian using GParted, writing a new msdos partition table and a FAT32 file system.  Then I copied a couple of albums to it and checked it was recognised in my Rockboxed Fuze+.  It seemed OK.  However in a microSDHC card reader doing sustained writes (rsync my old 32GB card to the new card) it got extremely hot and unmounted.  This happened a couple of times but  with the card in the Fuze+ writes were very slow  so I spent some time this afternoon trying to get things so the card works in Rockbox and also reads/writes the FAT32 file system at proper speed without heat or unmounting (I found these issues are quite widely reported).  I succeeded, so you probably can too.

I started over:

Formatting the card:  I booted my EeePC into Windows XP SP3, downloaded the exfat support update from Microsoft and installed it and rebooted.  Then I used the SD Association's SD Formatter 4.0 tool to restore the card to its original state complete with exfat file system.  The SD Formatter 4.0 recognises the hardware and automatically writes the correct partition table and partitions the card with 16MB free space at the beginning, an exfat file system in the middle and about 3.3MB free space at the end (just as the card was supplied).  Then I downloaded the guiformat tool from   http://www.ridgecrop.demon.co.uk/index.htm?guiformat.htm  I used this at its default settings and it retained the partiion layout and formatted the exfat file system to FAT32.  This all worked Ok and the card was recognised by my EeePC and by Rockbox just like any compatible microSDHC card.  For some reason on my desktop I now had trouble writing to it (could add files but not create directories) if it was attached via a USB or integrated card reader.  While in the Fuze+ it worked but was slow.  The difference apparently is the card reading hardware.  My desktop is old and cheap with a really lousy built in SD reader that must be from the stone age.  It also turned out that my USB 2.0 Lexar microSD reader that was supplied with my 32GB microSDHC card has trouble with microSDXC even when formatted to FAT32.  Luckily last week curiosity and cheapness overcame me, I found myself in a 99p store and bought a USB 2.0 multicard reader (exactly the same as the one linked) and this cheap and generic but new reader works fine with microSDXC.  I was able to copy a full 32GB card's contents to the new 64GB card at high speed without any excessive heat or unmounts, then I added a lot more music to it and put it in my Fuze+, did a database update and PictureFlow update and have been using it for a few hours.  It's absolutely fine.

So, I apologise for having been verbose but I wanted to illustrate that there might be more than one issue to consider:

Linux kernel and disk utilities maybe are not yet ideal with microSDXC hardware.  If you have Windows XP/Vista/7/8 available then there are some excellent automated tools for these specific tasks.

Older card readers might appear to be compatible but actually be problematic.  Slow write speed is a relatively small problem but unwanted unmounts are not good and the card getting extremely hot might be terminal for the card or the card reader it's in.

99p stores are great and being cheap is its own reward.

[Echo]

Well Jolian you got me thinking.
I noticed that /i have a file with a corrupt name in my SD.
Also I put some files with hebrew file names on it.

So I decided to start over. I re-formated my SD using ubuntu disck utility (yes, I know, GUI... BAHHH)
and I re-installed rockbox from the offisial relice. Than my (empty) SD card got recognized.
Than I started adding files graduatlly, checking that they work each time.
All went well...

Conclutions:
1. Use only well tested formating tools
2. Don't use corrupted files
3. Make rockbox support xFAT file system

Now my only problem is the bad encoding of some of my hebrew files ID3tags but that fixable :-)

Than you all very much for your help

Peace And Love
Raz

[wodz]

xFAT is not gonna happen anytime soon if ever.

[Echo]

Why not? Maby I could help?

[AlexP]

http://www.rockbox.org/wiki/NoDo

In addition to any problems about an open source implementation existing that could be ported to Rockbox etc. etc.

Same reason we don't support anything other than FAT

[Echo]

I saw the NoDo only after posting this, so I'm sorry for spamming.
But the NoDo says this is mainly a RAM issue.
As far as I understand it, this is the code volume of the additional file systems that concerns the developers.
So maybe one could think of dynamically load of FS code or conditional compiling of FS code.
Anyway I think this is beyond this forum scope so I will try to think of a compleat solution an post it if I can get something good enough.
Thanks anyway

[saratoga]

http://www.rockbox.org/wiki/NoDo

In addition to any problems about an open source implementation existing that could be ported to Rockbox etc. etc.

Same reason we don't support anything other than FAT

There is actually an open source implementation we could use (its in cyanogenmod now), so I don't know that we wouldn't ever do it.  But yeah at the moment unless someone is interested in working on it I don't see much need. 

[wodz]

I am not aware of current status quo but the main objection to the open source xFAT implementation was patents issue. Microsoft holds the patents behind xFAT and it can use it to sue anyone at anytime.

Implementing fs as dynamically loaded modules is possible but needs at least:
1) inclusion of elf (or other) loader which supports relocation. Some work has been done in this are see:  http://gerrit.rockbox.org/r/#/c/326/
2) massive code reorganization.

This is not  weekend project really.

[mdreilly]

I just got the same 64GB card.  I can see it through the USB connection but it does not show up in the Sansa Clip directory.  It is currently formatted as EXFAT.  Are you saying that I have to reformat as FAT32?

Thanks.

[wodz]

yes