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

[Joe Blow]

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 found my scroll wheel accuracy decreased.

Running rev 22864, Sansa E280 v2

I didn't spend a lot of time playing with it, but I noticed it just didn't feel right.

[kugel.]

I think it's more fluently for fast scrolling, but it's possible that I didn't think enough about slow scrolling. I'll have a look.

May I remember you again? This thread is not a support channel. It's for development. Please stop flooding the thread with questions (and answers...) about installing and sort of.

[epithetless]

I think it's more fluently for fast scrolling, but it's possible that I didn't think enough about slow scrolling. I'll have a look.

Thanks.

May I remember you again? This thread is not a support channel. It's for development. Please stop flooding the thread with questions (and answers...) about installing and sort of.

If that includes my posts about my experiences with LCD glitches and scrolling accuracy, I apologize. I thought they were sufficiently "development-oriented." If not, where -- now that the "Official Test Builds" thread has been closed -- is the appropriate place to raise and discuss issues like that?

[mc2739]

where -- now that the "Official Test Builds" thread has been closed -- is the appropriate place to raise and discuss issues like that?

Any issues with the Fuze and e200v2 should be reported on the Flyspray tracker.

Issues with any other of the AMS models (clip, c200v2, etc) should be reported in this thread only if it has not been previously discussed.  There is no benefit in posting additional reports on issues that the developers already know about, unless there is information that could be useful in correcting those issues.

[epithetless]

where -- now that the "Official Test Builds" thread has been closed -- is the appropriate place to raise and discuss issues like that?

Any issues with the Fuze and e200v2 should be reported on the Flyspray tracker.

Issues with any other of the AMS models (clip, c200v2, etc) should be reported in this thread only if it has not been previously discussed.  There is no benefit in posting additional reports on issues that the developers already know about, unless there is information that could be useful in correcting those issues.

Understood. Thanks.

[funman]

I used a bit my Fuze with the class 6 Transcend SDHC without problems.

Do any of you have a problem to report about storage with a current build ?

The release candidates builds of mkamsboot had no bug report so they work fine, the code changed a bit since then but there were no functional changes so we can rebuild it and label it 1.1 final.

I will have a look again at recording (fs#10371)

There are some patches floating around where you could help:

• fixing playback on clipv1/m200v4/c200v2 which is being worked on by saratoga
• factorizing DBOP access for LCD/buttons reading, which needs some work on Fuze (hold button doesn't work anymore)

One more thing is needed for Fuzev1/e200v2 : finish the manual (AlexP started working on it, I'm not sure if there he opened a patch on the tracker yet)

My opinion is that once the manual is finished we can label Fuzev1 and e200v2 as stable.

[HankB]

Any issues with the Fuze and e200v2 should be reported on the Flyspray tracker.

Where can I find guidelines for doing this in a manner that will be most useful to the devs?

I just decided that I would be more helpful if I kept a recent release loaded on my Fuze and reported any difficulties I encounter rather than try to find the most stable one and let others test the bleeding edge.

I just loaded r22777-090921 and believe I provoked a deadlock by inserting a microSD card and going to Rockbox -> Files. The player became unresponsive to further input except to bring the screen back after it turned off. I was able to power down after holding the power slider to "off" an extended time.

I just checked the bug tracker and searching for Fuze, only found one entry.

Thanks again for all of the effort you folks put into this.

best,
hank

Edit: found guidelines at http://www.rockbox.org/wiki/FlySprayHowto

But I am unable to reproduce the problem. 

[funman]

I just loaded r22777-090921

You shouldn't report any issues with an outdated build, always use the current build (available from the left menu on the website)

[kugel.]

I posted a patch to http://www.rockbox.org/tracker/task/10667. tell me if it improves things please (most importantly on the e200v2).

[FlynDice]

I just posted FS#10669 to try to implement voltage scaling once again.  I made the assumption that the problem remaining with the previous implementation was a microsd card issue but I would also be  interested how it performs on the clip as there were some bug reports on that last time.  I have purposely set the reduced voltage on the low side to coax the bugs out if they are there...    Feedback on Flyspray appreciated!

[daniel_at]

Hello,

just short notice:

I d/l the latest fuzeV1 ( http://forums.sandisk.com/sansa/board/message?board.id=sansafuse&thread.id=33874 )  original firmware, and found that the SVN-mkamsboot does not know this version (1.2.28). I tried it, patching, booting (OF and RB) works. On a 8GB, Fuze V1.

Code: [Select]

Index: mkamsboot.c
===================================================================
--- mkamsboot.c (Revision 23063)
+++ mkamsboot.c (Arbeitskopie)
@@ -196,6 +196,7 @@
     { MODEL_FUZE,   "1.01.15", "df0e2c1612727f722c19a3c764cff7f2" },
     { MODEL_FUZE,   "1.01.22", "5aff5486fe8dd64239cc71eac470af98" },
     { MODEL_FUZE,   "1.02.26", "7c632c479461c48c8833baed74eb5e4f" },
+    { MODEL_FUZE,   "1.02.28", "5b34260f6470e75f702a9c6825471752" },

     { MODEL_C200V2, "3.02.05", "b6378ebd720b0ade3fad4dc7ab61c1a5" },

Daniel

[funman]

thanks for testing daniel, it's r23067 (one day too late for mkamsboot 1.1 though)

[yelped]

What's wrong with the mp3encoder included with Rockbox? It outputs a lot shorter files with squeaky voices. Does this happen on all targets, or only on the Fuze? If so, why?

Thanks a lot for the great work.

[FlynDice]

@funman

re ata_sd_as3525.c:   Tell me if I'm understanding correctly

line 130  #define UNALIGNED_NUM_SECTORS 10

738        if(transfer > UNALIGNED_NUM_SECTORS)
739            transfer = UNALIGNED_NUM_SECTORS;
740        if(write)
741            memcpy(uncached_buffer, buf, transfer * SECTOR_SIZE);

It seems we are using transfers of at most 10 sectors(1280 Byes), memcpy to uncached buffer, then dma uncached buffer to MCIFIFO(drive).  I assume this is so the dma can use an uncached, aligned buffer.
I hope this is a silly question ,  if we're going to end up memcopying the whole thing to the buffer anyway, why don't we just memcopy to the FIFO in the first place...?

[funman]

Good point.

We also do a memcpy from MCIFIFO when reading to use an aligned & uncache buffer to be sure the data cache in synchronized with memory (no data in the cache).

Ideally we would only use aligned buffers and sizes multiple of 32 (cache size) and use cache invalidating functions but we would need to check all calls to storage_(read/write)_sectors. You could keep an eye on FS#9708 because I think that's exactly what they are doing.

When we were not using DMA but direct copy from/to the FIFO in the isr we sometimes had problems where we wouldn't be fast enough to fill/empty the FIFO and transfer would fail. Now perhaps the situation changed since the icache is enabled.

I think we should wait until DMA is enabled on PP and remove the memcpy, I just assume DMA is faster than a FIFO copy in the isr. Of course feel free to make benchmarks