Rockbox Development > New Ports

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

<< < (10/386) > >>

hth:
The 8-pin header on the lcd's back i wrote about appears to be a JTAG port (maybe pin 4 is TMS), with no standard pin assignments (GND would be on 7 but is on 8, e.g.). I ordered an Olimex ARM-USB-TINY to find out more and verify the pin assignments and wait for a Sansa M240 for testing bootloader embryo.

Regarding the recovery mode, this would be too good to be true!!! However, i notice nothing different from normal operation (or i'm too dull, am i? :). AFAIK, the hold+rewind (aka hold+left button) combination on  power-on is assigned to MSC mode on the e200 v2s. So it seems this info is just given to ensure the transfer mode for uploading the firmware binary. I guess this triggers the regular firmware update code located on the NAND.

Btw., started coding the AS352X target, i.e. the CGU so far. I use the first AMS linux-arm patches as a basis and compare them to the AS3525 datasheet. OTOH, the files i stumbled upon are really incomplete, on the other, modifications for AS3527 targets should be minimal (on the audio part the 500mW amplifier removed, for power management, enhanced support):
as352x-linux-2.6.19.patch1
as352x-linux-2.6.19.patch2
as352x-linux-2.6.19.patch3
as352x-linux-2.6.19.patch4
as352x-linux-2.6.19.patch4.2
as352x-linux-2.6.19.patch5
u-boot.patch1
u-boot.patch2
u-boot.patch3

ilikerockbox:
I think that the sansa clip has the same 8-pin header, Top-Right:


It is located under the usb connector, Top-Left:


Using the photo, 6 of the 8-pin header can be traced back to the AS3525. If I(or someone else) had a data sheet I could probably figure out the function of these connections. It is likely that these connections are the same as in the e200 series.

These photo's were found on:
http://www.anythingbutipod.com/archives/2007/11/sandisk-sansa-clip-disassembled.php

skaos:
Anythingbutipod has just disassembled the Sansa Fuze. It uses the same SoC as most of the other V2 models (20-99-00112-2) and it looks like it comes with RAM (ESMT M12L64164A-7T).

Bagder:
Yeps, I did extract the chip pic and compared it with the e280v2 one:

http://daniel.haxx.se/blog/2008/03/28/sansa-fuze-ams-reuse/

hth:
Unfortunately my father is in hospital for over a month now. :( So the time i can spend on the port reduced to about half an hour per month. Before the port stalls, i post some iterim results here which need verification:

8-pin JTAG connector pinout for e200v2:

--- Code: ---1: VDD    +
2: TCK    JTAG Clock
3: TDI    JTAG data in
4: TMS    JTAG test mode select
5: nTRST  JTAG test reset, active low
6: TDO    JTAG test data out
7: nSRST  System reset, active low
8: GND    -

--- End code ---

I used to solder 0,6mm thick wires onto the connector and put them under the lcd, leaving them out on the strap eyelet side. However, the wires didn't last long (isos broke and at least one wire got almost cut by the case). So i have to wait for an oppurtunity to fix that and verify the pinout  (my soldering station is out for repair).
Think the best would be to wire a female 1.27mm pitch 10-pin connector under the lcd left around under the mcu and put some iso-tape around the connector pins (for avoiding resets) and onto the black glueing side beneath the hold switcgh. That way jtag connections can be made on demand with an
adapter 10-pin male to a 20-way idc keyed box header (2.54mm male), and you can carry your player around without any wires coming out of it like i did.

There's a big chance that other devices (Fuze, Clip, etc.) use the same pinout for the JTAG connector; i would count from top side down or from left to right, but you can also measure potential of the outermost pins to be sure and let VDD be pin 1 (or use a led with a resistor for
determining polarity).

Btw., i started porting from scratch using the GPLed AS352X sources from u-boot and linux, because much more is implemented than the CGU only.
Unfortunately, the datasheets were within my old rockbox directory i removed, so i'll have to reobtain them to get some info later on. For now, there's enough to modify to get rockbox compiling, a patch against r16933 follows.

Edit: The patch partly contains unchanged u-boot/linux sources to be ported to rockbox.

Would be great if somebody could

* continue figuring out the way checksums are calculated,
* help out with the sources or
* test the jtag interface connector or surprise with another recovery method from broken firmware.
I'll concentrate on the sources, though it'll progress sluggish.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version