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

[mc2739]

My card is a 4GB SanDisk brand. The player is an e260v2.

I also found that if I boost the CPU through the System -> Debug -> CPU Frequency screen and then insert the msd card, it works properly and can see all files on the card.  As long as the CPU stays boosted (i.e. CVDDP is 1.2V) the card will work.

[saratoga]

Apparently voltage scaling is responsible for breaking SD access on some Clips as well (thanks for dfkt for bug report).  We should probably revert it for now until we have a good fix and can have more people test it.

[Hillshum]

Thats my opinion too. I'm very happy with my e250v2, everything works fine! Really a great job! I'm currently testing everything, but nearly no issues so far. I had one data abort with the following conditions:

• playlist with mp3 files followed by ogg files
• last mp3 was on the last 10 % of time
• I skipped the track and instead of playing the ogg file the player showed data abort

I'm getting about the same on my e200v2. It happens anytime a song of one codec ends and the thing tries to start the next song of a different codec. So far I've tried wma, ogg, and mp3. What happens varies. Sometimes I get a data abort message, sometimes a prefetch abort, sometimes it locks up and takes a hard reset (though some threads remain active).
Here's the two data abort addresses I wrote down:
6f6c4120
62694c20
PM me for my rockbox.elf

Edit: I can switch songs halfway through just fine (even with crossfade)

[funman]

Apparently voltage scaling is responsible for breaking SD access on some Clips as well (thanks for dfkt for bug report).  We should probably revert it for now until we have a good fix and can have more people test it.

I thought FlynDice has a fix for that?

Thats my opinion too. I'm very happy with my e250v2, everything works fine! Really a great job! I'm currently testing everything, but nearly no issues so far. I had one data abort with the following conditions:

• playlist with mp3 files followed by ogg files
• last mp3 was on the last 10 % of time
• I skipped the track and instead of playing the ogg file the player showed data abort

I'm getting about the same on my e200v2. It happens anytime a song of one codec ends and the thing tries to start the next song of a different codec. So far I've tried wma, ogg, and mp3. What happens varies. Sometimes I get a data abort message, sometimes a prefetch abort, sometimes it locks up and takes a hard reset (though some threads remain active).
Here's the two data abort addresses I wrote down:
6f6c4120
62694c20
PM me for my rockbox.elf

Since 0x6******* is not a correct address on AMS, this clearly shows a bug in SD driver (when the codec is transferred from storage to RAM) / or memory corruption but this one is unlikely.

[saratoga]

I can confirm the codec bug but I get 0x3067C528.

Edit:  bah no .map files for svn builds anymore, i'll repeat it now for a local build so i can see what function that is.

Edit2:  Using my own build switching from MP3 to Vorbis gives 0x3067C648, which is in codec_main().  Random guess: we're not flushing something correctly when loading the codec.

Edit3:  We don't flush the icache when loading a new codec as far as I can tell.  This is a problem on ARM9 since:

Secondly the split cache introduces problems with self modifying code being first executed, then treated as data, manipulated and an attempt is then made to execute the altered code before it is flushed from the instruction cache.

Such code fragments will break.

Basically the instruction and data caches are not coherent, so I think we need to handle flushing the icache.

[saratoga]

Flushing the icache before calling codec_main fixes this problem for me.  I'll see about committing it now.

Edit:

Should be fixed in SVN.

[thund3rman]

Hello,
I own a Sansa Fuze 4GB with an SD card of 4GB also. I've been using rockbox, but now I tried to update to the latest revision and I only get a white screen on boot. Bootloader seems fine because I can boot OF and I can see the first lines in the rockbox boot process. After loading the firmware, I see two or three more lines which I can't read (they scroll too fast) and then the screen turns white.

This happens with or without the SD card. The firmware was compiled following the instructions on the website.

I can't identify the latest working revision because I didn't save a copy, but at least by the time 3.3 was released rockbox worked ok on my Fuze.

Is this a known issue? How can I debug this problem?

Thanks

[saratoga]

Its due to voltage scaling.  I get it sometimes on my Fuze.

[thund3rman]

I get it everytime... Is there a way to fix this or a release which doesn't show the problem?

[saratoga]

I get it everytime... Is there a way to fix this or a release which doesn't show the problem?

Use an old build or revert the voltage scaling patch.

[FlynDice]

Wow, that'll teach me to go away for the weekend...

For what it's worth I ran the fix that funman committed yesterday all weekend with absolutely no lockups on my e280v2.  I was waiting to see how this would hold up and, for me at least, it has been solid. I played off of my 8Gb microsd with no hiccups at all.  I see from the forum traffic and irc that this has not been the case for a lot of others though.

I cannot argue with Saratoga's recommendation to revert this for now, especially if the fix funman committed yesterday is still causing problems.  The benefit is solely longer runtime and the general useability problems it has been causing seem to outweigh the benefit right now.

[kugel.]

I cannot argue with Saratoga's recommendation to revert this for now, especially if the fix funman committed yesterday is still causing problems.  The benefit is solely longer runtime and the general useability problems it has been causing seem to outweigh the benefit right now.

Alright, then let's do it.

[jago]

For information:

Sansa e260 (r21686)

In rare cases I experience deadlocks or last time a error (flush_fat_sector() could not write sector 479 (error-101)) while I am deleting files/folders on internal SD.
After rebooting I can delete same file/folder without problems.

[epithetless]

For information:

Sansa e260 (r21686)

In rare cases I experience deadlocks or last time a error (flush_fat_sector() could not write sector 479 (error-101)) while I am deleting files/folders on internal SD.
After rebooting I can delete same file/folder without problems.

Does it still happen with a more recent build (post-r21687, when voltage scaling was disabled)?

[thund3rman]

Thanks for that, now I can use rockbox again!:D