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

[psychowood]

Sandisk has just released the first firmware update for the Clip+.

This does mean that we've got da bootloada, don't we? 

[FlynDice]

I have disabled voltage scaling with r24217.  The code is still in place but I've #ifdef'd it with HAVE_ADJUSTABLE_CPU_VOLTAGE. If you want to continue using it just define that at some point and it should include the code.

If you are one of the folks that have been having uSD card issues would you please let us know if this takes care of your issues.

Thanks!

[funman]

This does mean that we've got da bootloada, don't we? 

No, that just means work can began on Clip+, so don't expect da bootloada anytime soon.

The file format is identical to other Sansa AMS, with only a new ID for Clip+ (0x28)

With a very quick look, the firmware looks like Clipv2, so Clip+ owners should look if the buttons known on Clipv2 are also present on Clip+

Don't hesitate to ask for help though, as before this step is done you can very easily brick your devices.

[JdGordon]

funman: I've got a clip+ in peices, can you kick me in the right direction to get things going? or alternatively do you want it?

hehehehe.... I've got a modified bootloader on my clip+...

edit2: no i dont :p i have a very light brick

[funman]

So current code in SVN works, but enabling the same USB check than Clipv1 & v2 bricked JdGordon's Clip+

The OF might rely on a specific value of GPIOA_DIR, so be sure to restore all the registers you modify.

EDIT: You could check buttons by trying this (don't forget to save & restore the registers you modify!):

• set GPIOB pin0 to 1, wait a bit (OF use i=0; while(i < 500)
• read GPIOA pins 1, 6, 7
• read GPIOC pins 1, 2, 3, 4, 5

I think they are all the 8 buttons but power and hold

The LCD is accessed using SSP, unlike all other models which use DBOP

[OldOne]

Re:Voltage Scaling

Just some brief tests.  Yes my problem PQI 8gb cards work fine with voltage scaling disabled.
My A-Data card was corrupted when recording to it with voltage scaling enabled.  Otherwise it worked perfectly at 1.10.  I will run a battery bench both ways to get an idea of how it affects battery life and post the results.

[FlynDice]

@funman:

Could you give a quick update the status for the clipv2.  If I've pieced things together correctly you've got it booting with an operating display and the sd storage makes it past the initialization stage,  but you don't know how to initiate a transfer yet.  How am I doing so far?

[funman]

FlynDice, you got it right.

Also all the buttons are working, it can help while debugging (like printing some message and waiting a button press before continuing execution).

Unhelpful reportedly had some problems with initialization but it sometimes worked, so this problem can be left for later.

sd-as3525v2.c has all the info I found so far, continue the reverse engineering is left as an exercise to the reader

[FlynDice]

Clip+ 2Gig on the way.

Willing to risk bricking 1 unit for the project......



EDIT:
@funman:

Looking at the diff you gave me for dualboot.s and trying to understand the process.  We're reading and testing pin A1.  So I get the dualboot bootloader installed and then I turn the player on and hold a button.  If It boots with a delay we've found a match, if there is no delay we shutdown and start again with a different button.  Is this the general idea?

[funman]

Looking at the diff you gave me for dualboot.s and trying to understand the process.  We're reading and testing pin A1.  So I get the dualboot bootloader installed and then I turn the player on and hold a button.  If It boots with a delay we've found a match, if there is no delay we shutdown and start again with a different button.  Is this the general idea?

Right, although we don't know if holding one particular button will set or clear A1.

First thing I would do is use unmodified dualboot.S (mkamsboot won't work out of the box, i'll let you figure why).

If it produces a brick we'll know there is something seriously wrong.

Then boot without pressing any button, then pressing one button, then pressing another one.

Just look at the delay presence in the majority of the boots and you'll know the default state.

Then boot pressing all buttons one by one and check if the default state change.


Note: looking at my previous post, it mentions setting GPIOB pin 1 and waiting a hair, I'm not sure if i've put that in the diff I sent you.

Writing a pin is more difficult, I'm not sure if you can know the previous value to restore it after your code has run. (Sounds a bit paranoiac if this pin is changed by button code in OF, but you never know..)

[FlynDice]

I'm assuming I can just use a clipv2 bootloader build for this right?

[funman]

Any binary will fit as long as you run scramble -add=cli+ on it, else mkamsboot will refuse it.

You can select sansaclipplus in configure but i'm not sure if the bootloader builds.

[FlynDice]

@funman:

I've got a patched firmware with unmodified dualboot.s ready to go.     scramble -add=cli+ did the trick.  As far as the modified dualboot.s goes the diff you gave me does not set the GPIOB pin, is that something I need to add now or would that be the next step?

[funman]

Not sure if it's needed, testing will tell!

[funman]

I just ran battery bench on my Fuze to calculate proper current drawing from the battery (it would be nice to have normal battery life estimation in the 3.5 release)

Runtime: 8h40

The first message of battery_bench tells the battery level was 91%, the second one 92%, so it was not completely full. I believe I had waited until the OF stops displaying the charging icon before running the test, I will check for the next bench.

Correcting with the battery level, 8h40 / 92 * 100 = 9h25


I think it's weird because the benchmark ran 2 months ago on SansaRuntime shows almost 12h


If there are a lot of differences between different Fuzev1, I'm not sure which values we should use for battery life estimation.


Here is my config.cfg:

Code: [Select]

volume: -8
repeat: all
selector type: pointer
idle poweroff: 5
brightness: 7
show files: all
rec format: mpa3
tagcache_autoupdate: on
fmr: /.rockbox/fmpresets/dijon.fmr
font: /.rockbox/fonts/13-Nimbus.fnt
wps: /.rockbox/wps/star.wps
lang: /.rockbox/langs/francais.lng
backdrop: /.rockbox/backdrops/andreo.bmp
button light timeout: 3

brightness and button light timeout shouldn't affect the bench because I only looked 2 or 3 times to see if the Fuze was off.

Could volume affect the benchmark if there are no headphones plugged in ?

EDIT: played mp3 44.1kHz joint stereo at 128kbps