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

[atomikpunk]

I found something very interesting tonight about the OS run by the sansa. It seems like it uses Segger's EmbOS. I found at least one evidence of this in the signature of the tasks creation routine. They are particularly recognizable and they are perfect match with the homologous routines in EmbOS. However, I still don't know the compiler used as EmbOS supports multiple compiler environments...

I hope it'll make analysis much easier by having routines documentation at hand...

I'll try to update the wiki when I can so others will be able to keep up to date with findings (and possibly contribute). Until then, good night

[embrion]

You rock I can't wait to switch my Nano to Sansa Fuze
Austrian hardware + German OS. Makes sense
My findings:
1. As AS3525 is ARM9 than according to  http://www.segger.com/emboscpus.html , You got 6 possibilities. At least KEIL got very nice simulator, so we could test a more or less simple code (check memory jumps and stuff  might be useful I think but I might be wrong because I did embedded only once in my life at school)
2. Those trials on Segger's site are only add ons for compilers but got included 2 very nice docs about ARM7/9 usage with embOS. I believe there shoul be trials of those compilers on manufacturers sites. At least Keil's uVision got trial version.
3. KEIL is very popular so I'd check it in the first place + 1 got some god feelings about it.
4. http://www.segger.com/jlink.html (a lot of text + some screenshots = might help with flash memo layout and/or jtag pins and/or anything else)
5.  I googled some guy's resume:

Worked on basic radio functionality for a prototype of the latest XM radio using ARM assembly, C, C++ running under Segger's embOS RTOS. The CPU is an Arm922t core as part of a System-On-Chip built by Austria Microsystems (AS3525)

[atomikpunk]

Haha thanks for the great words.

Yes I downloaded trials of the embOS and the package includes a very nice doc, at least providing most (if not all) of the API with signatures, description, etc. Very valuable

What I would suggest for finding out the compiler used is to compare C runtime and C library output from the various compilers with the one present in the firmware. I already found out what seems to be the strncmp function in the firmware so if someone could provide with the assembly output of the various compilers, we could compare with the firmware and see which one it is...

Anyone willing to look at the firmware, feel free to contact me via private message so we can get in touch on jabber/msn/icq.


Edit: After looking a little more into it, it seems more and more possible that EmbOS version 3.32 (or earlier) was used. I'm coming to this conclusion from the structure members that moved between versions and the one that truly match the M200 4.1.8A firmware looks like EmbOS 3.32.


Edit 2: (Damn anti-double-post) After looking at the GPIO ports usage in the firmware, it seems to me that the buttons reading is done in a keypad-like manner using port A. A[3:0] seems to be used as inputs while A[7:4] seems to be used as outputs. The routine at 0x32B4 (in the M200 4.1.8A firmware) seems to be the scanning routine, checking all column/rows combination and thus giving out a 16-bit mask of the "keypad". This would also explain why Daniel said that there are switches connected to resistor "networks".

That being said, I guess that it would be interesting to: 1) be sure that this button reading method is used on all V2 sansas, and if not, what is the button reading method for other models, and 2) identify which buttons are connected to this "keypad" and which one is where. Once we are able to recognize buttons, it will be possible to create dual-boot images

[embrion]

Good thinking
If there will be any problems with identifying which button is which, than You could always set official firmware to boot as default without key combination, Rockbox as alternative when button press and hold + use hit and miss method for finding correct key code by trying different codes in boot loader and pressing always the same physical key It's a lot safer approach as long as boot loader won't brake possibility to boot official firmware 

[atomikpunk]

Well good and bad news this morning.

The good: I was able to run linuxstb's sleep code on my M200.

The bad: There is a place in the code where the GPIO pin A3 is used as an input and it looked like a button to me. So instead of trying to implement the scanning routine for the "keypad" buttons, I thought it would be easier and safer to try to look at one GPIO directly. So I coded a very simple routine that:
1. Enable the GPIO hardware
2. Made port A an input (since all pins are input, except in the keypad scanning routine where A[7:4] are made outputs temporarily, then back to inputs)
3. Read pin A3
4.a. If the pin read 0, then wait for 0x500000 units (which correspond to ~5s in linuxstb's code)
4.b. If the pin read 1, then don't wait
5. jump to the original firmware reset handler

I don't know why, but my M200 is bricked now. I looked and looked at my code, then loaded it in the disassembler to be sure that it was ok, also looked at my automatically-generated routine graph to be even more certain that nothing was wrong, but still there is something that I missed... :'(

It's shocking but on the other side, I knew it was risky to try so I learned from my mistake... But the problem now is I don't see much interest in pursuing my work on this since I don't have a player anymore and I don't think I'll be getting another in the near future... But nonetheless I think I'll continue reading (and posting) on this forum, at least for a while, who knows what can happen (JTAG anyone? )

[Bagder]

atomikpunk, if you get in touch with me I think I can promise you compensation from the Rockbox fund if you do decide to buy a new one and get back into the race.

[daniel_at]

If someone has a "officially" bricked device, and dosent care to wait for some debricking solutions (did not make any progress with the JTAG port), the device would be a good candidate to desolder the AS-Chip and make some measurements. Direct connections to switches or if the already posted JTAG Pinout is correct and other Pin-Assignments.

If someone wants to ultimately brick is SansaV2: Conntact me, I can give you some hints how to "carefully" (as possible) desolder the Chip.

Daniel

[atomikpunk]

Hi everyone,

I really appreciate all of your support, it's really great to see that what we do is appreciated too.

Just for the info, I found out what the problem was with my firmware and no surprise it doesn't work: I used an AND instruction somewhere instead of a ORR and it resulted in disabling the ext. memory clock (Really good move AMS to put the ext. memory clock enable on the same register as the GPIO enable. Bha sorry it liberates me, really it's all my fault on this one )

But now there's a couple of ideas on my mind. I'll think about those a bit more so I don't get things worse than they are now... But what's really tickling me is the idea of trying out the internal boot loader. I wonder if it's possible to run it, and if so, if we would be able to do something with it. It's supposed to be selected by only one pin which should already be pulled up. I wonder if I could use a strong pulldown to make the device load the internal bootloader... And if so, I wonder what would be available in this mode and if it could be used as an unbricking method.

Ideas/comments on this?

BTW LLorean, if you feel like sending one my side, it would make my day (but I'll understand if you don't/can't)

I know it's a little off-topic but if anyone know good deal pleaces for sansa M2X0, clips or E2X0 that will ship to canada, please send those to me in private messages, thanks. The only ones I know are amazon, futureshop, ebay and stuff like that...

[daniel_at]

Hello again, today i made some progress to find a unbrick-solution to help the developers getting started.

The datasheet says that the SoC will boot from the internal ROM if:
 a) The XPC[0] is "1" _or_
 b) The Chip fails to boot from external flash.

I searched for that pin quit a long time - but wasnt lucky so far... so i tried to look for exploiting point b). And luckely it worked after few attempts.

Under on flash-chip i found (again) two unassmblied pads - i dont know what pin it belongs to, bec. i couldnt find a datasheet for the flash... but i hoped that it is smth. like ChipSelect/Enable or an address-pin so that the flash would not respond in the planed way.
I have marked the bridge on this photo:
http://flickr.com/photos/90053035@N00/2495460818/in/set-72157605072639496/
([All Sizes] for a higher resolution)

After (only temporary) bridging it and plugging the Sansa (from OFF-State) into the USB-Port the screen and the wheel stayed dark. I un-bridged it (so that the flash should work now again).

Than the funny moment: lsusb...

Code: [Select]

Bus 001 Device 030: ID 0781:6200 SanDisk Corp. 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x0781 SanDisk Corp.
  idProduct          0x6200 
  bcdDevice            4.02
  iManufacturer           6 SanDisk
  iProduct                7 M200Plus
  iSerial                 8         i 0744703011
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          9 config1: Mass Storage only
    bmAttributes         0xc0
      Self Powered
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk (Zip)
      iInterface             10 ms ifac 1 (SCSI::BULK_ONLY)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0001
  Self Powered

And thats it... this is a different DeviceID and complete different lsusb output than my normal one... one funny thing: my device is a E280, but the code from internal boot-loader says it is a "M200Plus". Okay - The internal Bootloader is a masked-PROM (so its "programmed" while the chip is factured) and therfor it is cheaper to use the same mask for all SoCs (i guess).

Okay - and what is with the USB-Massstorage device: fdisk showed a size of ~1024MB (normaly the dvice has 8GB), but no valid partition table.

I dumped the whole drive to a file and examined it afterwards with an hexeditor... and voila, from offset 0 ther is the same data which can be found in the firmware-files. :-D
I havent compared the dump exactly against the OF-files - but the first headers/and instructions are the same.
Okay.. the soultion is so far not very applicable (because you have to open the device, and i only kow that it works with the E200), but if you have bricked your device (atomikpunk? ) it is sofar the only solution... Maybe ill find a better soon

Okay... quick resume:
 *) Open device
 *) power off - Usb unplug
 *) search that said pair of pads near one of the flash-chip
 *) bridge it (but not permanetly (i.e. solder) - just press a copper wire above them)
 *) plug the USB in (I had problems on a USB2.0 port.. maybe try a USB1.1 if it dosent work)
 *) The sansa should _not_ light up (display and wheel)
 *) but the computer should report a device pluged in (dmesg or beep in win)
 *) unbridge the pads again
 *) open the whole device (/dev/sd?) in a hexeditor (in linux... in win=?)
 *) ? ? ?
 *) profit

But i guess SanDisk has planed some easier (non-invasive) way to call the intern EPROM-Bootloader... maybe ill find it

HTH
Daniel

[andva]

Excellent find! A suggestion: maybe if the Sansa utility is running while you plug in the "bricked" device, it will recognize it and do something - hopefully restoring the firmware from the factory one. If that works, that would be an effective unbricking strategy.

PS: My sympathies for atomikpunk, that really sucked Although it's not much, I have just tipped in $30 for the "Rockbox Fund" to partially make up for the bricked player (and to support a small fraction of your awesome work, of course)...

[atomikpunk]

Wow that's great news Daniel! I looked at the M200 PCB pictures on the wiki, and there are a couple of unsoldered resistors too. There is one particularly attracting one near the JTAG connector, I guess that it will be my first look. If it works, the next thing to check will be to modify a byte or two in there to see if it will unbrick my player. I think however that I'll play safe and use a 10 or 100 ohms res. to short the pads, one never know

Owh and BTW, on the (few) NAND flash datasheets I looked at that are TSOP-48, the pin which is connected to the resistor you jumped (pin 19) is almost always the write protect (/WP). So it's a bit confusing as of why it works, but maybe that pin is also connected somewhere else...


Edit: Ok I did try the same procedure and was able to see a plain'ol mass storage device in lsusb. However, unlike you Daniel, I have a device which shows up as being 0MB. I, however, only have USB 2.0 ports on my laptop so maybe this is the problem. Here is a snap of the interesting dmesg backlog:

Code: [Select]

usb 4-1: new high speed USB device using ehci_hcd and address 4
usb 4-1: configuration #1 chosen from 1 choice
scsi12 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 4
usb-storage: waiting for device to settle before scanning
scsi 12:0:0:0: Direct-Access     UNDEF    storage          1.0  PQ: 0 ANSI: 0
SCSI device sda: 1 512-byte hdwr sectors (0 MB)
sda: Write Protect is off
sda: Mode Sense: 00 00 00 00
sda: assuming drive cache: write through
SCSI device sda: 1 512-byte hdwr sectors (0 MB)
sda: Write Protect is off
sda: Mode Sense: 00 00 00 00
sda: assuming drive cache: write through
 sda:<6>sda: Current: sense key=0x0
    ASC=0x0 ASCQ=0x0
 unknown partition table
sd 12:0:0:0: Attached scsi removable disk sda
usb-storage: device scan complete
sda: Current: sense key=0x0
    ASC=0x0 ASCQ=0x0

The lsusb output is the same as yours if I use my usb ports as usb 1.1 (by rmmod-ing ehci_hcd). Maybe there is something with my linux box? So I'll try simply rebooting in windows to see what happens... (2s)


Edit 2: Well, on windows, it is detected as an "M200 Plus" device and windows installs 2 (UNDEF) drives. If I try to right-click on them, the first one seems to freeze explorer for a bunch of seconds, while right-clicking on the second one simply gives out that the drive is 0 bytes large with 0 bytes free. So it seems that there is still something missing on my side.

Any ideas out there? Daniel, you said that "I had problems on a USB2.0 port.. maybe try a USB1.1 if it doesn't work", what kind of problems did you get? Was it similar to what I'm getting now?

Owh and BTW, the M200 "bootloader" unsoldered resistor is the one right between the "repeat" button and the little battery...


PS: thanks everyone for the nice words, I really appreciate your support

[daniel_at]

Hi atomicpunk & others,

Cool that you tried the procedure also with your device and I think its a good sign, that it works basically... Okay some ideas:

*) How did you (un-)bridge the pads? Maybe it is a timing problem, I dont know if i just had luck, but it worked three times in a row (only tried it 3x).
*) I have two Flash-Chips in my Sansa - how many have you? Maybe that is important... Maybe the bootloader OF is on the other one, and i just block (writeprotect?!) the other one.
*) What does "sudo fdisk -s /dev/sd?" say? or "sudo od /dev/sd?"
*) Under Windows: do you know WinHex ( http://www.x-ways.net/winhex/index-m.html ) - Very neat hexeditor (can open devices directly)
*) My proplems with USB2: did not work at all... the sansa booted into the OF - it gave me some thoughts "why?" and "how?"... But maybe I also had a problem while bridging the pads (bec. my computer with USB2 is in an other room - so i used other tools)
*) The computer which worked is a "native" USB1.1 (Notebook from the year 2000)

Okay.. thats all for now - would be glad if we get you (atomicpunk) back into the race

[edit]
I yesterday also tried to find other ways to enable the internal ROM-booldr.: I thought it would be reasonable that SanDisk put that XPC[0] Pin onto the Sansa-plug. So that a technican can flash the sansa with a special plug. Tried to pull up each pin up (one-by-one, with an external powersupply) and plug it into my USB: no luck. Than i though somewhere where it is easy reachable... There is a plastic-shield which is only glued above the battery: tried to pull up some pads, or bridge some resistors: no luck. Maybe some pin within the SD-Card reader.. so that you have to use a special crafted SD-Dummy... no luck.
But i wonder that my Sansa still works
[/edit]

CU
Daniel

[JD24]

Nice find on the recovery thing daniel!

I read somewhere else that someone did enter the recovery mode with bridging
2 of the NAND datapins on startup. That could makes sense because
the cpu cannot read the flash correctly then.

EDIT:
I found the link:

http://s1mp3.org/en/docs_deadrec.php

JD

[scharkalvin]

you may be able to find a real small surface mount spst push button switch that
can be soldered across those two pins. 

[andva]

I know it might be a really dumb suggestion, but if the pinouts for the SoC are standard (and thus available in the datasheet), the XPC pin may be exposed (as in, available to poke directly) somewhere.

If I'm not mistaken the SoC (at least for the e200v2, but hopefully the same for them all) is the square chip in this image (pictures already posted by Daniel):

http://www.flickr.com/photos/90053035@N00/2495459364/

Then, you may identify most of the pins making it through to the other side (I suppose the PCB is multilayer, so apparently not everyone is, though):

http://www.flickr.com/photos/90053035@N00/2496918368/

EDIT: It looks like he already did that!

http://www.flickr.com/photos/90053035@N00/2586759595

Now, anybody know what the correct pin is?