SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2

[ku-ku]

It certainly works now . I was able to create bookmarks now on my both cards without a single failure. Writing on my cards works too now. I am able to copy files from internal memory to sd card and deleting files and folder. Nevertheless one attempt of more than two dozen to delete different folders failed with "transfer error : 0x2" message, but after reloading a player I could delete this folder.

[musojon74]

Hey guys

Nice work on the development - Rockbox is working pretty awesome here

OK I've got a Fuze V1.  I'm using r22777-090921.  I have an Integral 16gb class 2 card - if I can run any tests which help with the sd corruption checking please let me know (I've been only playing stuff really and loading player with usb connect in OF mode).  Also, OT, let me know any other stuff you want me to try and test. Thanks again for all your hard work.

Muso

[Hillshum]

Try writing files to the SD card from within Rockbox, as well as deleting and creating folders

[musojon74]

Ok have created 10 folders in quick succession looking good.  Will copy some mp3s around now quickly and see if that breaks anything.

[ku-ku]

I found out that I have more chances to get transfer error : 0x2 when I try to delete a folder in a
subfolder with very big number of folders (more than 100, in my case) on my both cards - transcend 8gb class 6 and silicon power 8gb class 6.

[funman]

flyndice have you tried reading the extended status register ?

it should be acmd13, then read the status on data line (using DMA)

[FlynDice]

I tried reading that with your patch that used DMA and have not been able to get that to work yet.

I still can't  get the cards to operate without the bypass bit set.

I can set high speed timing with no problem.  In fact, changing to highspeed timings allowed me to copy a single file from the internal to the uSD card without the delay I added recently, but any copy with a directory involved would fail.

I have partial operation on both cards with 4 bit widebus.  I can browse files and display album art but cannot play music off of a card in widebus mode.  It seems that the transfer never stops.  In View I/O ports you can see the sd card transfering data on the GPIOD display.   The 4 lsb's are the 4 data bit pins.

I have added a few things to the dma driver and now have normal playback without changing the AHB priority with  CCU_SCON = 1 in system-as3525.  I have this line commented out and my player is playing normally.

I have been spending today trying to understand wakeup's and dma_callback today without much luck so far but I haven't spent a whole lot of time on this yet.

I'll post some patches later tonight or maybe tomorrow, I've got 170 people waiting for me to take them to San Francisco in 20 mins.....







EDIT:  @ku-ku:  I changed the delay to a check for FIFO activity which should handle your large number of folders.  Would you test and let us know?

[ku-ku]

I could replicate the error trying to delete some folders before r22850 patch was committed. With r22850 patch I have no errors at all. It seems it works perfectly now.

[epithetless]

Just so I can get a wider perspective on the issue: Are other Fuze owners seeing sporadic LCD glitches, where the entire screen distorts for a split-second and then returns to normal? I've noticed this ever since I began using Rockbox on my Fuze in early July, and it has persisted up through the most recent builds (I'm on r22850 at the moment). I find it happening most after I've just returned to the WPS from the file browser, or shortly following an unlock of the hold switch -- both with music playing -- but I haven't found a reliable way of prompting it. Is this behavior isolated to my device or is it just some of the Fuze's "unstable" status showing through?

[saratoga]

Its really easy to see in mpegplayer on my Fuze.

[epithetless]

Its really easy to see in mpegplayer on my Fuze.

Okay, so it sounds like some kinks in the display still need to be worked out. Glad it's not just my unit!

[kugel.]

Its really easy to see in mpegplayer on my Fuze.

Okay, so it sounds like some kinks in the display still need to be worked out. Glad it's not just my unit!

http://www.rockbox.org/tracker/task/10603 fixes that. The problem is that the hold button can't be read for some reason.

[yelped]

Its really easy to see in mpegplayer on my Fuze.

Okay, so it sounds like some kinks in the display still need to be worked out. Glad it's not just my unit!

http://www.rockbox.org/tracker/task/10603 fixes that. The problem is that the hold button can't be read for some reason.

I never use the hold button, and I get occasional LCD Glitches.

[epithetless]

Its really easy to see in mpegplayer on my Fuze.

Okay, so it sounds like some kinks in the display still need to be worked out. Glad it's not just my unit!

http://www.rockbox.org/tracker/task/10603 fixes that. The problem is that the hold button can't be read for some reason.

I never use the hold button, and I get occasional LCD Glitches.

I think what kugel means is that the patch which fixes the LCD glitches has the side-effect of rendering the hold switch inoperable on the Fuze.


On a different note:

Is anyone else seeing a decrease in scroll wheel accuracy on their Fuze following the commit of r22863? Quite often now, when scrolling through a list, my pointer jumps 1 step in the opposite direction of the way I was scrolling at the very end...

[Dhraakellian]

Is anyone else seeing a decrease in scroll wheel accuracy on their Fuze following the commit of r22863? Quite often now, when scrolling through a list, my pointer jumps 1 step in the opposite direction of the way I was scrolling at the very end...

I can confirm this (using r22864).  Good to see I'm not going mad the only one experiencing this.