Rockbox

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

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#10507 - AMSSansa Lower frequency for uSD Card on as3525 to comply with sd specification.

Attached to Project: Rockbox
Opened by Jack Halpin (FlynDice) - Tuesday, 11 August 2009, 08:18 GMT+2
Last edited by Jack Halpin (FlynDice) - Tuesday, 08 December 2009, 21:36 GMT+2
Task Type Patches
Category Drivers
Status Closed
Assigned To No-one
Player Type Another
Severity Low
Priority Normal
Reported Version Version 3.3
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Private No

Details

This patch lowers the frequency of the card clock to 31 Mhz for a high speed card and 15.5 MHz for a standard speed which respects the sd specification speeds of 50 & 25. Due to the current PCLK setting of 62 MHz these are the highest frequencies we can use and still remain within the spec. I have only tested on my e280v2. I can copy and delete files between the uSD and internal with no problem and music plays normally. I have not run check_disk yet. I had to disable widebus(4bits vs 1) to get this to work.
   uSD_spec_freq2.diff (3.1 KiB) 
 firmware/target/arm/as3525/ata_sd_as3525.c |   40 ++++++++++++++++++-----------
 1 file changed, 25 insertions(+), 15 deletions(-)

This task depends upon

Closed by  Jack Halpin (FlynDice)
Tuesday, 08 December 2009, 21:36 GMT+2
Reason for closing:  Fixed
Additional comments about closing:  Fixed with r23901
Comment by Rafaël Carré (funman) - Tuesday, 11 August 2009, 13:44 GMT+2
Thanks for the patch, it works fine with my 2 µSD cards

I think the timeouts should be hardcoded, like SD_MAX_READ_TIMEOUT[NUM_VOLUMES], because we always know the state of the MCI_CLOCK_BYPASS bit for drives 0 & 1, so no need to read it.

Also is the change to pushpull bus mode needed?

Why do you put an extra card_info[drive].initialized = 1; before initialization is fully completed?

Since we should know what we set MCI_CLOCK to, I think reading it and doing a "& 0xff00" is not needed, but that's almost cosmetics.

Last thing: I'll run a test_disk in benchmark mode with and without this patch to see if using 1 or 4 bits data line has a noticeable effect.
Comment by Rafaël Carré (funman) - Tuesday, 11 August 2009, 15:04 GMT+2
correction: while modifying test_disk to run it off the µSD i am seeing unhandled interrupt 00

btw I'll make a better error message for this one
Comment by Rafaël Carré (funman) - Wednesday, 12 August 2009, 16:19 GMT+2
No difference in benchmark for my 2GB µSD card, I tested r22268 with & without this patch, with "/<microSD1>/__TEST__" as test directory in test_disk.c

I did not bother with percentages for the (tiny tiny) performance difference, i attach the results if you want to check
   r22268.txt (0.7 KiB)
   r22268_fs10507.txt (0.7 KiB)
Comment by Jack Halpin (FlynDice) - Wednesday, 12 August 2009, 21:59 GMT+2
Crap! Once again I have screwed this up. This patch does not run the uSD at the lower freqs as the bypass bit has not been unset.
Comment by Rafaël Carré (funman) - Wednesday, 02 September 2009, 18:37 GMT+2
I just changed your patch to not set the bypass bit (I changed a bit the code which sets MCI_CLOCK)

I also let the change to test_disk.c to use the µSD and not internal storage.

It gets no worse than with SVN: when deleting the MUSIC/ folder created by the OF from the card I get a data crc fail (error 0x2) on the Transcend 4GB class 6

Could you check I didn't mess up either ?

Regression: microSD isn't detected on boot, you have to remove and reinsert it.

test_disk is a bit faster on 512b accesses, slower on other, and a write+compare test with 300MB was OK, now running with 2047MB
   ams_sd.diff (4 KiB) 
 b/apps/plugins/SOURCES                       |    1 
 b/apps/plugins/test_disk.c                   |    2 -
 b/firmware/target/arm/as3525/ata_sd_as3525.c |   44 +++++++++++++++++----------
 3 files changed, 31 insertions(+), 16 deletions(-)

Comment by Rafaël Carré (funman) - Wednesday, 02 September 2009, 19:35 GMT+2
Test passed. (2GB)
Comment by Michael Chicoine (mc2739) - Thursday, 03 September 2009, 01:28 GMT+2
Tested on e260v2 with SanDisk microSD type 2 4gb sdhc card. When accessing the card through the file browser, only 1 directory (out of 37) was listed, if any. The card would mostly show "Not Found!" in the Debug->View disk info screen. It did show the correct size and available space on the Rockbox Info screen. It did not seem to matter if the cpu was boosted or not.
Comment by Hilton Shumway (HIllshum) - Thursday, 03 September 2009, 04:06 GMT+2
e260v2 with 2GB SanDisk card, I get '*PANIC* MicroSD init failed: -3' upon insert, boot hangs, backlight and buttonlight threads still run.
Comment by Rafaël Carré (funman) - Thursday, 03 September 2009, 11:15 GMT+2
Testing again I had trouble playing files, WPS would stay on "elapsed time: 0"
Comment by Jack Halpin (FlynDice) - Friday, 04 September 2009, 07:30 GMT+2
Just a couple of notes on the things I've learned so far while looking at this.

The pushpull/opendrain thing is not an issue for us with sd, it is an mmc thing. The pl180 reset value for this puts the bus in pushpull mode anyway and we never change it which is how it should be.

The 400kHz limit during the ident phase is also an mmc thing and does not apply to sd. When it says "some cards" need this it's referring to mmc cards, not some sd cards.
The pl180 is designed to be used with both. My e280v2 internal and microsd work fine without the 400kHz Ident freq. and simply initializing at full MCLK freq(bypass).
We don't need to worry about someone trying to stick an mmc card into our microsd slot, it won't fit.....

In present SVN it seems we put the card in 4 bit mode but not the controller. I could not get 4 bit to work with the internal but with my uSD card I could browse the files and get album art displayed but
music would stop after 2-3 seconds. There is a 50 Kohm pull up resister on dat3(pin1) of the sd card that should be disconnected with ACMD42 SET_CLR_CARD_DETECT after entering 4bit mode.

Putting both cards into HS timing with the switch command seems to work fine.

Omitting the SD_SET_BLOCKLEN command seems to work fine as it defaults to 512 anyway.

That's all I can think of right now, I've had to take a break from the sd stuff for awhile as it was starting to turn me into a blithering idiot......

I've been trying to get the debug page to reliably show the card freqs so I do not end up with another "bypass screwup".

Comment by Rafaël Carré (funman) - Friday, 04 September 2009, 09:23 GMT+2
The 4.4 Clock Control § of SD spec (page 53 of PDF) says the clock should be running in the frequency range of 100KHz-400KHz
Comment by Jack Halpin (FlynDice) - Friday, 04 September 2009, 20:53 GMT+2
Well, that does seem to imply it's needed. I based my ident comment on a couple of sources:

www.sandisk.com/media/216454/appnotemmc_sdv1.0.pdf P.3:

Timing specifications
Design engineers must meet the rise, fall, setup, hold, and other SD Card and
MultiMediaCard bus timing specifications. If they want to support MultiMediaCards in
their design, the clock speed should be controllable by the host. This is due to the
MultiMediaCard's open-drain mode; the MultiMediaCard powers up in the open-drain
mode and cannot handle a clock faster than 400 Khz. Once the MultiMediaCard
completes the initialization process, the card switches to the push-pull mode. In the pushpull
mode the MultiMediaCard can run at the maximum clock speed.

and p.6:

Clock control is another option that should be implemented in a MultiMediaCard or SD
Card design. As mentioned in the Timing section, if the design needs to support the
MultiMediaCard, the clock should be lowered to 400 kHz or less during initialization.
When the initialization process is complete, the host can raise the clock speed to the
card’s maximum.

And also in a Sandisk manual I can't find a link for right now but the file name is: Sandisk_productmanualsdcardv2.2final.pdf

from a table on p.3-9:

Clock Freq. Identification Mode(9) fOD 010/10 0 400 kHz CL < 250 pF (21 cards)

(9) Low frequency required for MMC compatibility.


I hadn't looked back at the SD spec after finding these. There's so much missing from the simplified spec that I've found a lot of info by looking through the card manuals from several card manufacturers.

It didn't really change anything when I tried it anyway, it just worked. And what we do now works just fine it was just one of those observations that are crowding out my sanity.......

EDIT: Here's a similar doc I found a link for: www.cs.ucr.edu/~amitra/sdcard/ProdManualSDCardv1.9.pdf see the table on p.3-10
Comment by Jack Halpin (FlynDice) - Monday, 07 September 2009, 20:18 GMT+2
I think I found something useful this morning. I found I can run the cards at lower freqs as long as I lower the frequency by lowering PCLK. I don't think there's a problem running at lower frequencies I think there's a problem running with MCICLK != PCLK. If so I would think it would point to a problem with the way we deal with the FIFO as that is the buffer between things running in the PCLK domain and those in MCICLK domain. A lot of people know a lot more about that than me so knock yerselves out..... Or, then again I may not have a clue!

Loading...