Sansа Clip Zip - Improve battery life

[Mihail Zenkov]

Code in master branch do this. But when we switch FCLK to normal we have very low PCLK then we try set good PCLK, but sometimes we have memory corruption.
So in latest version FLCK and PCLK switching step by step. It work much better, but not totally stable.

EDIT: for AMSv2 PLCK always based on FLCK - this root of problem with switching frequency.

[oid_maps]

A maybe stupid question -- when I try to compile with patch V3 or patch V4, I get an error "‘CVDD1_BOOST’ undeclared" and "‘CVDD1_NORMAL’ undeclared" in "firmware/target/arm/as3525/system-as3525.c":

Code: [Select]

/tmp/rockbox/source/rockbox/firmware/target/arm/as3525/system-as3525.c: In function ‘set_cpu_frequency’:
/tmp/rockbox/source/rockbox/firmware/target/arm/as3525/system-as3525.c:526: error: ‘CVDD1_BOOST’ undeclared (first use in this function)
/tmp/rockbox/source/rockbox/firmware/target/arm/as3525/system-as3525.c:526: error: (Each undeclared identifier is reported only once
/tmp/rockbox/source/rockbox/firmware/target/arm/as3525/system-as3525.c:526: error: for each function it appears in.)
/tmp/rockbox/source/rockbox/firmware/target/arm/as3525/system-as3525.c:565: error: ‘CVDD1_NORMAL’ undeclared (first use in this function)
/tmp/rockbox/source/rockbox/tools/root.make:414: recipe for target '/tmp/rockbox/source/build-FuzeV2-firmware/firmware/target/arm/as3525/system-as3525.o' failed
make: *** [/tmp/rockbox/source/build-FuzeV2-firmware/firmware/target/arm/as3525/system-as3525.o] Error 1

.. Do you operate with another patch in the background?

I use the actual git checkout.

[Mihail Zenkov]

This patch for Sansa Clip Zip only. You should add CVDD1_BOOST / CVDD1_NORMAL / PVDD1_DAC / PVDD1_ADC in config for your player. Also you should fix #ifdef SANSA_CLIPZIP in patch.

[Mihail Zenkov]

Changes in V5:

• set PLLA=192mHz, disable PLLB
• set FCLK=192mHz and PCLK=96mHz at boost
• set FCLK=38.4mHz and PCLK=19.2mHz at normal
• minimize pop-click noise
• fix boot firmware though rolo
• disable mixer and connect DAC directly to output when volume -40dB or louder

WARNING: this patch may improve battery life and sound quality

Sound quality checked with RMAA and emu-0204.

Load 22 om, -6dB.

	Without patch	With patch
Dynamic range, dBA:	92.1	93.6
THD, %:	0.046	0.037
IMD, %:	0.061	0.041

No load, 0dB.

	Without patch	With patch
Dynamic range, dBA:	93.3	95.0
THD, %:	0.016	0.0037
IMD, %:	0.019	0.0065

Original firmware show same result as rockbox without patch.

[saratoga]

I'm testing this now.  One note though, with typical VBR MP3, it won't even boost (38MHz is fast enough), so to test stability I recommend either a slower format or turning on the EQ just to make sure the CPU actually changes. 

[Mihail Zenkov]

Yes, for testing stability frequency scaling better use APE - in this case CPU switch to boost and back to normal each second.

[saratoga]

http://mit.edu/mgg6/www/rockbox-clipzip.zip
http://mit.edu/mgg6/www/rockbox-clip+.zip

If anyone wants to try the above patch (I enabled it for the clip+ as well).  Tested and working on my devices, but I'm curious if they're good for everyone else.

[saratoga]

I tested battery life on some builds:

Last spring: 10h 14min
Current git: 13h 35min
Current git + 1.1v CPU (no change to other clocks): 15h 0min

Testing the frequency scaling patch on the Zip gave me 12h 45min, which is less than I would expect.  I will retest to be sure that nothing went wrong.  Have you done a battery test?

On the other hand, frequency scaling seems stable.  I put probably 36 hours on a pair of AMSv2 devices with zero crashes. 

[Mihail Zenkov]

I tested battery life on some builds:

Last spring: 10h 14min
Current git: 13h 35min
Current git + 1.1v CPU (no change to other clocks): 15h 0min

Testing the frequency scaling patch on the Zip gave me 12h 45min, which is less than I would expect.  I will retest to be sure that nothing went wrong.

Probably you force boost mode. Check frequency.

Have you done a battery test?

No. But I measure power consumption. Subjectively player work two times longer. Not sure if it have sense - in system menu I have top ruining time 23h 11m.

On the other hand, frequency scaling seems stable.  I put probably 36 hours on a pair of AMSv2 devices with zero crashes.

Good!

EDIT: Have you added cpu_boost(0) to usb-as3525.c?

[saratoga]

I started a new test, and this time confirmed after 30 minutes that the system was not stuck in a boosted state.  Will report the results in the morning.

[saratoga]

21 hours 29 minutes.

Not bad. 

[Mihail Zenkov]

You can get slightly better result by accurate tuning CVDD1. Other voltage better leave as in my last patch - it show best result with RMAA.

[saratoga]

I am slightly concerned about the lower cpu voltage when unboosted.  I think we would need to get a fair amount of people to test that before we are sure its safe.  I'm tempted to commit the frequency scaling first, and then follow up with voltage once we are sure its stable.  I tend to think theres probably a wide distribution of voltages that are safe between devices.

[saratoga]

http://pastebin.com/tTXpLSsj

Patch with cleaned up USB.

One question though, is the voltage reset in rolo.c even needed?  The header for that function isn't included, so I'm not even sure if its linked. 

[Mihail Zenkov]

I am slightly concerned about the lower cpu voltage when unboosted.  I think we would need to get a fair amount of people to test that before we are sure its safe.  I'm tempted to commit the frequency scaling first, and then follow up with voltage once we are sure its stable.  I tend to think theres probably a wide distribution of voltages that are safe between devices.

Yes, you right. I mean for you personal record My two devices can stable work on slightly less voltages.

One question though, is the voltage reset in rolo.c even needed?  The header for that function isn't included, so I'm not even sure if its linked.

Yes, it linked and work. I just was lazy fix warning. Without it player freeze on booting another firmware though rolo. Also I think better disable frequency scaling if we build bootloader.


In my researches I see two strange behavior:
1. playing wav (16/44.1) consume  mostly same power as low bitrate mp3 - is it expected?
2. in test_mem I have read speed much lower than write speed - is it normal?