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

[daniel_at]

Hello... I was indeed working on that approch - but somehow none of the accessible pins (i have tested) make sense compared to the description in the datasheet... Non of the JTAG pins are connected to any of the pins from that connector...

Tested some of the dbop_d (Display port data) pins  - none seem to be connected with the LCD  (Bec. the XPC[0] Pin is also a dbop_d Pin...). But some supply pins i measured were okay.

So there are some possibilities
 *) I mixed up the pin-numbering (i am dyslexic ) (but i tried rotated and mirrored versions of it)
 *) This is a multilayer with not-though-all-layers-vias (dont know if that is possible?)
 *) Sandisk has a ordered a special Pinout for the chip
 *) My DMS is playing tricks on me...

Dont know - maybe someone with an other hardware could give it a try...

Daniel

[atomikpunk]

Hi Daniel and everyone,

- yes indeed I tried multiple "delays" between my USB connection and the unbridging of the pads, but it doesn'T seem to change anything...
- the M250 have a single flash chip, but I did probe the pad and it "beeps" on both flash pin 19. This means that both pin 19 are pulled down simultaneously when the pads are shorted
- I tried using fdisk /dev/sda and the message is "unable to read /dev/sda", fdisk -l /dev/sda yields nothing at all, but I didn't try fdisk -s
- Thanks for the hex editor link, I was used to frhed, but I'll give it a try someday

But btw, if you want to try looking at XPC[0], you must pull _down_ the pins, not pull up The bootloader is actually called on low XPC[0], and the unsoldered resistor has a pad to both chips write protect and the other connected to ground, so this is definitely a pull down.

And looking at your pictures, you seem to have the good pinout. However, just in case, did you remove a bit of the protective screen before probing the vias? Or used a needle to probe through it? Because the protective green screen is isolant... I also know that it is possible to have partial or hidden vias, but it grows the production cost so most production will try to stay away from that except when absolutely needed...

andva: "EDIT: It looks like he already did that!" He = daniel_at

[daniel_at]

Hello...

Pull down? Why do you think so?

Code: [Select]

XPC[0]
BOOT LOADER source select input
1: internal ROM
0: external ROM/Flash
(see also p21)

Or did I miss somewhere a "not"?

> - the M250 have a single flash chip, but I did probe the pad and it "beeps" on both flash pin 19. This means that both pin 19 are pulled down simultaneously when the pads are shorted

Sorry, I dont understand that sentence fully... One flash... both "pin 19" - [edit]err... just understood it... You have a place for a second Chip  on your pcb? Okay ... that makes sense [/edit]

Youre idea about the writelock seems to be true - i googled some (other) datasheets for 32Gbit-TSOP48-Flashe-Chips and they all have \WL on pin 19... Dont understand why that leads to a failed boot - maybe an other pin is also connected to that net.

Maybe youll brave enough to try a method noted by JD24 - there someone just shorted all 8 IO-Pins while booting the player (not a SanDisk at all). Usually it should be enough to ground one or two pins, so that the internal bootldr wont get the correct headers. BUT I dont know what the I/O-Drivers of the SoC would think about it

>  did you remove a bit of the protective screen before probing the vias?

Yep - i did... i have grinded a very sharp needle-probe for my DMS for that things... And i had connections to most of the pins - but with very high-impedance -  so no direct (copper) connection.

Daniel

[mitchlr]

Atomicpunk,
Did you get a replacement player yet?  If not, perhaps a couple of us who lack the ability to work on the project can see what we can do to get one to you.
Kindest regards,
Rob

[atomikpunk]

Hi Daniel, Rob and everyone,

Well the unsoldered pads is definitely for a pulldown resistor because one of its pad is tied to ground (I probed it while unplugged and measured its voltage while plugged). But I think you are right, when XPC[0] is high, the cpu is supposed to boot on internal ROM. So there is something we miss in the circuit...

Yeah sorry I wasn't clear, there is effectively 2 flash footprints on the PCB, but on the M250 there is only 1 x 2Gb chip soldered.

About my player, thanks everyone's support and particularly for Bagder (in rockbox's name), which came with a very generous replacement offer to me so that I'll be able to get a replacement player very soon.  [shameless_plug]It's all possible thanks to the generous donators, so as Rob said, if you aren't able to contribute technically with the development, you can all do your part by donating to the project.[/shameless_plug]

But this is also very good news on the "hardware investigation" side because I'll be a little less shy trying things with my bricked player.

[amaldo]

I would like to confirm that shorting the two pads near the flash-ram-chip boots my Sansa e250v2 into the 'special' mode. This works fine in my Linux machine with USB2.0 (The ehci module reports the connection)

I also see a 1027342336bytes (980MiB) drive, and the beginning seems to be exactly the same as the firmware file I installed (e200pe.bin). I haven't tried writing to it yet. Does anybody have a patched firmware with a delay at bootup, so I could try writing it into the drive?

The USB ID is: 0781:6200 SanDisk Corp. (Sandisk M200Plus)

Trying to get JTAG to work has not been very successful. I followed the pinout that hth posted in this forum, but the TDO pin is stuck at 1 (actually 2.4V instead of 3.1V). It might be related to the empty solder pads next to what we think are the JTAG pads. The bad news is that after looking at the pinout posted here (http://www.flickr.com/photos/90053035@N00/2586759595/sizes/o/) by Daniel, none of the JTAG pins from the Datasheet are connected to those pads behind the screen. Am I missing something? Maybe a buffer circuit in the middle?

Edit: The pinout as suggested by Daniel seems to be ok, I tested the power pins, and they are in the right place:

A15  = 3.1V
B15 = 0V
K1 = 1.2V
L1  = 0V

Have a nice weekend!

[andva]

Excellent work, everyone!

Does anybody have a patched firmware with a delay at bootup, so I could try writing it into the drive?

I think that there is none yet for the e200v2 series, but you could always try writing an old version of the firmware and checking the version after rebooting to confirm that it has been updated. Bagder keeps an archive of several versions in his homepage:

http://daniel.haxx.se/sansa/v2.html

best regards - andva

[daniel_at]

@amaldo:

I already mentioned that i have not found any reasonable connection to that maybe-JTAG-pins. Can you probaply check if I made an error within my numberation of the Pins (rotating/mirroring)?

But maybe Sansa had ordered a special designed BGA-Package. At least they have a special PROM-Mask and a own Package labeling - but i see no reason for that... may be not that cheap..

Daniel

[embrion]

I checked disassembled Clip and Fuze and I can't see any candidates for jtag pins on Clip and maybe one on Fuze. Is it possible that they're just not on the PCB? Also, maybe Sandisk use jtag via their proprietary port? It would be convenient for service as disassembly wouldn't be necessary. Something like this http://www.segger.com/jpg/sam_ice.jpg
Can't we just direct solder into correct pins of SoC ? We got docs of it and the chip itself got jtag support  http://www.austriamicrosystems.com/03products/products_detail/AS3525/download/block_diagramm.gif

I'm still looking for something that would help people working on the jtag. As we know now, v2 uses Sagger embOS. Sagger also sells SAM-ICE and J-Link jtag simulators. I'm trying to find some schematics. For now, I found something about mysterious missing resistor. Check this http://www.atmel.com/dyn/resources/prod_documents/doc6206.pdf. Apart from described pinouts at page 2-1,2-2, the document also says about removing resistor at page 8-1. I know they remove it from J-link itself but maybe it is something?

[atomikpunk]

Hi everyone,

I agree with caladan that probably emFile is used, and I guess emUSB is also a valid hypothesis. However, I doubt emLoad is used since I simply don't the use of it when USB is available.

Concerning pinout, I'm really puzzled by all of this, I simply don't understand why pinout would be different from the original chip pinout. I thin it would also be quite difficult to change the pinout of parts of this complexity, geographically speaking.

Have we measured for capacitors between jtag pads and expected processor pins? I guess the next step on the hardware side is to probe everything we can and share results. I will gladly probe mine and share results when I'll have time to do so. As for the buffer you mentioned Amaldo, well I don't see one on the PCB, but there could be one somewhere in the processor chip maybe...

Andva, if you're adventurous, their is a patcher on SVN that you could use to patch your firmware with the delay. Have a look in utils/AMS/hacking.

Anyone with another V2 kind tried the "resistor shorting mode" on their player? 'Cause up to now, only people with E200 have made it to see a non-zero drive...

[atomikpunk]

Just a small update to the wiki listing all the GPIOs (we know of) that are used in the firmware and their deduced usage.

I'm still thinking about how we could inject more than a couple of bytes into the OF to insert a rockbox bootloader, but I've not much progress to report so far... If you've got ideas on this, please share them! Of course, when we'll find a button we can easily read at boot, it will be WAY easier to test because we will be able to test some code without the risk of bricking (more) devices. We could try the keypad scanning algorithm, but there's a bunch of instructions in there, maybe we could clean it up a bit and use that?

Owh and just for the records, I've tried to bridge 2 I/O pins on the flash like it is suggested on S1MP3.org to make the SoC think the flash is corrupted. This was in order to load the internal bootloader. I've used a 100 ohms resistor without success so far. I also tried grounding some I/O pins, one at a time, via that same 100 ohms resistor, also without success... I'm a bit shy at trying it directly with a wire, fearing that I'd burn the chips drivers or something...

I'd like to help you guys probing the supposedly JTAG pins but on the M200 series, the LCD display is soldered directly above those pins If I may suggest, probe the connector pins with every components, like resistors and capacitors... Maybe we are just missing passive components on the JTAG path...

[daniel_at]

Hello all...

Had today again some time, which I spent infront of my e200-V2.

I tried for the first time to write to the partition exhibited by the special mode - and: It works!

 * Just modified some bits in the "DEAD-BEEF"-areas
 * unpluged the device
 * started in normal mode: works.
 * unplug again
 * start in special-mode
 * check if it is still modified: YES
(no battery was connected, so it was really modified in flash)

So if anyone has some time to provide me with modified firmwares who has no e200, I am willingly available for testing them. Just conntact me by this thread or by PM. Best would be to test the modfications via IM in "realtime".

Daniel

[andva]

That's excellent, Daniel. I haven't yet gotten around to using atomikpunk's tools, but if you feel adventurous, you may try writing a different version of the firmware to the device to see if it is updated. Bagder keeps several versions in his website: http://daniel.haxx.se/sansa/v2.html

Thanks for trying, keep up the good work!

[atomikpunk]

Hi Daniel,

this is great news! I'm more than willing to help you test some stuff on your e200 if we get to be online on jabber at the same time I'll write a couple of tests we could try... I'll also bring an wall-powered USB hub from work to see if power was the problem with my m200... If not, I'm really clueless about the problem I'm facing with this one...

Any update on the JTAG stuff? I'm about to build a wiggler JTAG interface and try to test it on my side...

Also, I've a couple of minor findings I'd like to put on the wiki, but since the graph plugin does'nt work, I'll wait a bit... But everything is minor, nothing of big interest to report yet.

BTW, I got myself another sansa from ebay but unfortunately, it's a m200 v1. I'll try to see if someone is interested in trading with a v2, maybe in the sansa v1 port forum or something... Or if someone here wish to trade, contact me via personal messages!

Francois

[daniel_at]

Hello atomikpunk,

I have played a bit with motified firmwares. I use the utils/AMS/hacking tools from Dave Chapman from the svn.

I have modified the test.S:

Code: [Select]

.equ AS3525_GPIO1_BASE, 0xC80B0000
.equ GPIO3_DATA, (AS3525_GPIO3_BASE+0x0000)

.equ AS3525_GPIO3_BASE, 0xC80D0000
.equ GPIO1_DATA, (AS3525_GPIO1_BASE+0x0000)

/* This value is filled in by mkamsboot */
originalentry:   .word   0

        /* A delay loop - just to prove we're running */
ldr    r1, =GPIO1_DATA
ldrb   r1, [r1]  /* Load GPIOC-Data into r1 */
        tst   r1, #0x10   /* check if .. is set */
bne    noloop

        mov   r1, #0x500000       /* Approximately 5 seconds */
loop:   subs  r1, r1, #1
        bne   loop


        /* Now branch back to the original firmware's entry point */
noloop:        ldr   pc, originalentry(tried different Bit-Masks....but not all)

But I did not get any results so far - the delay always happens. Which is already a good step, which says that my sansa runs my modified code.

But i also have some strange behaviour: the first boot after a fw-update (via my "special-mode"-methode) takes about 30seconds until the "Sansa"-Bootlogo comes up. Each consecutive start takes about 7seconds (with delay) or 2 seconds (without delay, removed within code)

I tried to analyse the patched firmware in the disasm... But i have some problems to get it doing what I want... Your help would be appreciated Just ping me, if you see me online - would be great.

Daniel