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

[FlynDice]

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

Yes that was exactly the problem but mc2739 was clever enough to figure it out for me so I could continue!

I have checked all 32 GPIO pins and USB does not set any of them high so far as I can see.  There are some pins that seem to be set high always and I'm going to check them to see if perhaps USB will pull them down low.

As far as writing to GPIOB goes, what do I need to write? I'm assuming you mean change the gpio_dir to 1 for output, write a value(0xff or 0??) and then switch the gpio_dir back to 0 and read the pin?

I see you've been busy working on the clip+ build also.  I'm very confident in my left button dualboot so I think I'll take a break from chasing GPIO pins and see what happens if I let rockbox try to boot!


Edit:  Bootloader builds just fine but no sign of anything on clip+ when I let rockbox try to boot.

Long pwr press to reset and dualboot into OF lets me plug usb back in and flash the original OF firmware back to it.

[funman]

As far as writing to GPIOB goes, what do I need to write?

saved_gpiob = GPIOB_DIR;
GPIOB_DIR = saved_gpiob | (1<<0);
GPIOB_PIN(0) = 1;
i = 500;
while(i--) ;
GPIOB_DIR = saved_gpiob

and then read the buttons.


The backlight might be different for Clip+, what would help debugging is to find the button light.

Note if you power on the Clip+ fast after power off there might still be data in GRAM, and if you plug the USB cable it might power a bit the LCD and you could see something on the screen, that worked for the Clipv2.

[FlynDice]

The backlight might be different for Clip+, what would help debugging is to find the button light.

Unfortunately there seems to be no buttonlight on the clip+

EDIT

Using the GPIOB write did not change the results at all it seems.  Here's the code I used:    http://pastie.org/812138

When booting to the rockbox bootloader there was no sign of life at all.  I tried holding/pressing buttons, plugged in USB listened on headphones, shined a light on the screen etc..     Nothing, nada ,zilch.

[funman]

If it didn't make a difference I think it should be used, because there could be a difference on some models.

Now let's hunt the USB pin !

EDIT: Now it seems it is never explicitely read in Clipv1/Clipv2 but rather written to .. Not sure how else we could detect rather than by brute force like you did..

EDIT2: We could use adc_read(VBUS): it reports ~ 0.16V when usb isn't plugged and around (a bit less) 5V when USB is plugged. Would i2c read in mkamsboot be overkill ?

[FlynDice]

I found the clip+ pwr button on D6 by using the  GPIOB write with this code:  http://pastie.org/812463

It was very tricky as it's difficult to press the pwr button to turn it on and then press it again quickly enough to have it read....

[bertrik]

I did a few battery runtime benches on my clip v1.

Somehow my clip v1 (1GB with FM) seems to get a lot longer runtime than those of other people.
I'm getting more than 8h with rockbox while other people seem to get only around 5h30.

I wonder what causes these runtime differences between people. I think it's not just a bad battery because people with low runtime in rockbox still seem to get normal runtimes in the OF.

• Could it be a difference in the Clip hardware perhaps? I do remember that some Clip v1s need the backlight voltage to be turned on while other work without it, for example.
• There's a number on the bottom of my Clip v1 (1GB with FM), saying BB0806AYJK. Perhaps this can be correlated to rockbox runtime.
• Or maybe we're neglecting to set some kind of power management setting?

To experiment a bit, I ran a benchmark with the CPU voltage regulator forced in a different mode: "direct length regulation" instead of auto (which probably chooses the "charge pump with length regulation" mode under light loads). With this change I got 5h48 runtime instead of 8h14, much closer to the result of other people.

[saratoga]

Its possible we don't init some piece of hardware, and some clips default to different settings.  I know with PP different PP devices would boot with random pieces of hardware enabled, resulting in different idle currents until we figured out how to turn them off.  Something similar may be happening here.

[matsch]

I did a few battery runtime benches on my clip v1.

Somehow my clip v1 (1GB with FM) seems to get a lot longer runtime than those of other people.
I'm getting more than 8h with rockbox while other people seem to get only around 5h30.

To experiment a bit, I ran a benchmark with the CPU voltage regulator forced in a different mode: "direct length regulation" instead of auto (which probably chooses the "charge pump with length regulation" mode under light loads). With this change I got 5h48 runtime instead of 8h14, much closer to the result of other people.

There is bit 7 in AS314_CP_DCDC3_SETTING  which defines a lower margin for changing to length regulator when setting to 1. In rockbox it is set to 0.  Maybe there are some clips having a lower input voltage for the regulator. The voltage margin after the charge pump voltage divider is to low and they stay in length regulation.  There is register IOVDDp in the as3525 data sheet. If it is set to 1 (2.99V) risk is higher for length regulator only.

[FlynDice]

This is how I understand the charge pump/length regulation scheme.  There are some charts in the datasheet graphing voltage vs current for both methods of regulation.  The charge pump is the more efficient method to provide current but cannot maintain the voltage in the desired range at higher current draws.  When the voltage drops too much it switches to length regulation to provide the needed current and maintain an acceptable voltage.  So if you change the switching margin what you are doing is allowing the voltage to get lower before switching to length regulation.  I don't know if that's OK or not...  I checked on an almost empty battery and it was still running in charge pump mode.

[FlynDice]

@ funman:

Here is the code I tested for clip+ dualboot: http://pastie.org/815858.  It seems to work as far as branching to the OF when a button is pushed but there's something weird going on if there's no button pushed.  It should just take an extra 4 secs then boot the of. Instead it just stays dark.  I thought perhaps it was just the timer on the lcd but pushing a button won't wake the display.  Interestingly, a normal power off pwr button press does power down normally.  No need for the long power reset.  I tried removing the last 4 sec delay and this was still happening.

[funman]

Hm i spotted one problem: I forget to modify r1 after writing new GPIOB_DIR and before writin B0

Also can you try without resetting B0 ?

If this doesn't work then I have no idea and you should forget everything I said ..

[funman]

There's a number on the bottom of my Clip v1 (1GB with FM), saying BB0806AYJK. Perhaps this can be correlated to rockbox runtime.

Mine is BE0712A0LK and has a short battery life, I would think this is a serial number and not a hardware revision like is written on the PCB

[FlynDice]

@funman

I tried the modifications you suggested but still no luck.  The dualboot function with the left & home keys works with that code, ie if you press one of the buttons during boot the of boots fine, but if you don't hold a button the of won't boot.  Just to check on my test setup I substituted the code that I know works and the of booted fine without a button press.  I'm going to correct the error I made in unsetting B0 but I think that's all I should do for right now.

EDIT:  Here's the code I used :  http://pastie.org/816726

EDIT:  I can confirm that the clip+ has the same cp15 id register value: 0x41069265 as the clipv2 so ARM926EJ-S.
           I can get some yes or no answers using a delay so let me know if you have questions that fit that profile.

EDIT:  CCU_VERS  main version id : 2  sub version id: 3

EDIT:  It seems I can also find values in registers bit by bit but it takes a lot more work....

[ranma]

Since my original report on the 'Sandisk - Installation/Removal' subforum was delted I'll report it here, where it should be appropriate:

I tried installing rockbox on my c240v2 according to the instructions in the "Installation for Unusable (other AMS Sansas)" section of http://www.rockbox.org/wiki/SansaAMS

I ran into the  "C200V2 bootloader installed but no effect" issue, but was able to work around it by patching dualboot.S, apparently the USB pin check is borked for my device and always branches to the original firmware even if the device is not plugged into USB.
See also http://forums.rockbox.org/index.php?topic=23263.msg162027#msg162027

After flashing the firmware with my updated dualboot, it now tries to boot rockbox, but apparently fails.

The exact behaviour differs depending on whether or not .rockbox/rockbox.sansa is there, so I'm assuming that the second-stage bootloader works so far.
However as far as I understand the second stage is supposed to turn on the lcd, show a splash and report an error there if rockbox.sansa is missing. My lcd does not turn on though.
What I do see:

If .rockbox/rockbox.sansa is not there:
Middle button light turns on for some time, device powers off.

If .rockbox/rockbox.sansa is there:
Middle button light turns on for some shorter time, turns off, both middle button and menu turn on
for some longer time, both turn off, pattern repeats.

If I boot while holding right it boots the original firmware just fine, so my patched dualboot works for me.

I tried building a newer second stage bootloader from svn than the Nov. 21st 2009 version at http://download.rockbox.org/bootloader/sandisk-sansa/c200v2/bootloader-c200v2.sansa
But the behaviour stayed the same after flashing that one.

Hope that helps.

Index: dualboot.S
===================================================================
--- dualboot.S  (revision 24590)
+++ dualboot.S  (working copy)
@@ -93,12 +93,14 @@
 #endif
 
 #ifdef USB_PIN  /* TODO : remove this check when we'll have an USB driver */
+/*
         ldr     r0, =GPIOA
         mov     r1, #0
         str     r1, [r0, #0x400]
         ldr     r1, [r0, #(4*(1<<USB_PIN))]
         cmp     r1, #0
         bne     boot_of
+*/
 #endif
 
         /* Here are model specific tests, for dual boot without a computer */

[funman]

So the problem is the USB check gives a false positive ?

What happens if you power it with the USB cable ?

Some c200v2 might need something more to enable the backlight, just like what happened on the Clipv1