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

[tofmin]

When I turn on "cuesheet support" I can't skip to next/prev track. Player hangs in database (sometimes) and I've got randomly "dark blue screens" (in Settings, Database or just after turning on).

If cuesheet support is off, then next/prev buttons works again but player still hangs sometimes with "blue screen" on the LCD and when I use some applications (ie: fire, fft)

Hmm, I remember 25508 coz this was first build which I installed on my player (and tested him almost two days) after apply "backlight patch" for the c200:
http://svn.rockbox.org/viewvc.cgi?view=rev&revision=25499


Sorry 4 bad english. Again. And thx for great job U done!

[funman]

1. When loading a new build of rockbox,  a couple of time I find that the very first time i play a song I just get white noise from the player. After that first play it is fine and great every time after. Even after a reboot. Just testing this appear to be a reproducible by koading the OF playing a sound switching it off and then back to rockbox the first song you play or even speech kill the player and give this white noise effect.

Can't reproduce on my side

2. If the database is not refreshed in the OF and i force it to shutdown then rockbox takes an age to boot. After a full refresh we have normal boot times for rockbox.

It could be because the filesystem is damaged

3. Rockbox seems to run for much longer than the OF is that because the low battery level has not been set and is there the potential to damage the battery but draining it too much? Might it be good to warn users of this?

Rockbox will shutdown when the battery is empty so there is no risk, it runs much longer because we're better at codecs than the OF!

[Xanikseo]

Another thing I've noticed on the Fuzev2 (using current build): When skipping tracks, the song mentioned after "Next track:" is the current one playing, it doesn't tell you what the next song will be. You have to leave the now playing screen and return to it to see the next song. Skipping tracks happens to cause the wheel light to flicker on and off annoyingly for about a second as well.

I've found that fiddling with the EQ settings also often causes the Fuze to freeze, needing a hard reset.

[funman]

Just to let you know Clipv2 and Clip+ were promoted down to the "'Unusable" category.

That means there's pretty much no point into using them if you're not developing patches for them.

[Xanikseo]

Got more evidence that the amount of work the cpu is doing has an effect on distortions and flickering in the lcd (like when scrolling fast while listening to music).

If you boost the cpu frequency in the debug menu, the screen starts flickering, even without any music playing. I'm not going to pretend that I know what I'm talking about , but could this be a sign of the refresh rate of the lcd and the cpu frequency being out of sync or something?

[ranma]

When I turn on "cuesheet support" I can't skip to next/prev track. Player hangs in database (sometimes)

Hmm, indeed. Never tried cuesheet support before, maybe its an issue with the limited ram size?

and I've got randomly "dark blue screens" (in Settings, Database or just after turning on).

That's a known problem, sometimes the LCD controller gets reset or something... Maybe due to the DBOP noise problem seen on key reads.

If cuesheet support is off, then next/prev buttons works again but player still hangs sometimes with "blue screen" on the LCD and when I use some applications (ie: fire, fft)

Hmm, I remember 25508 coz this was first build which I installed on my player (and tested him almost two days) after apply "backlight patch" for the c200:
http://svn.rockbox.org/viewvc.cgi?view=rev&revision=25499

Sorry 4 bad english. Again. And thx for great job U done!

I tried "cuesheet support" with r25499 and it doesn't work there either, so it's not a regression.
Please remember that C200v2 support is still unstable, and some things might also just be a bit difficult to get to work because of the small amount of RAM (2MB) this hardware has (e.g. recording).

[saratoga]

If cuesheet support tries to allocate more memory then we can afford, we should probably disable it.

[ranma]

If cuesheet support tries to allocate more memory then we can afford, we should probably disable it.

It's allocating ~72KB at least (struct cuesheet is freaking big), so that really might be the reason...
99 (MAX_TRACKS) struct cue_track_info are (((80*3+1)*3+4)*99) => 71973 Bytes

Let's see. With cuesheet enabled:

pcm: 0/176400
alloc: 0/91552
usefl: 0/91552

Without cuesheet:

pcm: 0/176400
alloc: 0/164624
usefl: 0/164624

So it's 73072 Bytes and practically half of the memory still 'available'.

[edit]
Verifying it's a memory issue:
For the most part the pcm buffer still seems to be larger than necessary, so I halved it, trading it in for 88200 additional Bytes of alloc/usefl.
Now with cuesheet enabled:

pcm: 0/88200
alloc: 0/179480
usefl: 0/179480

And skipping to next/previous track works _most_ of the time.
Sometimes it still stops playing though, with pcm and alloc/usefl fully filled.
[/edit]

[edit2]
BTW, compiling with '-Os' gives me about 32KB more available memory than the default '-O', maybe that should be made default in configure as with some other archs (e.g. sh, m68k)
[/edit2]

[edit3]
When it stops playing and just sits there with filled buffer not doing anything, it seems to be sitting in codec_pcmbuf_insert_callback in

Code: [Select]

186        while ((dest = pcmbuf_request_buffer(&out_count)) == NULL)
187        {
188            cancel_cpu_boost();
189            sleep(1);    <---- sleeping here
190            if (ci.seek_time || ci.new_track || ci.stop_codec)
191                return;
192        }

Debugger:

Code: [Select]

(gdb) target remote localhost:3333
Remote debugging using localhost:3333
[...]
(gdb) bt
#0  switch_thread ()
    at /home/ranma/src/rockbox-c240v2/firmware/target/arm/system-arm.h:242
#1  0x3003002c in codec_pcmbuf_insert_callback (ch1=<value optimized out>, 
    ch2=<value optimized out>, count=47)
    at /home/ranma/src/rockbox-c240v2/apps/codec_thread.c:189
#2  0x30208684 in tree_gui_init ()
    at /home/ranma/src/rockbox-c240v2/apps/tree.c:301
#3  0x00000450 in ?? ()
#4  0x00000450 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) frame 1
#1  0x3003002c in codec_pcmbuf_insert_callback (ch1=<value optimized out>, 
    ch2=<value optimized out>, count=47)
    at /home/ranma/src/rockbox-c240v2/apps/codec_thread.c:189
189                 sleep(1);
(gdb) print dest
$1 = 0x0
(gdb) print out_count
$2 = 47
(gdb)

[/edit3]

[edit4]
The problem seems to be that the pcm buffer is completely filled according to one metric (pcm: 88200/88200 in buffering thread debug, pcmbuf_request_buffer returns NULL) and completely empty according to another (pcmbuf_unplayed_bytes is 0, pcmbuffer_fillpos is 0).
[/edit4]

[edit5]
Ok, I think the problem here was just that with a reduced pcm buffer size
the PCMBUF_TARGET_CHUNK and PCMBUF_MINAVG_CHUNK defaults are too big.
With those two reduced to 8192 and 6144 it seems to run pretty well even with a pcm buffer of just 44100 Bytes.   With a pcm buffer that small I do hear occasional short buffer underruns though.

And the hang with unreduced pcm buffer size and cuesheet support enabled is a different kind of hang than what I was seeing here.

BTW, I compared the target configs for the different Sansa 2MB targets and
c200v2 has the biggest PLUGIN_BUFFER_SIZE define of them all.
By reducing it from 0x60000 to 0x45000 like in sansaclip.h or sansam200v4.h
we'd gain enough memory (110592 Bytes) to make cuesheet support work I think.
[/edit5]

[funman]

Perhaps we should disable the few plugins which use a lot of memory

[Timar]

Hi,

as I've posted here: http://www.anythingbutipod.com/forum/showpost.php?p=463457&postcount=186 I get playback crashes with all recent rockbox builds on my Clip+. Today I've tried the new 25676. While it crashes as usual it now displays a debug message (reproducable). I thought I'd post it here for it may be usefull for bugfixing:

Code: [Select]

Data abort at 30057FC4
FSR 0x8 (domain 0, fault 8)
address 0xFFFFFFFF

[funman]

unsurprisingly the error is in set_cpu_frequency() which is known to be buggy.

If you force the CPU to always be at maximum (in debug menu -> cpu frequency; set the counter to 1 or more), it shouldn't happen anymore.

[Timar]

Great, that solved the problem... thanks! So I guess the older builds run stable because they don't have that feature?

Is there any way to save that setting into a cfg file to default it on startup?

[funman]

Is there any way to save that setting into a cfg file to default it on startup?

No.

[ranma]

Did some power draw measurements on my C200v2 today:


OF:

Playing mp3, display off:
3.85V,  28mA

Playing mp3, display full brightness, buttonlights on:
3.80V,  68mA

rockbox:

Not playing, settings menu, display full brightness, main buttonlight on:
3.79V,  64mA (Not 68mA because 'menu' light is off I suppose)

Not playing, settings menu, display full brightness, main buttonlight off:
3.81V,  51mA

Not playing, settings menu, display off, buttonlights off:
3.84V,  34mA

Playing mp3, now playing screen, display full brightness, main buttonlight on:
3.76V,  78mA

Playing mp3, now playing screen, display full brightness, main buttonlight off:
3.78V,  65mA

Playing mp3, now playing screen, display off, main buttonlight off:
3.81V,  48mA

[edit]
At funmans suggestion I did a readout of the ascodec state on
both original firmware and rockbox:

Code: [Select]

--- originalfirmware.ascodec.readout.txt	2010-04-21 23:00:48.868252431 +0900
+++ rockbox.ascodec.readout.txt	2010-04-21 23:00:37.391522447 +0900
@@ -1,9 +1,9 @@
 0x00: 00000000
 0x01: 00000000
-0x02: 00000003
-0x03: 00000043
+0x02: 000000c5
+0x03: 00000045
 0x04: 00000000
-0x05: 00000000
+0x05: 00000080
 0x06: 00000000
 0x07: 00000000
 0x08: 00000000
@@ -12,15 +12,15 @@
 0x0b: 00000000
 0x0c: 00000000
 0x0d: 00000000
-0x0e: 00000019
-0x0f: 00000059
+0x0e: 00000016
+0x0f: 00000056
 0x10: 00000000
 0x11: 00000000
 0x12: 00000000
 0x13: 00000000
 0x14: 00000060
-0x15: 0000003f
-0x16: 00000006
+0x15: 00000007
+0x16: 00000000
 0x17: 00000000
 0x18: 00000000
 0x19: 00000000
@@ -30,22 +30,22 @@
 0x1d: 00000000
 0x1e: 00000000
 0x1f: 00000000
-0x20: 00000031
-0x21: 00000016
-0x22: 0000005c
-0x23: 0000000b
+0x20: 00000039
+0x21: 00000004
+0x22: 00000081
+0x23: 00000000
 0x24: 00000000
 0x25: 00000000
 0x26: 00000010
-0x27: 00000001
-0x28: 000000f3
+0x27: 00000030
+0x28: 00000023
 0x29: 00000040
-0x2a: 000000b7
-0x2b: 00000043
+0x2a: 00000092
+0x2b: 00000042
 0x2c: 0000008b
 0x2d: 00000035
 0x2e: 00000002
-0x2f: 000000f5
+0x2f: 000000f7
 0x30: 00000000
 0x31: 00000000
 0x32: 00000000

Main differences are as follows, I'd guess at most the bias current and load setting changes would make a difference in power draw:

0x02: (HPH_OUT_R)
OF: 0x03: [edit]Overcurrent timeout 256ms[/edit]
RB: 0xc5: 'Do not change, default 0' bit is set to 1[edit]Overcurrent timeout 0ms[/edit]

0x05: (SPH_OUT_L)
OF: 0x00: output normal
RB: 0x80: output muted (power up default)

0x15: (AudioSet_2)
OF: 0x3f: Bias current reduction 50%, AGC disabled
RB: 0x07: No bias current reduction, AGC enabled

0x16: (AudioSet_3)
OF: 0x06: 32 Ohm load or more, cm buffer on, zero cross update disabled
RB: 0x00: 16 Ohm load, cm buffer on, zero cross update enabled

0x20: (System)
OF: 0x31: PVdd unreduced
RB: 0x39: PVdd Vnom*17/18

0x21: (DCDC3)
OF: 0x16: BVDD 3.1V CVDD 1.1V
RB: 0x04: BVDD 3.6V CVDD 1.2V (probably halted it in boost mode?)

0x22: (Charger) [Was not plugged in in both cases, running on battery]
OF: 0x5c: NTC supply on, 100mA, 4.2V, charger enabled
RB: 0x81: NTC supply off, charger disabled

0x23: (DCD15)
OF: 0x0b: 13.75mA [Well, this regulator should be unused, maybe dead code in OF?]
RB: 0x00: off

0x28: (RTCV)
OF: 0xF3: Supply 2.5V
RB: 0x23: Supply 1.2V

[/edit]

[edit2]
I just noticed that the rockbox current draw values might be completely off,
I measured them with a local patch that may have caused BVDD to stay
on the boost value...

No, for one thing it's CVDD, the BVDD 3.6V thing shouldn't really come into play until the battery is nearly empty.
And the voltage scaling code does not get compiled in AFAICS, so it just stays at 1.2V CVDD.

Still the additional current due to higher CVDD shouldn't be too big, I'd expect about 20% increase (1.2^2/1.1^2).
The difference I measured here is more like 70%...
[/edit2]

[funman]

Thanks!

I'll try a bench with modified audioset2 and audioset3 to see if it changes anything. no change

You have dumped CGU registers already, now the only difference I can think of is in GPIO registers ? Can you dump and GPIO_DIR (+0x400) and GPIO_DATA (+0x0) ?

This could give a clue at how c200v2 power is drawn if some PIN is set, but hopefully we could identify the code using it in the OF and compare with other models.




Oh well I remember some code which put SDRAM in self-refresh mode, and most of the audio codecs are loaded in IRAM, so the SDRAM could be disabled (I don't know if this can account for high power usage)

The datasheet for the SDRAM chip (linked from wiki SansaC200v2) has current values page 4, but i'm not sure which one apply (I suppose the correct value is weighted from all of them)

In OF, 0x301C enters self refresh mode (next function leaves the mode), parent 0x1CD8 is called multiple times (I have not identified callers though)

In your post I see that external memory clocks are enabled when playing mp3, perhaps it's enabled/disabled at some high frequency?