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

[saratoga]

It may just be differences in battery capacity.  You could test the OF to be sure (record the OF via line in on your PC and see how long it takes the wav to go silent). 

[FlynDice]

I got 9:48 on my e280v2 with r24382

No clip+ today, hoping for Monday now.

[funman]

In fact it seems my battery won't go past 91%, running bench with backlight always on

[mc2739]

@funman

Normal battery bench results posted on SansaRuntime

Battery bench with backlight on resulted in 7:10:14.

[funman]

With BATTERY_CAPACITY = 730,

That gives:

CURRENT_NORMAL = 730 / (10+37/60.) = 69mA per hour
CURRENT_BACKLIGHT = (730/(7+10/60.)) - (730 / (10+37/60.)) = 33mA per hour

EDIT: not sure if mA per hour makes sense ..

[mc2739]

funman,

my battery capacity is 750mAH, not 730mAh.

It was bought as a refurb, so may not have the original battery.

[tessarakt]

Is it normal that the battery percentage jumps up and down? It was at 39%, then I had the light on and it moved down until 34%, then it went up to 40% again while I did not touch it, now it is at 35% again ...

[saratoga]

EDIT: not sure if mA per hour makes sense ..

Battery capacity has units of mA*hours, so its actually mA*hours per hour which is simply mA.

[funman]

Is it normal that the battery percentage jumps up and down? It was at 39%, then I had the light on and it moved down until 34%, then it went up to 40% again while I did not touch it, now it is at 35% again ...

Which model ?

With "I had the light on", do you mean the LCD backlight was active ?

What is your setting for backlight timeout ?

If you go into the debug screen of battery you can see a graph with the voltage, is it jumping up and down or only decreasing ?

(I assume yes, but are you using a current build of today?)

[tessarakt]

e280v2. Yes, I mean active LCD backlight. I have to look for the exact settings later, but it switches off after some seconds without input. (It seems as if the battery "recovers" in phases where the backlight is off.) I'll look at the battery debug screen later. Yes, I updated to a build of today this afternoon.

[FlynDice]

@funman:

I have flashed my clip+ with the unmodified dualboot.S code.  It seems to work just fine but there does not seem to be a any extra delay in addition to the boot time for an unpatched firmware(as it appeared there should be from looking at dualboot.S).  I tried upping the delay value from 0x500000 to 0x5000000 & 0x50000000  with no difference in the results.  Looking closer now and scratching my head.  Am I being a bit too paranoid do you suppose?


Edit:
After looking through the code more closely I still think I should be seeing a delay with the patched firmware in relation to the unpatched and I do not.  After I copy the newly patched firmware file to my clip+ it does do the upgrading firmware routine.  And when I turn it back on it starts up asking for settings like it normally does after a firmware upgrade.  However, there is no added delay when booting.  In all cases there is about a 1 sec lag between pushing the power switch and seeing the OF splash start up.  This leads me to believe that the delay code(5 sec in SVN & much more in my modified) in dualboot.S is somehow not running.

Here are the steps I used to produce my patched firmware:
- I built a clipv2 bootloader (I don't really think this matters as I'm not running actual rockbox code yet....)
- I used scramble -add=cli+  to produce bootloader-cli+.sansa
- I modified mkamsboot to work for clip+(just removing the #if (0)) and built it.
- I ran mkamsboot to produce patched firmware named Rclppa.bin
- I loaded the patched firmware on the clip+ and renamed to clppa.bin
- After seeing no delay the first time, I modified dualboot.S to try to increase the delay but was not successful.

Here is the diff and console output that I saw.       http://pastie.org/807886

The patched firmware that I used seemed to work identically to the unpatched. 

[mc2739]

@FlynDice

Check your forum PMs

[FlynDice]

@ mc2739:

You got it exactly right Thanks!!!!   

I still had to modify the delay as the 0x500000 only delayed about .5 secs and was not very obvious.  I wonder if this means the processor is being clocked a lot higher?  We'll see!



EDIT:

I'm attaching a .pdf with my results for GPIOA.  I've got to figure out where to go from here so If someone has an idea please speak up. 

I would find it odd if this wasn't a keyscan type thing similar to the clip & clipv2 but I can't make it fit together in my head just yet.  Moving on to GPIOB,C,D with the same code does not seem logical to me.

EDIT:

Just went back & found funman's post with some hints --> http://forums.rockbox.org/index.php?topic=14064.msg160803#msg160803

EDIT:

I've found all of the buttons except pwr now.  There is no hold button.  The OF implements the hold function with a long home press.
New .pdf attached.

EDIT:

I now have Dualboot working with left button.  No Rockbox code yet, just a delay to simulate branching to rockbox.

[funman]

good job!

Did you forget to update dualboot.c / dualboot.h when the delay wasn't changed?

I have one remark before you commit your diff:

You should find the USB pin: I see that the OF writes GPIOB before reading buttons, if you skip this step reading the left button might just not work on some specific Clip+.

That's the same process than checking buttons, you can add the check after checking for left button since you know it works on your Clip+.
EDIT: only add the check after left button in your test build, once you found the USB pin it should be the first check (as it is in dualboot.S) as I believe it's much less likely to fail than a button check.


Once it's done you should commit it, so you can start LCD code and maybe be helped by others

I'll look at making the Clip+ bootloader target build

[funman]

Just found this on google.

In the first post:

WARNING: drivers/usb/host/as352xhcd.o(.text+0x2be0)

In the third post:

AS353X NAND Driver, (c) 2010 austriamicrosystems

And a bit more down:

insmod /lib/modules/2.6.28.4-as353x-patch-svn1406/kernel/drivers/usb/gadget/dwc_otg/dwc_otg.ko
dwc_otg: version 2.60a 05-JUN-2009
...
dwc_otg: Detected: Synopsys DWC OTG 2.60a Core

If one of you can write chinese and feel like asking them where they got their linux sources and if they are willing to share, perhaps we could find some SD code!

Note we already have the source for dwc_otg (link on the SansaAMS page)