Rockbox

shouldn’t we re-open the original FS-entry and close this one?

In my opinion, re-opening of the original FS-entry is the best decision because symptoms of this issue are identical to  FS#11798 

IMO, there are several things wrong with the sd card driver. Heaping them all up in a single task confuses the various possible causes of uSD problems.
For example you are describing some other corruption problems, this was not described in the the previous task.
 FS#11798  described a particular problem plus the fix for it, so I am against re-opening it.

BTW, I prefer to have the full description of the bug in the flyspray task, instead of in an external link.

I made some tests and problem with MY Transcend 16Gb microSDHC card (no tests with other cards, sorry) was solved by increasing delays during card initialisation. Patch for this – sd-init-fix.patch

NOTES for more, than I, skilled developers:
a) I assume, that delay for 100 milliseconds is long enough for completion of card internal operations, but is subjectively short and not visible for users. In “original”  FS#11798  issue delay for 1 millisecond was enough, so with 100ms we have good overlap.

b) IMHO, we don’t always properly wait for the response of the card during “setting card to the HS timings” commands sequence. But I am not familiar with SD specs, so I cannot figure out how fix this issue.

c) Patch file with some results of my tests – sd-init-fix-INFO.patch
Sorry for weird form of its representation, but I hope, that it may be useful for locating “failed” SD-command.
Marks “25.0MBit/s” and “50.0MBit/s” are from “System-Debug-View disk info” menu. They are identical for both internal and external cards.

   sd-init-fix.patch (0.5 KiB)
   sd-init-fix-INFO.patch (2.3 KiB)

Suggested delay results in 50 Mb/s (vs 25 Mb/s) reported for internal memory on my Clip+ with 8 Gb internal memory while making no difference (25 Mb/s) for external Transcend 32 Gb microSDHC memory card.

The patch by Max Sin helped me recognize my 32GB Sandisk SDHC card, which the latest build could not. Here’s the card infromation from the debug menu:

SU32G Rev 8.0
Prod: 11/2010
Ser#: 0x0BB8D125
M=03, 0=SD
Blocks: 0x03B72400
Speed: 50.0MBit/s
Taac: 10.0ms
Nsac: 0 clk
R2W: *2
IRmax: 35..45 mA
IWmax: 60..10mA

Just a FYI, this patch was also the only thing that worked for me on my fuze V2. The 3.8 release nor the current build of r29559 worked, my card (Sansdisk 32G) would be seen by the OF but not rockbox.

Works great after applying the patch from Max Sin.

I still cant get USB data transfer working, but I dont think this patch was supposed to address that.

Thanks! It helped me a lot.

Patch updated to work with latest (currently r29611). Tested with a Sansa Clip+ and it seems to work.

   sd-init-fix.patch (0.5 KiB)

The 100 ms delay has been committed as SVN r29619

Can someone with a card that didn’t work previously, test the attached patch?
With this patch, the sd controller waits until the data sent by CMD6 has been fully transfered, before issuing another command (and it replaces the delay).

   cmd6_fix_v1.diff (1.9 KiB)

Clip+ here, 32gb SD card did not show up after patching r29625 with your patch.

Pity it didn’t work. How about the following patch?
It simply removes the code that puts the card in hi speed mode, this should have no effect on transfer speeds because the controller doesn’t use hi speed mode itself yet.

   cmd6_away_v1.diff (1.5 KiB)

Patched cmd6_away_v1 with current build (r29625) and clip+ did not display the 32gb SD.

j4tp, does it show up if you replug the card? I do see a problem now with cmd6_away_v1.diff, but only when it is plugged in during boot. It starts working when I replug the card.
As far as I understand from z8080 (jan 26th), things started working actually for him when disabling the high-speed switch code:
+ //if (false) /* No HS timings - no problems */ /* M */ /* OK, 25.0MBit/s */

I removed and inserted the card, and it appeared, as you said it would.

Same here (SansaClip+, 16GB uSD). I also tried r29627, no luck. With 3.71 it works.

r29625 breaks SD detection on powerup. I’m not sure why yet.

This patch fixes it for me, but I’m not 100% sure the logic does what r29625 was supposed to.

   test_sd.patch (1 KiB)

saratoga: also works for me, I am using an 8gb card

Clip+ 32gb SD here, saratoga’s patch works.

saratoga, what kind of hypothesis are you making about how the internal sd memory is organised? Aren’t you compensating for the AMS_OF_SIZE twice now?
Odd BTW, how basically a change for internal df memory has an effect on how external sd memory works.

As far as I understand the internal sd memory organisation:
* I *guess* the size reported in the CSD is the total size of the internal sd memory
* The first 30 MB are reserved for the OF image. Our code skips this first 30 MB at a very low level, so the upper layers (file system, usb storage etc.) are not even aware of this.
* The rest of the memory is available as internal storage for songs etc.

r29625 just moves the check for out of bounds access to be before the size of the OF is added (in the case of internal memory). I think this breaks card detection because the call to sd_init_card() is missed due to the moved check. So I just moved the check back to the original location and changed the check to account for the OF size.

I confirm saratogas patch fixed an unrecognized 8GB SD-card in my clip+ with the current HEAD svn: r29630
on bootup. Thanks a bundle - They both show 50MB/s. Cheers.

funman has committed a change based on saratoga’s patch as r29638.

Another couple of patches to simplify and clean things up, please try (they work for me):

• simpler_numblocks_check_v1.patch simplifies the check of accessed blocks against the highest block
• cmd6_away_v2.patch entirely removes the part where we switch the card to high-speed mode. Switching to high-speed mode is currently useless because we don’t switch the sd controller into high-speed too.
• wait_response_v1.patch makes rockbox properly wait for the response of the SD_STOP_TRANSMISSION command

Things to try:

• does it still boot? :)
• is an external sd card still recognised at all?
• is an external sd card recognised directly after reboot?
• is an external sd card recognised after reinserting it?

   simpler_numblocks_check_v1.pa... (1.4 KiB)
   cmd6_away_v2.patch (1.5 KiB)
   wait_response_v1.patch (1.2 KiB)

with the latest commits, 29647-29651 do you still need the three patches tested? (or did the commits fix those things)

Patch wait_response_v1.patch has already been committed. I’m pretty confident that patch simpler_numblocks_check_v1.patch just works (it’s not really a sd controller change).
The most interesting patch is cmd6_away_v2.patch, please test that one. It works for me, but I also never had the original problem.
Attached patch cmd6_away_v3.patch also gets rid of another delay, could you also test that one?

   cmd6_away_v3.patch (1.7 KiB)

what issue is it that we are testing for with cmd6? I do not have a SDHC card, my card is only 8 gb so I am not sure if my tests will be very conclusive; glad to do a few trials though :)

The issue is that some uSD cards do not work properly with AMSv2 players (sansa clip v2, sansa clip+, sansa fuze v2). After investigating this, it appears that the problem occurs in a piece of code that isn’t necessary in the first place (sending cmd6 to the sd card). So the “cmd6_away” remove this code. I never had the problem myself in the first place, so I can’t verify myself that removing this code actually helps. So I’m asking people to test.
You *do* have an SDHC card, anything bigger than 2 GB will at least be SDHC, not “normal SD”.

working great with my card (v3 patch), compiled with 29661 :)

OK, I committed the wait_response and cmd_away patches and I don’t see anything fundamentally wrong anymore. Please keep reporting if you have problems accessing sd cards.

One of the recent AMSv2 SD changes broke uSD on my player. Latest SVN version (+ Enable Rockbox USB) on FuzeV2 variant 0: the card is recognized fine and I can browse folders fine, but Rockbox locks pretty much immediately when playing music from uSD. The player becomes unresponsitive until I eject uSD, at that point it resumes working. The card is a Sandisk Class 6 8GB. I’ll try to bisect as soon as I can.

Please bisect as soon as possible. These changes seemed to be fully functional until now, so they have been committed in the 3.8.1 branch too, which is very close to release.

Sorry for the delay but I’m on cygwin here at work… r29655 is the last working one. I have tested all the relevant later revisions and they all exhibit the same behavior.

Thanks for bisecting. It appears then that r29656 is the culprit (”AMSv2 sd: do sd slot switching with GPIO B5 only for AMSv2 variant 1”). I can’t explain this logically yet.
For the 3.8.1 we might have to revert r29656 (and r29667 which relies on r29656). Are you able to build and test a firmware with r29667 and r29656 reverted?
If not, drop by in the irc channel (#rockbox on freenode.net) in a few hours and I might be able to build you a test firmware (if you’re interested in helping to test).

Apparently my bisecting was too superficial. I just retried with r29655 and the problem is still present.
I have tested official 3.8 - works fine - and pre-official 3.8.1 - same problem. I’m gonna try to go back a few revisions more, but I’ll need some more time. Sorry for the wrong info above.

I did a thorough bisection but the results were inconsistent. In the end I switched to another uSD and it works just fine now. The older uSD works fine in my phone, but since there were no other reports I suspect some strange hardware issue. Thanks to everyone that helped!