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

[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: [Select]


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    -


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.

[hth]

OK, posted as task 8843,

Link: http://www.rockbox.org/tracker/task/8843

[Bagder]

Cool, if nobody else does it I hope to soon be able to go over it and commit at least parts of it to SVN to enable more people to join in this effort easier.

[Xav]

Here are e200v2 V03.01.16 firmwares:

http://mp3support.sandisk.com/firmware/e200/e200v203.01.16a.zip (America)
http://mp3support.sandisk.com/firmware/e200/e200v203.01.16e.zip (Europe)
http://mp3support.sandisk.com/firmware/e200/e200v203.01.16f.zip (Europe with FM Radio)

[atomikpunk]

I recently got into looking at rockbox for my M250 and I noticed that I got the V2 and no rockbox port is still available. I have some skills in electronics, programming and disassembly analysis, and since I'd really like to try rockbox on my M250, I thought I'd help where possible in the project.

So I got the firmware in some tools I got and started looking at the firmware file. For the records, I've got the american V2 version with the 4.1.08A firmware in it. I also took note of the info which badger is keeping on his web page.

First of all, I'd like to thank badger and andva for their work since it is what got me started with the firmware analysis.

It's a bit late here but I think it's worth that I share at least part of my findings up to now. So here we go:

Naming convention & Header block(s)
First of all, I also found that the firmware file for the M250 is divided in what seems to be library blocks. However, I think that what andva consider the header block is in fact composed of 2 header chunks. The first one (that I'll name FWHeader) being only 0x400 bytes long, while the remaining bytes before block 0 are what I call BlockA. So for the blocks naming, I'd mostly stay with the convention andva defined, with the following exception: I'll refer to the 0x400 bytes block as the FWHeader block, and the remaining of bytes before Block0 being referred to as BlockA.

However, I think that the "regular blocks" are only up to the empty block. After that, the block structure doesn't seem to be used anymore. In the case of the M250 firmware, there are:
1 x FWHeader block
1 x BlockA
17 x regular blocks
1 x empty block
then, there are some other unanalyzed data.

FWHeader format
This block is 0x400 bytes long and only contain 2 data structures in it, the first one present at 0x00000000 being (almost) mirrored at 0x00000200. The structure has already been described by badger on his web site, though I think I found a bit more info about it (denoted by italic rows), so here it goes (numbers between parenthesis are for the mirrored structure at 0x200):

Offset	Value(s)	Description
0x00	0 (1)	This seems to be the index of the header structure
0x04	Checksum	Seems to be a checksum
0x08	Block multiplier	This seems to be used in the calculation of the regular blocks size: [block multiplier] * 0x200 = [regular block size]
0x0C	BlockA size	BlockA actual size, counted from offset 0x400 in the file (that's why I think there should be both FWHeader and BlockA blocks)
0x10	3	A file format version number maybe?
0x14	8-bit checksum?	A 8-bit checksum? Would be redundant IMO
0x15	Model Id	Model identifier
0x16	0	Zero(?)
0x18	40	Fourthy(?)
0x1C	1	One(?)

BlockA
I didn't go deep as of now, but the first thing is that offset 0x0 of this block is an indirect branch instruction to some code at 0x4B8. I didn't have time to analyze it yet but it seems to be valid arm code.

Numeral block headers
For each regular block, a block header is also present right at offset 0x0 in each block. The block header structure can be incomplete, but the following is always present:

Offset	Value(s)	Description
0x00	String offset	Block offset to the string describing the block's content
0x04	Lower address	Seems to be the lower bound of an address range, still unknown
0x08	Upper address	Seems to be the upper bound of an address range, still unknown
0x0C	Block size	Actual size of the block "effective" data, that is where there is valid code or data

So that's pretty much it for tonight, I'll try to continue looking at the firmware when I'll have some spare time. Meanwhile, please have a look at my finding and confirm (or infirm) that it is correct. Of course Badger you can add this info to your web site as you like

Good night peeps.

Edit: Clarified the "block multiplier" description in the FWHeader structure

[saratoga]

I applied Bagder's checksum code to blocks other then the first one, but unfortunately this did not give me the checksum in the header. 

The first header is different then the rest though.  Its length is the offset of the next block relative to the end of the present header, while the others are the relative address from the start of the header.  But even making that change didn't get me the right checksum, unless i'm doing something wrong.  I also tested the theory that the subsequent headers might be smaller or larger, but starting from the end of the block and going backward printing all possible checksums didn't yield the right sum either.

Looks like more work is required.

---

Also interesting, the datasheet mentions a USB repair mode in the SOC's internal ROM that works even if the FLASH is corrupted.  Unfortunately, as I suspected you need to trigger it electrically.  According to the sheet, GPIOA bit 4 is flipped on and then GPIOA bit 0 is read to see if the "firmware update button" has been pressed to connect them during power-on.  Unfortunately, looking at the pictures, its not clear whats hooked up to that those pins in either the E, Fuze, or Clip, as the connecting traces seems to be inside the PCB.  At first I thought the JTAG connector might also go to those pins, but it looks like this is not the case on the Clip at least. 

[atomikpunk]

Here is a little update for tonight.

It seems that BlockA actually contains the usual ARM 9 vector table right off at the beginning of BlockA (0x400 offset from beginning of firmware file). In the M200 firmware, only the reset, irq and fiq seems to be handled though. All the (four) others are simply infinite loops, so if they ever happen, the device is frozen.

I'll be looking at the reset vector in the next couple of days. There seem to be some hard coded addresses in there so some input about the device memory map from those with the AS3525 datasheet would be really appreciated.

[saratoga]

Bagder:

Theres another M200V2 (or rather V4) firmware here:

http://ca1.storage.flashcp.com/sansa2/Firmware/M200/4/A/PACKAGE/SansaM200_plusA4_0_45.txt

(rename to .7z)

Firmware format looks superficially similar to the other V2 players, but I didn't look at it in much detail.

Edit:  Apparently the V2 M200 series have been out for quite a while.  That firmware update was posted on ABI in January 2007. 

Edit2:  Has anyone tried the "special MSC mode" trick on the E200v2?  The one where you plug in USB with the device off like described on Bagder's V2 page?  Seems very odd to me that it wouldn't work on the other players.

[atomikpunk]

Well I got my M250 on april 2007 so yes it's been quite a while now... _If_ there is a recovery mode or "special" msc mode, would you think it would appear in the firmware or it would be hardcoded in the hardware?

Owh and BTW, from what I saw in the m200 firmware, there doesn't seem to be checksums for "regular" blocks. I've only seen a checksum for Block A, the one at 0x400.

[Bagder]

I added that m200 firmware to the v2 page and I've tried to incorporate the more recent file format data/info we've learned.

[advcomp2019]

Edit2:  Has anyone tried the "special MSC mode" trick on the E200v2?  The one where you plug in USB with the device off like described on Bagder's V2 page?  Seems very odd to me that it wouldn't work on the other players.

About a month or two ago, I looked at this file( http://daniel.haxx.se/sansa/v2/c200/sansa-c200v2.zip ) which is on Bagder's v2 page.  If you look at those folders and if you have a v2, the special mode is just an hidden MSC mode that was in the older firmware.  Since they added USB modes to the menu, this trick looks like it does not work any more.  I tried it with my Clip.  With the Clip, it was the "Select" button and not |<<.