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

[funman]

It works no brick as of yet says Version V02.01.35A and like I said it did not brick

Thanks, mkamsboot 1.2 on its way to the download server

FlynDice, funman: Is this code in svn? I've flashed clip+8G with firmware made from svn r25276 and got ATA error. Is it consequence of differences between 2g and 8G clip+ or just I need to wait for your code in to svn?

All the code is in SVN.

I just tried r25287 (both normal build & bootloader) and it works fine, so sorry that there are differences between the Clip+ FlynDice uses and yours.

I believe bug reports will not be useful until he gets SD fully working, but perhaps you can try to build other revisions and last revision until it works.

If you identify a certain commit which made your Clip+ work/not work then you should say which one it is (unless it says so in the commit message already).

[pbxy]

Just a little clip+ update.  If you haven't seen it by now, funman found the magic line to get sound!

Works great on ClipV2, too.

[FlynDice]

@ mitk

What number was your ata error?

[mitk]

FlynDice: It is ATA error: -2

After press ON to debug:
GPIOA: 24 DIR: 20
GPIOB: C4 DIR: E5
GPIOC: 41 DIR: 00
GPIOD: 9F DIR: 00

CP15: 0x0005107D

And after press LEFT:
*PANIC*
ata: -2

It is svn r25276. I will check it with newer version.

Edit:

I've made format my player and tried to run r25276 again and it works, so there is no case.

[ranma]

does that fix the boot for the c200v2 that did not boot before

It should boot, but the fix for the backlight is not in svn yet.
You still need this patch, to get a working backlight, a more proper fix will come later.

Code: [Select]

Index: rockbox-pwm/firmware/target/arm/as3525/sansa-c200v2/backlight-c200v2.c
===================================================================
--- rockbox-pwm.orig/firmware/target/arm/as3525/sansa-c200v2/backlight-c200v2.c	2010-03-18 01:11:34.328140932 +0900
+++ rockbox-pwm/firmware/target/arm/as3525/sansa-c200v2/backlight-c200v2.c	2010-03-18 01:13:26.107078294 +0900
@@ -37,12 +37,12 @@
 
 static void _ll_backlight_on(void)
 {
-    GPIOA_PIN(5) = 1<<5;
+    GPIOA_PIN(7) = 1<<7;
 }
 
 static void _ll_backlight_off(void)
 {
-    GPIOA_PIN(5) = 0;
+    GPIOA_PIN(7) = 0;
 }
 
 void _backlight_pwm(int on)
@@ -56,7 +56,7 @@
 
 bool _backlight_init(void)
 {
-    GPIOA_DIR |= 1<<5;
+    GPIOA_DIR |= 1<<7;
     return true;
 }
 

[funman]

mkamsboot 1.2 is now available at the usual location

[stel]

I'm another happy RB clip+ user but I've come across a problem. I don't know if it's too early days to report it (just say if it is).
Symptoms are exactly the same as FS#11114 but I'm using MPC files. Sometimes I can get to the end of a track and then it data aborts but I never get to play more than one track and it happens both on both internal & external memory.
I haven't had any issues so far with mp3 files

Example error I've had before the clip+ locks up or restarts:

data abort at 30006D14
FSR 0x8
(domain 0, fault 8 )
address 0x74E452F7

[FlynDice]

Well I almost have sd-as3525v2.c send_cmd() working with the CD int but it seems playing music gets in the way...

If you understand Stkov ata/sd and/or data aborts could you do me a favor and comment on:

http://www.rockbox.org/tracker/task/11140.

I can load & run rockbox from the main SD, browse files & display album art, but as I said, playing fails.

[bYOndo]

Just flashed my ClipV2 8GB, no problems at all. Finally, thanks for your _great_ work!
A mere detail: mkamsboot asks for "m300a.bin" but the OF is named "m30pa.bin", I renamed it and it worked.
A strange behaviour In RB: when you press pause or switch off the clip during music playing, it makes a little "buzz" sound.
The booting time is even faster than OF

Massimo

edit:
ops...my fault regarding OF filename, it was my too little attention on copy&paste of mkamsboot command line    

[bYOndo]

Just flashed my ClipV2 8GB, no problems at all. Finally, thanks for your _great_ work!
A mere detail: mkamsboot asks for "m300a.bin" but the OF is named "m30pa.bin", I renamed it and it worked.
A strange behaviour In RB: when you press pause or switch off the clip during music playing, it makes a little "buzz" sound.
The booting time is even faster than OF

Massimo
   

yea but just rename the FW back to m30pa.bin after you should be fine but I have a 2G clip V2 so mabey it is different Rockbox runs fine for me don't know where you are hearing the buzz sounds I dont hear anything maybe you messed with the gain?

it's barely audible, but it's there, it's like an electric discharge sound effect (if you know the song "(-) Ions" by Tool, that sound!)
it's related to "fade on pause" option, because if I disable it, this issue disappears. 

EDIT: One more thing there seems to be a problem with the database I cant export/import settings any idea when this will be fixed?

funman has just replied to it Let's wait!

Massimo 

[misterhh]

I just installed rockbox on my 4GB Clip+, rebooted into rockbox successfully, and played that block-breaking game. Then I selected Chopper, and I'm pretty sure it bricked. I cant turn it on, or connect it via USB. I know this is risky no-warranty software, but is there any way to force reset, etc?

edit: woah that was a scare, I held down the power button for 15 seconds then tried again and it turned on.

[oxide]

There's been a bit of talk on the Sansa forums about a pitch issue on the Clip v2 and the Fuze v2, where playback of files with a sampling rate of 44.1KHz is 2% slower than it should be due to a clock problem. I personally have an 8GB Clip and a 4GB Clip (of the v1 variety) and have compared playback between the two, and noticed that the 8GB does play slightly more slowly.

The Clip v2 with the Sandisk 02.01.32 firmware does indeed play flat. In fact, it plays about 19 cents or 1/5 of a semitone flat. Enough to where it makes it so that if I play along on an in-tune guitar with a track that I know is in tune, it's out-of-tune with the Clip v2 with 02.01.32 firmware. Sandisk recently released new 02.01.35 firmware that fixes this pitch problem - the Clip v2 with 02.01.35 firmware now plays pretty much in tune.

HOWEVER! Doing the "play-along" test, I notice that the new Rockbox for the Clip v2 (thanks for all the hard work, guys!) also plays noticeably flat. I'm not sure if it's the exactly the same amount flat as the 02.01.32 firmware (someone with instrumentation will have to measure it), but it's noticeably flat.

[bertrik]

Rockbox on AMS sansa (at least the clipv1, fuzev1 and e200v2) plays with a sample rate error of about 0.15%. It is possible to reduce this to 0.04% error by either 1) changing the entire clocking scheme of the AMS  sansa or by 2) enabling a separate PLL for generation of the sample rate clock.
Option 1) is a bit controversial because it affects other sub-systems too (like maximum attainable CPU speed, display update rate, clocks for SD card access).
Option 2) takes a bit more power from the battery than we currently do, reducing runtime by approximately 2.5%
See the following patch for an implementation of option 2: http://www.rockbox.org/tracker/task/10906
The same trick can probably also be used to reduce the error on clipv2 players.

[bYOndo]

Rockbox on AMS sansa (at least the clipv1, fuzev1 and e200v2) plays with a sample rate error of about 0.15%. It is possible to reduce this to 0.04% error by either 1) changing the entire clocking scheme of the AMS  sansa or by 2) enabling a separate PLL for generation of the sample rate clock.
Option 1) is a bit controversial because it affects other sub-systems too (like maximum attainable CPU speed, display update rate, clocks for SD card access).
Option 2) takes a bit more power from the battery than we currently do, reducing runtime by approximately 2.5%
See the following patch for an implementation of option 2: http://www.rockbox.org/tracker/task/10906
The same trick can probably also be used to reduce the error on clipv2 players.

And a permanent pitch modification? Maybe thru a string on config.cfg. It's less elegant and I don't know how much power it drains, I test a 440hz sample with a tuning fork next to the other ear and with a 101.1% of pitch correction it sounds perfectly in tune.
It changes both time&pitch so it's correct, isn'it?

just my 2 cents.
Massimo
 

[FlynDice]

A bit more SD related info.  I believe the controller we're dealing with is The Synopsys DesignWare® Mobile Storage Host Controller.  Here is a link to a document with some info on page 119 - 120: 

https://www.synopsys.com/dw/doc.php/doc/dwf/manuals/dw_frg.pdf

There is another 3 page .pdf available with a little bit more info but you need to register to access it.  I did and there wasn't much more info there.  They call it a datasheet but it's not the datasheet that would really help us.  The one thing i did pick out of it though is that there are separate clocks to the card interface unit and the bus interface unit.  I'm guessing CGU_MEMSTICK is going to the BIU and the CGU_BASE + 0x3C that is now renamed CGU_SDSLOT is going to the CIU.  That would make sense with the frequencies we are running those at.  CGU_IDE is still required as in the as3525v1 for reasons we still don't fully understand.