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

[RockRabbit]

Thanks kugel.

I have mapped the MicroSD present pin -> A2 (high), and the USB present pin -> A1 (low). I have write access to the twiki so I will update the hardware mappings myself tomorrow, but you can do it if you want to.

I have run tests now against almost all the pins (all but two). The only button I can detect apart from the power button is the right button which is detectable on pin C6. It looks to me like this model might have the row/column scanning structure like the clip and the m200. I am guessing that perhaps the right button is detected because of default values on the row driver pins. I note that the button mappings are the same for the clip and m200. The ports are different but the row/column arrangement is the same. If so that might mean that the input pins are C5 thru C7, with the right button showing on C6, the middle pin, as with the clip and m200. But this is pure speculation.

Any suggestions about what to do next will be greatly appreciated. I would very much like to be able to disassemble the OF, but arm-elf-objdump objects to the format of the OF bin file. Any ideas?

thanks 

[kugel.]

Great news!

What to do next? Integrate the c200v2 into the Rockbox tree, so that we can use bootloaders, which are save and where we can use C code.
It could well be that it's using a keyscan matrix. But it could also be direct connections. Note that e200v2/Fuze also have Right on C6.

Oh, and we should bug linuxstb to edit mkamsboot to support c200v2.

[gabe565]

Kugel: Are you sure that the Fuze and the e200v2's right keys are on C6? On the hardware mappings page, it says down is C6 and right is C5. I also have write permissions to the Twiki, so I can update it if you want!

[kugel.]

Not anymore I just misread sorry.

[RockRabbit]

Great news!

What to do next? Integrate the c200v2 into the Rockbox tree, so that we can use bootloaders, which are save and where we can use C code.
It could well be that it's using a keyscan matrix. But it could also be direct connections. Note that e200v2/Fuze also have Right on C6.

Oh, and we should bug linuxstb to edit mkamsboot to support c200v2.

Can you tell me where the experimental Rockbox code is? Or is it simply the latest version in trunk?

I might like to attempt this for the fun of it, even if my code is not used. However is there a proper way to do this, e.g. is there someone who is delegated to do this kind of thing?

I have a copy of the current version of mkamsboot, and it looks fairly straightforward (peels of laughter sound from around the world) to add some c200 code to detect the USB cable. Presumably I could mod that and test it even without anything else rockboxy being on the player.

One last question - is it possible that the other buttons are hooked up to GPIOC and I simply stuffed up the code when I was looking for them? Or in other words, is there a possibility that some other setting is interacting with the port that stopped the other pins working?

One even laster quesrion - Is it possible to dissassemble the OF (C200PA.BIN) using arm-elf-objdump?

[kugel.]

Can you tell me where the experimental Rockbox code is? Or is it simply the latest version in trunk?

Yes, the SVN is developement and experimental at once. Only for release the code is branced.

I might like to attempt this for the fun of it, even if my code is not used. However is there a proper way to do this, e.g. is there someone who is delegated to do this kind of thing?

Not that I know of. But just look at the source and the target tree system, and even the SVN history when other ports got their initial commit. It's quite easy.

I have a copy of the current version of mkamsboot, and it looks fairly straightforward (peels of laughter sound from around the world) to add some c200 code to detect the USB cable. Presumably I could mod that and test it even without anything else rockboxy being on the player.

As far as I know, mkamsboot doesn't contain the dual boot. It's the dualboot.S files in there which contains the dual boot functionality. You need to edit that too to have proper dual boot. mkamsboot handles patching your OF with the dual boot and the compiled bootloader (see here why dual boot works independently of the bootloader).

One last question - is it possible that the other buttons are hooked up to GPIOC and I simply stuffed up the code when I was looking for them? Or in other words, is there a possibility that some other setting is interacting with the port that stopped the other pins working?

It's possible. And it doesn't necessarily suprise me if there are buttons you didn't find. On the Fuze, I haven't found a single button using the method you used, even though there're at least 6 buttons directly attached to GPIO. You can actually feel lucky that you found so much.

One even laster quesrion - Is it possible to dissassemble the OF (C200PA.BIN) using arm-elf-objdump?

Yes. You can use this command: arm-elf-objdump -D --target binary -marm C200PA.BIN --start-address=0x400 --stop-address=0x20000 -Mforce-thumb > disasm.txt

--start-address skips the firmware header which doesn't contain code.
--stop-address=0x20000 limits the disassembly to not go beyond that adress, so that you don't get the whole libraries(codecs,drm stufff etc) disassembled, but only the main firmware(the interesting part). Note that the output is thumb code, not ordinary arm code.

[gabe565]

Kugel: OK, I was just wondering if you messed up or if the wiki was messed up!  

Until we know if the c200 uses a keyscan method like the Clip and m200, I'll just add the right button to the hardware mappings page as C6.

EDIT: Nevermind, Kugel covered everything I said except he worded it a little better...

[RockRabbit]

Is it likely that some of the buttons have been wired to output pins on the IO ports, such that the button must be "energised" by setting a particular pin to output before it will be able to signal the input pin? this way the buttons would be hidden and much more difficult to locate? Has this happened before?

[gabe565]

I don't know of this happening in any Sansa devices before, but it is possible. I don't know how you would find them this way, do you?

[kugel.]

Is it likely that some of the buttons have been wired to output pins on the IO ports, such that the button must be "energised" by setting a particular pin to output before it will be able to signal the input pin? this way the buttons would be hidden and much more difficult to locate? Has this happened before?

That's surely possible. You're trying to read without anything being initialized by an OS. You're in a state between ROM and an actual bootloader of Software. It might be that e.g. the lcd needs to be initialized which itself then makes it indirectly possible to use other GPIOs and stuff.

And again, I didn't found any button for my Fuze with this method.

We actually have enough now for building a bootloader, so I wouldn't focus too much on this any more. Our bootloader will already have system initializations and hardware setup (kernel_init(), system_init()) that is already nicely implemented for the other AMS targets.

[RockRabbit]

We actually have enough now for building a bootloader, so I wouldn't focus too much on this any more. Our bootloader will already have system initializations and hardware setup (kernel_init(), system_init()) that is already nicely implemented for the other AMS targets.

I'll wait till someone else is able to do that - its beyond my capabilities (at least at the moment) - and i'll pick up again when its done. I'll be glad to do whatever I can once there is a proper dual boot setup for the c200.

In the meantime i'm building a test bootloader that has subroutines that will flash the button light a set number of times (almost complete) that will enable multiple conditions to be tested in a single pass. It might actually be useful but if not its good practise for me with arm assembler (getting to grip with subroutine linkage and stack handling).

If anyone out there wants me to try something out on my c200, please let me know.

[atomikpunk]

Hi peeps,

its been a while, but I finally got some spare time to look back at the OF and investigated the buttons for the e200/fuze/c200 targets. As I previously said, the OF reads those buttons using DBOP. But we are also able to read some using GPIOs. It tickled me for some time but now I got an explanation for this and it is a shame I didn't notice before: some GPIO pins are shared with the DBOP data lines!

This basically means that it "should" be possible to read the buttons using either the GPIO or the DBOP. However, DBOP also controls some control lines which could theorically be wired to devices chip select pins and such. This leads me to recommend using DBOP as in the OF for reading the buttons on those targets. This is only a couple of lines of code really, but it needs to be carefully put together. And as a bonus, maybe using DBOP will correct some of the current LCD/whatever bugs some people see with those targets.

I already sent a (commented) disassembly source to kugel which will look into and probably create a test code with it. If anyone is seriously interested in it, I could also send it through PM, but sadly (for legal reasons), I won't post my disassembly here.

I still read and contribute this thread but I don't have much time these days to write so feel free to comment/write to me if you need more help, I'll be glad to do what I can

[kugel.]

RockRabbit: I put up http://www.rockbox.org/tracker/task/9679 so that the c200v2 is integrated into the source. Note that most is guess work (which is fine for now), but we need to know the particular memory size.
Please patch your c200v2 with a stock OF named "c200pt.bin", this will hopefully enable the diagnosis mode, in which the memory size is stated.

Play around with my patch, but beware that it is completely untested. It may or may not brick (one of) your c200v2.
It'll at least build a bootloader with loops after doing init stuff.

I've made dualboot.S so that it boots the OF if USB is inserted or RIGHT is pressed. That's based on the information your findings.

atomicpunk: Thanks again!

[Hillshum]

Could some folks who have loaded modded firmwares on AMS sansas please see if DRM still works? I seem to have broken my Sansa's DRM support by doing so. If this is really the case, then e200s are not fully recoverable.

[RockRabbit]

RockRabbit: I put up http://www.rockbox.org/tracker/task/9679 so that the c200v2 is integrated into the source. Note that most is guess work (which is fine for now), but we need to know the particular memory size.
Please patch your c200v2 with a stock OF named "c200pt.bin", this will hopefully enable the diagnosis mode, in which the memory size is stated.

Play around with my patch, but beware that it is completely untested. It may or may not brick (one of) your c200v2.
It'll at least build a bootloader with loops after doing init stuff.

I've made dualboot.S so that it boots the OF if USB is inserted or RIGHT is pressed. That's based on the information your findings.

atomicpunk: Thanks again!

You'll have to explain further about c200pt.bin. Where do i get it, and where did it come from?

Is there a way I can mod my bootloader code to ascertain how much memory the thing has? I really dont want to risk bricking it at this early stage if possible.