Rockbox Development > New Ports
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: ---Data abort at 30026264
FSR 0x8 (domain 0, fault 8)
address 0xB48AD288
--- End code ---
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:
--- Quote from: Timar on April 24, 2010, 02:14:42 PM ---
--- Code: ---Data abort at 3002624
--- End code ---
--- End quote ---
You wrote 7 digits but the correct number has 8, can you post the exact number, and the revision you were using ?
--- Quote from: Xanikseo on April 24, 2010, 03:30:48 PM ---What could be going on?
--- End quote ---
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:
--- Quote from: funman on April 21, 2010, 02:28:08 PM ---Thanks!
I'll try a bench with modified audioset2 and audioset3 to see if it changes anything. no change
--- End quote ---
I did some tests myself with the multimeter and did find some power savings with those bits set:
--- Code: ---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
--- End code ---
--- Quote ---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) ?
--- End quote ---
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: ---0xc80b0400: 000000b3
0xc80c0400: 00000070
0xc80d0400: 00000000
0xc80e0400: 00000080
--- End code ---
GPIOA: Backlight, main buttonlight, three unknowns...
GPIOB: FM sda/scl and display reset line
GPIOD: Menu button light
--- Quote ---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)
--- End quote ---
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]
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version