Rockbox Development > New Ports

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

<< < (23/386) > >>

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: ---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
--- End code ---

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)...

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version