• Status Closed
  • Percent Complete
  • Task Type Bugs
  • Category Drivers
  • Assigned To No-one
  • Operating System Another
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by Omega - 2010-12-08
Last edited by bertrik - 2010-12-26

FS#11798 - Files in MicroSD card aren't being shown in File Browser or Database on Clip+

I will copy the Post from the forum, because i am a lazy person:

” I have all of my files in the Music folder. I’ve refreshed the database numerous times. I have it on MSC mode and they still won’t show up. Can anyone give me any suggestions as to what to do?

With the Sandisk Firmware (CLIP+) all things working great, but in rockbox the card does not appear.

In “Rockbox Info” is only the Internal visible.
One line below it shows:
“HD1 Not present”

I have the SanDisk 16GB microSDHC Memory Card in FAT32.”,26369.0.html

I reloaded the clip. I reinstalled the firmware. I reformated the card.
Nothing works.
In the current version r28767 the issue still exist.

Closed by  bertrik
2010-12-26 13:37
Reason for closing:  Accepted
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

Patch wrs_sd_fix.patch committed as SVN r28903

Try this patch. It enables the high-speed mode only for v2 cards, like the clipv1 driver does.

Omega commented on 2010-12-08 21:05

Thank you very much

But i think i am too silly to patch the souce file. I have no experience in programming and i have tried it for 2 hours now and i stuck.

….is there some easier way to test your patch then

and this?

at: “In that folder type ../tools/configure which will bring up a list of all possible devices "

There is noch such folder….and what means “../”….under “help” there ist so such command.

sorry i am very confused. Maybe i will try it a second time tomorrow. I hope there will be a person with more experience who can test this faster than me.

I have a Clip+ with a SanDisk 16GB microSDHC card (class 4) showing exactly the same issue;

On booting Rockbox (tested stable release, and current daily build as of 2010-12-12) the contents of the SD card is not shown in the file browser. “Rockbox Info” shows “HD1 Not Present”. The “View Disk Info” Debug screen does correctly identify both SD cards (internal 8GB and 16GB microSD card). The Original Firmware sees the card and uses it quite happily. I’ve tried with the card partitioned and the partition formatted with FAT32, and with FAT32 written directly onto the card (no partitions, using mkfs.vfat -F 32 -I)

I decided to try building my own firmware this afternoon. I tried applying the “sd_highspeed.patch” provided by Bertrik. Interestingly this patch appeared to be in the svn code already so perhaps it has recently been applied to the mainline code. I also applied the second of the USB patches (as3525v2-usb.diff) from  FS#11664 . I mention this because I discovered something odd: If I plug the Clip+ into my Linux box it detects two block devices (both internal and microSD storage devices) and I can mount them both. In fact I have copied ~3.5GB from the microSD card to the internal memory in this way, apparently without issues. When I unplug the USB cord, the Rockbox firmware suddenly believes that the microSD card exists and a “<microSD1>” entry appears in the file browser. I can then play music from the microSD card, etc. If I power off and power back on, the player fails to see the SD card once again.

OK, it’s some sort of timing issue initialising the SD card. I’ve added a few delays in firmware/target/arm/as3525/sd-as3525v2.c:sd_init_card() and the card is now reliably detected on boot.

Unfortunately I was somewhat liberal with my delays! I’ll try to narrow down the minimum set of changes to make it work properly.

OK. The attached patch fixes the problem for me (ie, with my player and this particular SD card). A shorter delay also works but an extra millisecond every time the card is initialised is hardly going to hurt.

Nice build system you guys have, btw. Makes the compile/test cycle very quick.

Omega commented on 2010-12-12 18:10

@William R Sowerbutts

Thank you very much.

I have tried your patch and it worked.

In Rockbox Info it shows “HD1 14.8GB” GB now and in “Files” i can see “microSD1”.

In addition i can play a song from the disk.

If i should do some other tests, let me know. I will help if i can.


Jolly good. No idea how we go about getting this merged into svn – anyone?

Omega commented on 2010-12-12 18:40

@William R Sowerbutts

Thank you very much.

I have tried your patch and it worked.

In Rockbox Info it shows “HD1 14.8GB” GB now and in “Files” i can see “microSD1”.

In addition i can play a song from the disk.

If i should do some other tests, let me know. I will help if i can.


Hi Will, thanks for figuring out what makes the cards work again!

Indeed the first patch has already been applied. I’ve been merging some fixes/cleanups from another sd-card driver (for the sansa clip v1, fuze v1) to the sd-card driver for the clip+/fuzev2, this weekend.
Part of this cleanup is actually replacing some delays with more proper code. I think that for some commands, we don’t actually need the delay, as long as we just properly wait for the card’s reply (which we’re currently not doing consistently).
I’d like to finish that merge/cleanup and (together with your extra delay) have it tested by someone who is affected by this problem (you perhaps).

Happy do to so. Let me know when you have a patch and/or updated code in SVN. I’ll build a new version and test on my Clip+.



I think I’ll commit your fix soon, so people affected by this can have a functional sd-card.

The sd card code for AMSv2 players already has various (in my eyes arbitrary) delays and adding yet another one seems a bit ‘wrong’.
I looked a bit into it this weekend and I think the following is happening: we don’t always properly wait for the response of the card after sending a command. Many commands are responded with a simple 48-bit ‘R1’ response that we can easily wait for. However some commands trigger an ‘R1b’ response, which means that the cards sends an 48 bit response but also keeps asserts a ‘busy’ signal. I guess we don’t properly wait for this busy signal to be de-asserted, so we send the next command already before we are actually allowed to do so. I’d like to figure out if we can tell the sd card controller to wait for this busy-signal. Unfortunately I don’t have a datasheet of this controller, I’ll try to find out if/where we can find one. The end result of this investigation would be that the sd driver becomes more robust and is not using those arbitrary delays any more. This is a bit out-of-scope for this task though.


Available keyboard shortcuts


Task Details

Task Editing