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

[saratoga]

Now I have to figure out how to best proceed in testing the pins...

This can probably help:

http://forums.rockbox.org/index.php?topic=14064.msg129684#msg129684

[funman]

Quick update:

LCD now works on Clip+ since r24729.

It's at the same state than Clipv2, i.e. only buttons & lcd work, still not storage.

Further development is still blocked until someone figures how to use the SD controller.

mkamsboot reported to work (r24727) on my Clip+, FlynDice one and 2 other testers from the irc channel (tested 2GB, 4GB and 8GB).

If you want to help you can test it on your Clip+ and report if it bricked it or not (still not sure what happened on the 2 bricked Clip+)

[ranma]

Now I have to figure out how to best proceed in testing the pins...

Battle plan:

Either the 0V pin is TRST and TDO is tristated during reset or it's TDO and TRST is floating.
Check if it can be pulled up (TRST) or not (then it's most likely TDO).
Assuming it's TRST, check the other pins for 0V or 3V, I'd expect TDO to have logic level now.
For the remaining 3 pins there should only be 3! = 6 possible combinations left.
I also bought two 74HC00, LEDs and resistors to build a SR flop for manual clocking and to show the pin state.

[edit]
Ok, unfortunately TDO is tristated as long as the state machine is not in a 'shift data' mode.
But I got the pinout now:

Code: [Select]

C240v2 JTAG pinout

USB

    1 GND
 F  2 TDO
 L  3 TCLK
 A  4 TMS
 S  5 TDI
 H  6 TRST
    7 VCC

RAM
TRST is asynchronous, just checked that.
Here ist the test rig I used for figuring out the pinout:
http://uguu.de/~ranma/jtag_test_rig.jpg
Two 74HC00 Quad NANDs, 2 NANDs form a SR-Flipflop to debounce the clock switch (left), 4 drive the upper LEDs for monitoring which pin is TDO, 2 are unused (inputs tied to gnd).
TMS is fed in using the dark blue jumper cable.
TRST is the white cable on the right side pulled up to VCC using a 10K resistor.

Unfortunately the girl with the Jtagkey wasn't at the hacker space today, so I can't go on and try to upload a debricker just yet.
[/edit]

[saratoga]

Unfortunately the girl with the Jtagkey wasn't at the hacker space today, so I can't go on and try to upload a debricker just yet.

If you can get JTAG running while in some part of the OF, it would be really interesting to know what settings it uses for the various AS3525v2 clocks and voltage regulators.  We're clearly not setting a few things correctly and knowing the OF settings would be useful to figure out what.

[funman]

If you can get JTAG running while in some part of the OF, it would be really interesting to know what settings it uses for the various AS3525v2 clocks and voltage regulators.

You mean AS3525? The v2 is only in Clipv2/Clip+/Fuzev2 not in c200v2.

Not sure how c200v2's battery life but I would expect it to be lower than OF like the other AMS, and indeed JTAG could be very helpful.

Can you insert breakpoints ? I think it's the only way to be able to know what the i2c registers are set to (Reading a register isn't simply a load), unless we find that the OF keeps a cached table of registers content

[FlynDice]

Having display makes things so much easier!

Clip+  pin A2 is unset for uSD present.

USB detect is not on any of the GPIO pins.

[embrion]

Hi

any ideas about improving batterylife? I've tested my v1 Fuze and got 11:50h while OF gives me ~22h. OF was tested by repeating the same track so I believe caching gave me some of that 22h but still it's a lot more than RBX.

[saratoga]

Hi

any ideas about improving batterylife? I've tested my v1 Fuze and got 11:50h while OF gives me ~22h. OF was tested by repeating the same track so I believe caching gave me some of that 22h but still it's a lot more than RBX.

Yes we've talked about this a lot.  Basically various core clocks are set too high and probably some hardware isn't turned off properly.   

[kronflux]

I don't know what you guys did, but my e200v2, I haven't updated for a good few weeks. I just compiled the latest svn, and wow! changing tracks and whatnot used to be really slow for me. it could take up to 5 or 6 seconds just to change to the next track when you press next or previous track. now it's instantaneous! very impressed! and I just tested doom for the heck of it too. aside from it being too tiny since its not landscape view, it works great! thanks guys! keep up the amazing work!

[embrion]

Yes we've talked about this a lot.  Basically various core clocks are set too high and probably some hardware isn't turned off properly.   

Yeah, I read about it. Also something about some hardware differences between (at least Fuze) 1.x revisions. Well, somehow they manage to keep one OF firmware version for all revisions 1.x so maybe some kind of detection?
In my case it would be probably only clocking as I tested without powering off.
Any plans on looking for minimal clocking? I know that everybody is working now on Clip+ etc but improving existing, more mature ports would also be welcomed

[saratoga]

Any plans on looking for minimal clocking? I know that everybody is working now on Clip+ etc but improving existing, more mature ports would also be welcomed

Don't let me get in your way.

[bertrik]

Regarding the runtime issue:
1) A known problem is that some revisions of the radio chip seem to initialise in a powered-on state, wasting about 15 mA. With a runtime of 11h50m, current is about 550mA/11h50m = 46.5 mA. Without the 15 mA waste, runtime could be about 17h27m.
2) I think we are pretty conservative already with respect to disabling and enabling various peripherals. You could look up the CGU_PERI value in the debug/hwinfo menu and check the bits against the datasheet. Last time I looked at it on my clip, I couldn't find any unneeded peripherals wasting power.
3) We have configured the internal clocks for maximum performance (for example 248 MHz max processor clocks). Maybe the OF clocks a little lower. Also with a lower clock (below 200 MHz), the processor voltage can be reduced from 1.2V to 1.1V, theoretically saving about 16% on processor current.

Can you report back with the following:
1) enable the radio, go to the debug/radio menu and note the first two numbers (1st will be 1242)
2) go to the debug/hw info menu and note the CGU_PERI value

[ranma]

Ok, since Tooru didn't have her JTAGKey with her yesterday and akizukidenshi has a reasonably priced ft2232 board I went ahead and bought one today for 1700 Yen (plus 150 Yen for the experimenting board).

http://uguu.de/~ranma/c200v2_jtag_ft2232c.jpg

Now I have to figure out openocd, but I got it working so far:

[edit]
Now successfully debricked!
Uploaded new first stage bootloader using
"halt" "load_image /home/ranma/ocd_repair.bin 0"
resumed execution from address 0 ("resume 0"), booted into OF and flashed a working image.
(Hard part: Hold down battery on battery contacts so I can unplug usb to trigger flashing...)
[/edit]

[edit2]

Code: [Select]

CGU regs OF in USB mode, no uSD
> mdw phys 0xC80F0000 0x20
0xc80f0000: 00002630 00002630 00000000 00000000 0000001d 0ee34395 00002001 00000032
0xc80f0020: 00000003 00000000 000000ff 000000ff 000000c9 00000191 00000008 00000000
0xc80f0040: 00002630 00002630 00000000 00000000 0000001d 0ee34395 00002001 00000032
0xc80f0060: 00000003 00000000 000000ff 000000ff 000000c9 00000191 00000008 00000000
>

CGU regs OF without USB, but powered over USB, no uSD
0xc80f0000: 0000261b 00002630 00000000 00000000 00000029 0ee3438d 00002001 00000032
0xc80f0020: 00000003 00000003 000000ff 000000ff 000000c5 00000189 00000008 00000000
0xc80f0040: 0000261b 00002630 00000000 00000000 00000029 0ee3438d 00002001 00000032
0xc80f0060: 00000003 00000000 000000ff 000000ff 000000c5 00000189 00000008 00000000

CGU regs OF without USB, but powered over USB, uSD plugged in
0xc80f0000: 0000261b 00002630 00000000 00000000 00000029 0ee3c38d 00002001 00000032
0xc80f0020: 00000003 00000001 000000ff 000000ff 000000c5 00000189 00000008 00000000
0xc80f0040: 0000261b 00002630 00000000 00000000 00000029 0ee3c38d 00002001 00000032
0xc80f0060: 00000003 00000000 000000ff 000000ff 000000c5 00000189 00000008 00000000

CGU regs OF without USB, but powered over USB, uSD plugged in, playing mp3
0xc80f0000: 0000261b 00002630 00000000 00000000 00000011 0ef3c38d 00002895 00000032
0xc80f0020: 00000003 00000001 000000ff 000000ff 000000c5 00000189 00000008 00000000
0xc80f0040: 0000261b 00002630 00000000 00000000 00000011 0ef3c38d 00002895 00000032
0xc80f0060: 00000003 00000000 000000ff 000000ff 000000c5 00000189 00000008 00000000

OF audio master i2c
0xc8070000: 00000028 0000008c 0000008c 00000053 00000000 00000000 00000000 00000009
0xc8070020: 00000001 00000098 00000004 00000000 00000000 00000000 00000000 00000000
0xc8070040: 00000000 00000025 00000025 00000025 00000003 00000000 00000000 00000000
0xc8070060: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[/edit2]

[edit3]

Code: [Select]

CGU regs OF without USB, battery power, no uSD, playing mp3
0xc80f0000: 0000261b 00002630 00000000 00000000 0000001d 0ef343d1 00002895 00000032
0xc80f0020: 00000003 00000003 000000ff 000000ff 000000c5 00000189 00000008 00000000
MCI_CLOCK:
0xc8000004: 00000301
0xc8020004: 00000000

CGU regs OF with USB, battery power, uSD present, playing mp3
0xc80f0000: 0000261b 00002630 00000000 00000008 0000001d 0ef3c3d1 00002895 00000032
0xc80f0020: 00000001 00000000 000000ff 000000ff 000000c5 00000189 00000008 00000000
MCI_CLOCK:
0xc8000004: 00000301
0xc8020004: 00000301


[/edit3]

Code: [Select]

> scan_chain
   TapName             Enabled  IdCode     Expected   IrLen IrCap IrMask
-- ------------------- -------- ---------- ---------- ----- ----- ------
 0 as3525.cpu             Y     0x00922f0f 0x00922f0f     4 0x01  0x03
> halt
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x20000053 pc: 0x000000bc
MMU: disabled, D-Cache: disabled, I-Cache: disabled
> arm reg
System and User mode registers
      r0: 00000000       r1: 00009db1       r2: 00000051       r3: 0004ff57
      r4: 0000000f       r5: 0004ff59       r6: 00000000       r7: 8022d509
      r8: 71800c18       r9: 0a20824c      r10: f0b50281      r11: 32006423
     r12: 8001bfad   sp_usr: 0390c0bc   lr_usr: 1bd02082       pc: 000000bc
    cpsr: 20000053

FIQ mode shadow registers
  r8_fiq: 94900252   r9_fiq: 1011ec30  r10_fiq: 3c30898a  r11_fiq: 31487004
 r12_fiq: e0201b14   sp_fiq: 5ca90381   lr_fiq: 2200a108 spsr_fiq: a000007a

Supervisor mode shadow registers
  sp_svc: 8104e3f8   lr_svc: 800002b4 spsr_svc: 60000034

Abort mode shadow registers
  sp_abt: 62050851   lr_abt: 411c08d8 spsr_abt: 20000018

IRQ mode shadow registers
  sp_irq: 8104e080   lr_irq: 8001c750 spsr_irq: 60000073

Undefined instruction mode shadow registers
  sp_und: 5f918607   lr_und: 80ea28d0 spsr_und: 300000f4
>

Here is the openocd config:

Code: [Select]

telnet_port 4444
gdb_port 3333

interface ft2232
ft2232_layout oocdlink
ft2232_vid_pid 0x0403 0x6010

jtag_ntrst_delay 100

set _CHIPNAME as3525
set _ENDIAN little
set _CPUTAPID 0x00922f0f

#jtag scan chain
jtag newtap $_CHIPNAME cpu -irlen 4 -expected-id $_CPUTAPID

set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME arm920t -endian $_ENDIAN -chain-position $_TARGETNAME -variant arm920t

# FIXME: copied from samsung config
$_TARGETNAME configure -work-area-phys 0x200000 -work-area-size 0x4000 -work-area-backup 1


[mc2739]

2) go to the debug/hw info menu and note the CGU_PERI value

On the e200v2, I am not seeing a CGU_PERI value on the "View HW Info" debug screen.


Edit: I found it. I did not realize there was another screen displayed when the down button was pressed.

1) radio ID: 1242 0850
2) CGU_PERI: 0F93018F

[funman]

CGU register dump from OF in USB mode.
0ee34395

2) CGU_PERI: 0F93018F

I see we leave ROM clock enabled unlike the OF, I'll run a battery bench to see if it changes anything to disable it