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

[Timar]

While with boosted CPU, playback is much more stable, sometimes the Clip still crashes showing the following debug message

Code: [Select]

Data abort at 30026264
FSR 0x8 (domain 0, fault 8)
address 0xB48AD288

[Xanikseo]

As it seems the weird flickering issue on the fuzev2 happens when the frequency is boosted - you can see this by boosting the FCLK manually in the debug menu: distortions, flickering and shifting start immediately, even when not doing anything - and as I'm not a developer, I just decided to simply play around with the CPU frequency for the Fuzev2 by changing AS3525_DRAM_FREQ in clock-target.h and see what happens.

So I decided to change the initial dram frequency back to the old 60MHz, and noticed the distortions were taking up less of the screen, and were not so annoying. Then I increased the initial dram frequency again to 80MHz, and lo and behold the problem is noticeably better. No distortions at all when switching tracks, no weird shifting on the screen etc. I then decided to boost the FCLK frequency from the debug menu, and even though FCLK should be at the same frequency as when DRAM was 40MHz, or 60MHz for that matter, distortions were much much less annoying and less frequent.

I've come to the conclusion that this LCD problem is specifically down to the ratio between the DRAM frequency - or at least one of the frequencies dependant on DRAM frequency - and the FCLK frequency. 40MHz is 6x less than 240MHz, 60MHz is 4x less, and 80 is of course 3x less, and the lcd is much much better.

What could be going on?

EDIT: Just discovered that the fire plugin is great way of both introducing lcd problems and seeing them very clearly. 80MHz still causes flickering/distorting a little, 160MHz was again less. I'm pretty certain there's a link between the ratio of DRAM to FCLK and the lcd problem.

I have a funny feeling it's due to the infamous set_cpu_frequency(), perhaps increasing the delay will help, as there seems to be less problems the closer the dram frequency to fclk?

[funman]

Code: [Select]

Data abort at 3002624

You wrote 7 digits but the correct number has 8, can you post the exact number, and the revision you were using ?

What could be going on?

Probably a race condition between LCD code and button code, like what happened on Fuzev1 and e200v2.

[kugel.]

It's pretty clear that the current delays needed for switching to "button mode" (by setting the undocumented CGU_IO bit 12) are not high enough to work in boosted mode.

[ranma]

Thanks!

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

I did some tests myself with the multimeter and did find some power savings with those bits set:

Code: [Select]

Setting   Draw
[Idle]
0         35mA
1         35mA
2         35mA
3         35mA
4         32mA
5         32mA
6         32mA
7         32mA

[Playing]
0         50mA
1         48mA
2         46mA
3         45mA
4         46mA
5         46mA
6         43mA
7         42mA

[pcmbuf in iram, Playing]
0         48mA
1         47mA
2         45mA
3         44mA
4         45mA
5         44mA
6         42mA
7         41mA

0: No power saving options
1: AS3514_AUDIOSET3 0x06
2: AS3514_AUDIOSET2 AUDIOSET2_IBR_DAC_50
4: CVDD_1_10

OF
Idle      26mA
Playing   28mA

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) ?

Well, dumping the data register doesn't seem to work with the processor stopped, apparently it always reads back as 0. Here are the gpio directions,
it's setting a few additional gpios as output.

Code: [Select]

0xc80b0400: 000000b3 
0xc80c0400: 00000070 
0xc80d0400: 00000000 
0xc80e0400: 00000080 

GPIOA: Backlight, main buttonlight, three unknowns...
GPIOB: FM sda/scl and display reset line
GPIOD: Menu button light

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)

I put hw breakpoints on both and only 0x1cd8 triggers
[edit]
(triggers while playing mp3, didn't check other use cases)

I tried changing the GPIOA settings in rockbox to match OF, but didn't see any differences in power draw regardless of whether setting the additional output bits to 0 or to 1.
[/edit]

[saratoga]

When does 0x1cd8 trigger?  During playback or some other time?

[Timar]

You wrote 7 digits but the correct number has 8, can you post the exact number, and the revision you were using ?

I've updated the OP (it took a while to reproduce, it's at 30026264). The crash occurs on track change/skip only.

EDIT: Revision was r25705

[cris]

This is my first post.

Can I first say kudos to all of you who are working on getting a rockbox build working for the Fuze v2. I have for the first time tried the build (and rockbox) on my Fuze 2 and see great potential.  I used the daily build from yesterday (25 April) and a pre-patched firmware .31 version from one of the developers here which was posted on the Sansa forum.  It worked!

Of course there are lots of bugs but no complaints.  Here are some I wanted to report:

1) Volume - the volume will often lock and then it cannot be changed with the scroll wheel or the menu (sometimes the menu will work.
2) Screen flicker - noted already
3) Cue files do not work yet
4) Crashes when flicking through EQ presets (not always)
5) Crashes always when you scroll through some of the higher (or minus that should be) DB values for precut - mine crashes always when scrolling around -4.5/5 DB
6) the Volume seems uncomfortably loud on my in-ear headphones but perfect for my full size headphones.  Is this normal (tried the precut but it crashes)
7) Will sound quality improve in later builds?  It is good but it lacks, what to me is the full bodied sound of the current .31 firmware of the Sansa when listening to flac files.  I am a believer in not using EQ as my headphones sound great with no EQ on the sansa and the fuze sounds excellent through my stereo amp with no EQ so I am thinking of sound quality "out of the box" (of course with the wonderful features of crossfeed and dithering!!! - brilliant)
To get round the non-saving issue for settings, I wrote a fixed.cfg file (note the manual has a value of 60 for volume!!!! I think this needs to be -60 to stop your brains being blown out ;-).  In the fixed cfg file I can't seem to successfully be able to set Crossfeed or Dithering but setting volume, bass and treble works fine (as does setting a new theme, which is great because I don't have to change the theme on every boot ;-) due to lack of writing support).


Once again, a big thank you.  I will donate something to the fund in due course.
Happy also to test daily builds and feed back.

Cris

[funman]

It's pretty clear that the current delays needed for switching to "button mode" (by setting the undocumented CGU_IO bit 12) are not high enough to work in boosted mode.

I added ridiculously long delays after switching CCU_IO in button-fuzev2.c without any visible effect on screen.

EDIT: a delay *before* any operation at the start of the function fixes the glitches
EDIT2: fixed in svn

[funman]

I have something regarding the volume on Fuzev2 (the fact that you can't decrease it below -39dB). I read on the sansa forums a while ago about DIY "line out". They have figured out a pin configuration for what people think might be line-out, except you can actually decrease the volume, but not by very much. This sounds like our problem here. Perhaps we are experiencing this, and are actually using the wrong pins (sorry, don't know if that's the right technical word ) for audio, ie (some sort of) line-out instead of headphone out?

Found it: http://forums.sandisk.com/sansa/board/message?board.id=sansafuse&thread.id=7792&view=by_date_ascending&page=1

cris' post triggered this thought, since he was saying that the audio had a different feel to it. I figured using rockbox to decode flacs shouldn't really affect audio quality.

From the forum thread:

The volume needs to be at about 50% or greater (doesn't really increase much from that point on)

This is different from rockbox:

On rockbox, the real volume is completely unaffected by settings the low 50% of the volume range, but still can go quite high.

With the line out cable, the real volume is affected (although only a bit) by the up 50% of the volume range.

I didn't read the whole thread as I'm not sure if it's related to the volume problem.

EDIT: fixed in r25732

By the way AMS didn't answer to my request of the as3543 datasheet



About the sound quality I'm completely unconvinced, it sounds perfectly fine to me, although I'm admittedly not an audiophile at all.

I will trust you only if you can back your claim of different sound quality with computer-made analysis of the output (with lossless source and good analogue recording equipment I think)

[LucaLeonardo.Scorcia]

FuzeV2: I can confirm no more flickering with the latest SVN. Locks up when changing EQ settings, sometimes (unfrequent) while playing unboosted. Today I had five lockups and two panics: Undefined instruction at 3005F740, Undefined instruction at 3005F760.

[Xanikseo]

Wow, volume really works , another good job funman . I don't know if this is intentional, but -74dB doesn't mute the sound, should it?

I'm finding now that during playback (q8 oggs), I get a lot of skipping, it just sounds a bit dodgy now...

I got a crash while switching tracks (not sure if it's related):

Code: [Select]

Prefetch abort
at A742D41C
FSR 0x1
(domain 0, fault 1)

EDIT: Getting a lot of crashes without error reports during playback. Can barely play a few songs before a crash...

[funman]

However, I'm finding now that during playback (q8 oggs), I get a lot of skipping, it just sounds a bit dodgy now...

I can reproduce it too, investigating...

EDIT: fixed in r25740

I got a crash while switching tracks (not sure if it's related):

Code: [Select]

Prefetch abort
at A742D41C
FSR 0x1
(domain 0, fault 1)

EDIT: Getting a lot of crashes without error reports during playback. Can barely play a few songs before a crash...

Make sure you boosted the CPU before reporting crashes (read last pages of this thread)

[Xanikseo]

Great, sounds much better!

Also, I've noticed that using the hold switch now takes a while to take effect. Sometimes it takes more than 2 seconds for rockbox to detect it, sometimes not at all! I haven't noticed this before.

EDIT: And another thing (god this german oral practice really makes me procrastinate), if you scroll through a long playlist quickly, you can sometimes suddenly jump straight to the end, which can't be right (the playlist I am using is ~500 tracks).

But I have noticed that the button light doesn't flash annoyingly between switching tracks anymore, which is good .

[funman]

Also, I've noticed that using the hold switch now takes a while to take effect.

Fixed

if you scroll through a long playlist quickly, you can sometimes suddenly jump straight to the end

Probably caused by r25736/FS#11172 : i'll let kugel comment on this