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

[werich]

tested r21248 (after format from the OF) on fuze 8GB (microSD temporarily removed cause it seems to work, as before).

Putting only a few files on it worked as it should (including building a correct DB) - but with more songs it didn't play these new ones, DB build stops immediately with 0 songs (not like before as it recognized at least the first 4GB correct). The accessible memory-border seems to be much lower now - 1 GB estimated. Maybe the 1GB with SD driver access funman mentioned at IRC yesterday?

Good thing is the filesystem corruption seems to be gone.

(edited: made it more clear)

[funman]

OK this looks like previously the bank switching failed, and now the initialization of bank switching fails.

To confirm you could format your Fuze with a size-limited file system:

mkfs.vfat -F 32 /dev/sdb $((0x7A7800/4-0xF000)) # for 1GB filesystem, test with r21248
mkfs.vfat -F 32 /dev/sdb $((0x7A7800-0xF000)) # for 4GB filesystem, test with r21247

and see if rockbox functions properly.

I had a look at the disassembly again and I found these:

• The OF sometimes use direct copy from MCIFIFO and doesn't use DMA (I don't know when exactly)
• The OF change pclk & fclk before and after bank switching, but not when initializing bank switching (this is done in early hardware init)
• The current OF has no support for 16GB, sorry ^^

I could perform some tests if I could reproduce this problem but "unfortunately" my Fuze works perfectly ..

[matsch]

I observed 'view buffering thread' of Clip v1 while playing mp3.
MP3 playing stops occasionally when buffer usefl is filled up. Buffer pcm is 0.

I reduced buffer size by changing 'Max Entries in File Browser' to 4450
and 'Max. Playlist Size to 1000'. With this settings the bug can be repoduced with a certain mp3 file.
Shortly after starting play I hear a hissing noise and playing stops. After changing back the settings the file plays on.
some files play fine with the 4400/1000 setting, some not.

[funman]

Before the thread becomes filled with loads of bug reports about SD/internal storage:

• r21227 and before work fine (prior using the data cache)
• r21228 and after show random behaviour : file system corruption, problems in bank switching (can't access the full capacity)

I insist on the random behaviour because storage access works fine for some people and some revisions, and doesn't work the day after, even if the difference between the two builds are not related to Sansa AMS.


If the file system is corrupted, plugins and codecs which are loaded from the storage can't obviously be relied upon, so any crash report (data abort at XX ..) is basically useless.

Easy solution : don't use them.

If you want to use the unstable, unsupported, unreleased development version of rockbox, you should use r21227 or anterior.


How to report that your Sansa doesn't work: please do not, we already know that our code is broken.


Let me add that my Fuze 4GB worked very fine (I still see unfrequent corruption of the LCD display, but that has always been) yesterday, but not today; even if no related changes have been committed.
That seems like an extra argument to the randomness of the problems we have.

EDIT: my Fuze infinitely loops into sd_transfer_sectors() because the SD controller reports a DATA TIMEOUT (bit 3 of MCI_STATUS).
Still the exact same problem I saw before committing r21247 to set timeouts specified in SD Specification.
Still random though : my Fuze boots after I added debug code in INT_NAND() ..


@matsch : thanks for the report, I'll try to reproduce when I find some time

[freddy]

Hi people

I just tried rockboy and it works quit  well after a small patch to the button code. I made a little patch that makes the scroll wheel work in rockboy again. Most games I tried work very well already. Should I make an FS entry for this patch ?

[kugel.]

Hi people

I just tried rockboy and it works quit  well after a small patch to the button code. I made a little patch that makes the scroll wheel work in rockboy again. Most games I tried work very well already. Should I make an FS entry for this patch ?

Yes, and we also need your real name.

I haven't updated my fuze recently but I've not encountered SD weirdnesses so far.

[freddy]

http://www.rockbox.org/tracker/task/10327 Here is the FS entry 

My fuze isn`t having any problems with SD I am running r21265

[GodEater]

Can you please go back to the task and give us your full realname please. If you don't, your patch will get rejected.

[porio]

Hi everybody,

I've  been trying rockbox for some weeks in my Clip. Most of the time it rocks!! If it wasn't for the freezing problem...
But I have realized, with several SVNs, that the probability of freezing is almost certain after skipping a track. If I don't skip, I can usually play a full album without issues. I can even fool around with sound settings, applications, file browsing, etc. In the Anythingbutipod forum someone else reported the same.
Has anybody else noticed that? Wouldn't it be an important clue about what the origin of the freezing is?

I hope I'm not introducing noise with this, I'm definitively in the user's side but eager to help debugging. Thank you all for the effort!

Regards

[ku-ku]

I've installed the 21288 build with a bootloader of the same revision on my 8gb fuze with an 8gb card. The same problem with internal memory. But I do can use rockbox without a problem with my 8gb card and database works too when there are no files on the internal memory. And I am using it now because I can't stand original firmware. By the way if I try to use original firmware when there are  files on an internal memory my player can't display all the files neither on a card nor on a player. And there is a note on the sansa forum: Song database supports up to 8000 songs (requires device format through settings menu for libraries larger than 4000 files) . But when I tried to format my player in such a way rockbox refused to load till I format the player through windows format utility.

P.S. Sorry. I've checked rockbox after formatting from original firmware menu and rockbox works.

[hex]

So I ordered an 8GB Fuze with the expectation that I could use the built-in OGG/MP3/FLAC capability to keep me satisfied until a stable version of Rockbox was released for it.

As a long-time user of Rockbox for iPod Nano, I was looking forward to gapless and crossfading playback (among other cool features).  One of the first things I did once I opened the package was to update the firmware...  to V02.02.26A.

So I have a second-version Fuze that will not have a version of Rockbox for some time.  What kind of information do you guys need to get cracking on the V2 build?

[FlynDice]

What kind of information do you guys need to get cracking on the V2 build?

How much spare time do you have available and can you learn C...... 

[hex]

How much spare time do you have available and can you learn C...... 

I'm a Computer Science student on summer break.  You tell me.  :-P

I'm proficient in C++ and some assembly.  This seems like a great opportunity to get my feet wet in low-level C and asm, but I certainly don't want to brick the device.

If I can spare the disassembly of my brand new player, I would be happy to provide you whatever you need.

[FlynDice]

@funman:

system-as3525.c lines 300-302 the comment does not seem to match what the ascodec_write code actually does or am I missing something ....again.   P128 as3525 datasheet

[funman]

@ hex : ecrips has already done a dual boot support for Fuzev2, now you can read the disassembly of your OF and try to get LCD working (better contact ecrips first to share the work).

See FS#10047 : it's for the Clipv2 but the link to Fuzev2 work by ecrips is in the ticket.

@ FlynDice : Perhaps the comment could be reworded: you can experiment with removing this line and booting rockbox : keeping the power button pressed for 1 or 2 seconds will hard shutdown the player, while if this code is run you'll need to keep pressing for 10 seconds.

@ ku-ku : have you read this post ? Because your post just looks like a bug report which is not helping development.