Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#11870 - Sansa Clip+/Fuzev2 SDHC detection

Attached to Project: Rockbox
Opened by Max Sin (z8080) - Thursday, 13 January 2011, 01:19 GMT+2
Last edited by Bertrik Sikken (bertrik) - Sunday, 17 April 2011, 11:47 GMT+2
Task Type Bugs
Category Drivers
Status Closed
Assigned To No-one
Player Type Sansa AMSv2
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Private No

Details

AMSv2 SDHC card detection problem described in  FS#11798  is not solved completely.

Here is original bug report:
http://www.rockbox.org/tracker/task/11798

And here is my description of revival of "solved" bug:
http://forums.rockbox.org/index.php/topic,26369.msg176646.html#msg176646
This task depends upon

Closed by  Bertrik Sikken (bertrik)
Sunday, 17 April 2011, 11:47 GMT+2
Reason for closing:  Fixed
Additional comments about closing:  This particular problem seems to have been caused by trying to enable sd card high-speed mode in an improper way. Should be fixed with r29660.
Comment by Andree Buschmann (Buschel) - Thursday, 13 January 2011, 22:51 GMT+2
shouldn't we re-open the original FS-entry and close this one?
Comment by Max Sin (z8080) - Friday, 14 January 2011, 15:49 GMT+2
In my opinion, re-opening of the original FS-entry is the best decision because symptoms of this issue are identical to  FS#11798 
Comment by Bertrik Sikken (bertrik) - Friday, 14 January 2011, 16:01 GMT+2
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.
Comment by Max Sin (z8080) - Wednesday, 26 January 2011, 17:48 GMT+2
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) 
 firmware/target/arm/as3525/sd-as3525v2.c |    1 +
 1 file changed, 1 insertion(+)

   sd-init-fix-INFO.patch (2.3 KiB) 
 firmware/target/arm/as3525/sd-as3525v2.c |   13 +++++++++++++
 1 file changed, 13 insertions(+)

Comment by Mikhail Titov (mlt) - Monday, 07 February 2011, 02:23 GMT+2
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.
Comment by Dragan (Idokras) - Tuesday, 15 February 2011, 12:21 GMT+2
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
Comment by dan m (mutex) - Friday, 11 March 2011, 06:45 GMT+2
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.
Comment by Haim (haim) - Sunday, 13 March 2011, 14:19 GMT+2
Thanks! It helped me a lot.
Comment by D Vegas (j4tp) - Friday, 18 March 2011, 22:13 GMT+2
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) 
 firmware/target/arm/as3525/sd-as3525v2.c |    1 +
 1 file changed, 1 insertion(+)

Comment by Bertrik Sikken (bertrik) - Sunday, 20 March 2011, 11:02 GMT+2
The 100 ms delay has been committed as SVN r29619
Comment by Bertrik Sikken (bertrik) - Sunday, 20 March 2011, 14:06 GMT+2
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) 
 firmware/target/arm/as3525/sd-as3525v2.c |   12 +++---------
 1 file changed, 3 insertions(+), 9 deletions(-)

Comment by D Vegas (j4tp) - Sunday, 20 March 2011, 21:44 GMT+2
Clip+ here, 32gb SD card did not show up after patching r29625 with your patch.
Comment by Bertrik Sikken (bertrik) - Monday, 21 March 2011, 09:14 GMT+2
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) 
 firmware/target/arm/as3525/sd-as3525v2.c |   26 --------------------------
 1 file changed, 26 deletions(-)

Comment by D Vegas (j4tp) - Monday, 21 March 2011, 09:59 GMT+2
Patched cmd6_away_v1 with current build (r29625) and clip+ did not display the 32gb SD.
Comment by Bertrik Sikken (bertrik) - Monday, 21 March 2011, 20:01 GMT+2
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 */
Comment by D Vegas (j4tp) - Monday, 21 March 2011, 20:28 GMT+2
I removed and inserted the card, and it appeared, as you said it would.
Comment by Karl-Heintz Müller (muelly2) - Monday, 21 March 2011, 22:36 GMT+2
Same here (SansaClip+, 16GB uSD). I also tried r29627, no luck. With 3.71 it works.
Comment by MichaelGiacomelli (saratoga) - Wednesday, 23 March 2011, 01:04 GMT+2
r29625 breaks SD detection on powerup. I'm not sure why yet.
Comment by MichaelGiacomelli (saratoga) - Wednesday, 23 March 2011, 01:17 GMT+2
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) 
 firmware/target/arm/as3525/sd-as3525v2.c |   11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

Comment by Matt M (Chesteta) - Wednesday, 23 March 2011, 04:33 GMT+2
saratoga: also works for me, I am using an 8gb card
Comment by D Vegas (j4tp) - Wednesday, 23 March 2011, 08:49 GMT+2
Clip+ 32gb SD here, saratoga's patch works.
Comment by Bertrik Sikken (bertrik) - Wednesday, 23 March 2011, 13:17 GMT+2
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.
Comment by MichaelGiacomelli (saratoga) - Wednesday, 23 March 2011, 20:42 GMT+2
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.
Comment by Richard Fröhning (omnirox) - Thursday, 24 March 2011, 11:36 GMT+2
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.
Comment by sideral (sideral) - Thursday, 24 March 2011, 14:00 GMT+2
funman has committed a change based on saratoga's patch as r29638.
Comment by Bertrik Sikken (bertrik) - Saturday, 26 March 2011, 11:58 GMT+2
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.patch (1.4 KiB) 
 firmware/target/arm/as3525/sd-as3525v2.c |   20 +++++++-------------
 1 file changed, 7 insertions(+), 13 deletions(-)

   cmd6_away_v2.patch (1.5 KiB) 
 firmware/target/arm/as3525/sd-as3525v2.c |   26 --------------------------
 1 file changed, 26 deletions(-)

   wait_response_v1.patch (1.2 KiB) 
 firmware/target/arm/as3525/sd-as3525v2.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Comment by Matt M (Chesteta) - Saturday, 26 March 2011, 23:11 GMT+2
with the latest commits, 29647-29651 do you still need the three patches tested? (or did the commits fix those things)
Comment by Bertrik Sikken (bertrik) - Sunday, 27 March 2011, 00:59 GMT+2
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) 
 firmware/target/arm/as3525/sd-as3525v2.c |   29 -----------------------------
 1 file changed, 29 deletions(-)

Comment by Matt M (Chesteta) - Sunday, 27 March 2011, 03:56 GMT+2
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 :)
Comment by Bertrik Sikken (bertrik) - Sunday, 27 March 2011, 10:00 GMT+2
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".
Comment by Matt M (Chesteta) - Wednesday, 30 March 2011, 20:06 GMT+2
working great with my card (v3 patch), compiled with 29661 :)
Comment by Bertrik Sikken (bertrik) - Wednesday, 30 March 2011, 21:23 GMT+2
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.
Comment by Luca Leonardo Scorcia (LucaLeonardoScorcia) - Tuesday, 05 April 2011, 14:46 GMT+2
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.
Comment by Bertrik Sikken (bertrik) - Tuesday, 05 April 2011, 15:32 GMT+2
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.
Comment by Luca Leonardo Scorcia (LucaLeonardoScorcia) - Tuesday, 05 April 2011, 17:02 GMT+2
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.
Comment by Bertrik Sikken (bertrik) - Tuesday, 05 April 2011, 18:11 GMT+2
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).
Comment by Luca Leonardo Scorcia (LucaLeonardoScorcia) - Tuesday, 05 April 2011, 23:36 GMT+2
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.
Comment by Luca Leonardo Scorcia (LucaLeonardoScorcia) - Saturday, 16 April 2011, 10:27 GMT+2
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!

Loading...