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

[JdGordon]

A better solution came up in irc today that the superfloppy mode should be told which sector to start at (it does already anyway, currently always 0) instead of using the SD driver to shift it. this _should_ work but hasnt been tested yet

[JdGordon]

weeee
time to join the party properly!

ATA error: -1
Press ON to debug

loading a real binary on my e200v2...


edit: commenting out some #ifdef BOOTLOADER lines andremoving HOTSWAP and MULTIVOLUME gets me to the logo... time to find out how much further

[mc2739]

I was able to get to the main menu on my e200v2. It is still not very consistent. Sometimes, I get just a white or gray display. If you hold the player at an angle, you can sometimes still see the rockbox logo. After 10 seconds, the backlight goes off. The buttons aren't working yet, but inserting the USB cable will sometimes turn the backlight back on.

I'm starting to wonder if the shared GPIO deal is what maybe causing some of these problems (at least on the e200). The display uses GPIO B & C as do some of the buttons. The button light uses GPIO D which I believe is also used by the storage. If the various functions are not checking the status of these GPIOs, and just reading or writing under the assumption that they are still in the correct state, then who knows what will happen.

Any thoughts from the more experienced?

[JdGordon]

sounds plausable :p

here is a better version of the disk sector offset patch I had up before.. this one actually works

[funman]

I was able to get to the main menu on my e200v2. It is still not very consistent. Sometimes, I get just a white or gray display. If you hold the player at an angle, you can sometimes still see the rockbox logo. After 10 seconds, the backlight goes off. The buttons aren't working yet, but inserting the USB cable will sometimes turn the backlight back on.

The SD driver is broken.
It doesn't work.
It's not finished.
It reads corrupted data.
Don't use it.
It will not be fixed by modifying 2 lines of code.

The solution might be to use DMA requests to read the data from the SD controller.
The DMA controller is luckily a (documented) PrimeCell controller, so this should be easy to write code for it.

I'm starting to wonder if the shared GPIO deal is what maybe causing some of these problems (at least on the e200). The display uses GPIO B & C as do some of the buttons. The button light uses GPIO D which I believe is also used by the storage. If the various functions are not checking the status of these GPIOs, and just reading or writing under the assumption that they are still in the correct state, then who knows what will happen.

Any thoughts from the more experienced?

This is not a problem, the button light code shouldn't be called at all as far as i understand.
And if it is called, it should restore the state of the CCU_IO register which defines if XPD is used for SD/MMC (storage) or for GPIO.

Note that to avoid potential bugs, we should disable interrupts before changing this CCU_IO register, and reenable them after we have reset it to the original value, to be sure not to leave the register in the GPIO state while we need SD transfers.


---

People, is it possible to keep this forum thread development related, and not testing related ?
It is already quite hard for newcomers to follow these 30+ pages and understand what is the  current status.

(For newcomers: the current status is in development, and not ready for use)

IMHO the port is not in a state where it benefits from massive testing.

Maybe the developers ask to try a feature once to see if the results are not different on another model, but no need to answer the same thing 10 times.

[bertrik]

Last night I tried to see if anything else was present on the audio master i2c bus of my clip. No luck, I only got the codec at address 0x46 to respond, no response at any other addresses. Tried the same on the master/slave bus and no response at all either (I did make sure that the master/slave i2c interface was enabled in the CCU_IO register and that the i/o pins were not configured for display use). I was hoping to find the fm radio chip.

I looked at the fuze firmware and it seems it does "bit-banged" i2c on some pins (i.e. doing i2c by wiggling GPIO pins). It might be worth looking into devices on this bus. The generic GPIO i2c driver already present in the rockbox sources could make this easier.

[Domonoky]

I just detected that, at least on the m200v4 the sd-driver doesnt need the CCU_IO bits modified.
So at least for the internal storage it doesnt use gpio d.

When i dont modify the CCU_IO i get my backlight back working. And as a added bonus the sd-driver is running much better in rockbox, i can now browse files in rockbox :-)

Could people with other sansa v2 players test if the CCU_IO bits also arnt need in the sd-driver ? (especially external sd-mem on e200v2 would be interesting).

[funman]

It's not needed on the Clip, but I didn't try to make the difference between modifying or not.

According to the as3525 datasheet, it should only matter when using the 'original' PL180 controller, the one used with a SD slot (on Fuze and e200, I don't know if the c200 has an SD slot).

Note that I have applied the diff of domonoky and modified it a bit, but we both still have strange results, especially panics in the fat driver, that might result from incorrect data transfers which are not reported by the DATA_CRC_FAIL in the PL180's STATUS register.

EDIT:
Disabling the irq before the data transfer gives perfect results: no overrun, no delay...
But this still causes panics in the fat driver, so the data transferred may have been corrupted.

Another problem with this approach is that we don't give back the control of the CPU to other threads or the kernel tick interrupt until the transfer has been made.
If we can fix or understand the remaining problem we might do precise timings (perhaps with a TIMER) and decide if this approach is worthwhile.

I attach a patch which disable interrupts, and does no retries if a problem happened (instead it will happily panic).
Please report if you see problems other than a panic "Updating size on empty dir entry %d"

EDIT2: the remaining problem has been fixed with a suggestion of Frank Gevaerts: the write function returned success. Making it return a failure fix the problems, I'll commit a fix shortly.

[yapper]

...I don't know if the c200 has an SD slot

It does

[Llorean]

Hi, I've just played with the clip simulator and noticed the keymap.

Is there a particular reason it's so drastically different than existing keymaps (especially the e200, which could be 1:1 mapped if you used the volume buttons in place of the wheel)?

[funman]

I think I modified the e200 keymap (replace wheel with left/right) until it built, and made a few modifications to avoid duplicate combinations.

Work on the keymap is welcome of course (I noticed that the C200 keymap is quite similar).

Note that the volume buttons are not as easily accessible as the others, so I personally would prefer if their role was limited.

[atomikpunk]

Hi everyone,

I had a look at the sansa fuze OF and disassembly pictures and, sadly, the more I look into it, the more I think the buttons (and wheel) are read using DBOP. Which would mean, it isn't as simple as the other players... I may be wrong, but the "ReadButtons" routine seems by far bigger than the other players equivalent.

However, without any hints on what I in the wheel/buttons part of the device, it is quite difficult to know what to do with it except to rewrite the same as what the OF does. Anyone brave enough to take pictures of the wheel/buttons disassembled casing?

If you guys want to have a look at it, the deepest subroutine of the "ReadButtons" routine, which in fact directly access DBOP, is located at 0x4920 in the fuze firmware. Also, the routines write the buttons state in 0x2164E.

Any progress on the SD side?

[saratoga]

Anyone brave enough to take pictures of the wheel/buttons disassembled casing?

They plug into a non-descript ZIF socket on the board via a ribbon cable.  It can be clearly seen in image 17 here:

http://www.anythingbutipod.com/archives/2008/03/sandisk-sansa-fuze-disassembly.php

Its the plain white connector with 10 pins. 

[atomikpunk]

They plug into a non-descript ZIF socket on the board via a ribbon cable.  It can be clearly seen in image 17 here:

http://www.anythingbutipod.com/archives/2008/03/sandisk-sansa-fuze-disassembly.php

Its the plain white connector with 10 pins. 

Anything more than those picts? I already saw those... My real question was "is there any serial number or something we could recognize and get a bit more info on". Anything that could be searched on google to get a datasheet or something... Or maybe it is as simple as being passive components? 10-pins, maybe that's enough for direct connections. I would guess 1 or 2 for power and the others for each button/wheel sensor.

[daniel_at]

Hi all,

I have already taken some pictures (other than the from abi) and posted the link in the wiki: http://www.rockbox.org/twiki/bin/view/Main/SansaFuze

As far as i can see: the Buttons are either matrixed or directed connected to the main-pcb but surley their is no further logic controlling them. But as you can see, on one of the pics, all outer rings are connected together, matrix'ing isnt possible at all.


The wheel, however, is a bit more complex... its not controlled by actuall switches but with two magnetic-sensible devices. And the wheel (the moving part) itself is a magnet. (if you place a strong magnet behinde the fuze, the wheel does not work anymore... unfortionally, my mount in my car works with an magnet )

So this may be sampled with an ADC or with oder complex(er) algortithms...

hope that helps a bit,
Daniel