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

[ecrips]

I recently got a Fuze V2 and I thought I'd report on my findings:

The GPIO inputs for USB detect and Left button are the same as the Fuze V1 (using http://github.com/ecrips/Rockbox-FuzeV2/commit/8a9030bbd1f895958b5c455e398cf1ab499c27b5 I successfully get a delay only when holding Left and without USB connected). I limited the RAM to 0.5Mb not because I know it's correct, simply because I don't know for sure I have any more.

I then attempted to cobble together the ClipV2 support that funman has done with bits of Fuze V1 code, but didn't get anything to boot.

So I thought I'd go for something simple and attempted to simply turn the button wheel on and spin in an infinite loop. At which point my Fuze appeared bricked. No amount of holding the power button/plugging into USB etc got it working.

However, once the battery was flat, plugging it into USB got it booting the original firmware again! So I've recovered my device, but I'm a little wary of running random code on it now

It does appear that it's possible to disable the "reset" operation on the power switch on Fuze V2s which could make testing interesting!

[funman]

I recently got a Fuze V2 and I thought I'd report on my findings:

The GPIO inputs for USB detect and Left button are the same as the Fuze V1 (using http://github.com/ecrips/Rockbox-FuzeV2/commit/8a9030bbd1f895958b5c455e398cf1ab499c27b5 I successfully get a delay only when holding Left and without USB connected).

Cool!
Did you try to control the button light, so at least you have some output before we write a lcd driver?

I limited the RAM to 0.5Mb not because I know it's correct, simply because I don't know for sure I have any more.

Hum I don't remember why I did that: a packed Clip bootloader + packed Clipv2 OF largely fits in 0x5000 = 327680 bytes (384kB, not 0.5MB):

[INFO] Original firmware size:   391804 bytes
[INFO] Packed OF size:           90807 bytes
[INFO] Bootloader size:          45464 bytes
[INFO] Packed bootloader size:   22987 bytes
[INFO] Dual-boot function size:  272 bytes
[INFO] UCL unpack function size: 168 bytes
[INFO] Total size of new image:  114234 bytes

And the bootloader size can even be shortened by removing -mlong-calls option from gcc.

However I suppose that you have plenty of RAM behind that, since on Clipv2 & Fuzev2 the DRAM is mapped at 0x0 (the OF firmware block doesn't fit in 0x50000 bytes, so I suppose that the IRAM size didn't change between AS3525 and this newer SoC believed to be AS3531)

I then attempted to cobble together the ClipV2 support that funman has done with bits of Fuze V1 code, but didn't get anything to boot.

So I thought I'd go for something simple and attempted to simply turn the button wheel on and spin in an infinite loop. At which point my Fuze appeared bricked. No amount of holding the power button/plugging into USB etc got it working.

However, once the battery was flat, plugging it into USB got it booting the original firmware again! So I've recovered my device, but I'm a little wary of running random code on it now

It does appear that it's possible to disable the "reset" operation on the power switch on Fuze V2s which could make testing interesting!

You should be able to use the unmodified power_off() function, so you could test your code with a finite number of loops, and then power off to avoid having to empty the battery.

This thing also happened to me with a Clip while developping the bootloader but I don't remember why exactly (perhaps reading/writing from some GPIO pin).

Also note that on Clipv2 you have to press the power button for much longer than for Clipv1 (something like 20seconds)

I'll try to find the LCD code in the OF, since I know a bit the Sansa AMS firmwares and they all are _very_ similar (even between AMS v1 & v2!).

[matsch]

Can you confirm that you have no radio chip (radio not detected by rockbox) ?
You can check in debug menu -> FM radio.

Perhaps this is the way to detect the Clips which needs this special screen powering.

My clip has no radio chip. Submitted patch to flyspray.
http://www.rockbox.org/tracker/task/10273

[ecrips]

Did you try to control the button light, so at least you have some output before we write a lcd driver?

I have attempted to turn it on using the following code:

Code: [Select]

	ldr   r0, =GPIOA
	ldr   r1, [r0, #0x400]
	orr   r1, r1, #0xFF
	str   r1, [r0, #0x400]

	mov   r1, #0xFF
        str   r1, [r0, #(0xFF<<2)]

	mov   r0, #0x3000000
1:	subs  r0, r0, #1
	bne   1b

	b     boot_of

(repeating for GPIOs B, C and D) I'd expect that to configure all pins as outputs and output a 1 on each pin. But I haven't managed to turn the button light on with that code. Although it has just now occurred to me that it's possible the button light is on when a 0 is output... I shall have a go later.

[funman]

What if you try only GPIOA_PIN4 ?

By the way if you want to come on IRC we could discuss this "live" (i'm in CEST timezone)

[FlynDice]

@kugel:  I know you think we should abandon the 31/32 MHz PCLK rates but I think you should reconsider.  With the DBOP fifo patch(yours) the ui responsiveness is very good at 31 MHz.

[kugel.]

@kugel:  I know you think we should abandon the 31/32 MHz PCLK rates but I think you should reconsider.  With the DBOP fifo patch(yours) the ui responsiveness is very good at 31 MHz.

Have you done battery benches or current messurements? I'm not sure 3x vs 6x makes much difference.

Also, we most definitely need to boost more often with 31MHz, which may result in higher drain again (since the main clock is at 248MHz then).

[FlynDice]

Have you done battery benches or current messurements? I'm not sure 3x vs 6x makes much difference.

No benches yet, I just thought your main concern was ui responsiveness which your version of the DBOP fifo patch vastly improves for me at least.  I do seem to remember noticing that the higher PCLK setting did impact battery time when funman ran his benches a few weeks ago.  I don't have enough info to say that I think we should lower it, I'm just saying that ui responsiveness is not a problem at the lower frequency now as far as I can tell.

[matsch]

Clipv1 r21190 sporadically stops playing MP3s showing 'filename (root) 1018'.
I think this happens more often when playing large mp3-Files or pressing pause play button several times for one file. Only after reboot the Clip plays again.

[funman]

Yeah playback sometimes stops on the Clip.

The problem is known, and specific to the Clip, but no cause has been determined yet.

EDIT: If some people have a m200v4, it would be very helpful to tell if you meet this same bug, so we could relate it to the small amount of memory of these 2 models (2MB)

[iudex]

My clip dont want to boot with caching patch.

It shows me:

Loading firmware
LEnght: 63210
CHecksum: 26CED3E
Model name: clip
Loading rockbox.sansa
Sum: 26CED3E
Executing
 

[funman]

My clip dont want to boot with caching patch.

Some people had to update the bootloader to make it work. Did you update it ?

[sko]

I made a patch for e200v2 which makes the button driver more equal to the one of the fuze (which uses same repeat/acceleration logic since r21166):

• it renames the repeat variable to accel
• using same comments as on fuze (as they are describing the same)
• remove wait for fifo empty
• implement button_delay in the same way as on the fuze

Here is the patch: FS#10284

[kronflux]

I made a patch for e200v2 which makes the button driver more equal to the one of the fuze (which uses same repeat/acceleration logic since r21166):

• it renames the repeat variable to accel
• using same comments as on fuze (as they are describing the same)
• remove wait for fifo empty
• implement button_delay in the same way as on the fuze

Here is the patch: FS#10284

Just tested this! seems to work rather well, I definitely prefer it over the way it was.
Running this on my e280v2.
Edit: Also just made the hardware mod that gets rid of the "click" feel in the wheel, and tried it both with this patch and without, and both with the wheel mod and without, this patch is still preferable, to me anyway.
Nice work! thanks a lot!

Don't know if this has been addressed yet, but the player randomly likes to turn the wheel light on during playback, and sometimes when browsing, it flickers.
I think the issue was addressed, but was it ever fixed previously?

[funman]

Don't know if this has been addressed yet, but the player randomly likes to turn the wheel light on during playback, and sometimes when browsing, it flickers.

This is a known "problem" also happenning on fuze, and which will eventually be looked at in the future.