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

[Hillshum]

Take an OF image from wherever, name it c200pt.bin, and load it on sansa. Go to Settings>Diagostic and follow that.

[RockRabbit]

Take an OF image from wherever, name it c200pt.bin, and load it on sansa. Go to Settings>Diagostic and follow that.

thanks

I ran the diagnostics - dram size shows as only 2MB. From version 1 to 2 we seem to have dropped 30 mbytes. Is that a show stopper for some of the more advanced rockbox functionality?

I have a bootloader which tests for a button press in a continuous loop. If i press the button that is being detected in the loop, the loop detects the button press continuously, even after one single press. Somehow the pin is not being reset. However the code appears to do this:


           ldr   r0, =GPIOA
           mov   r1, #0
           str   r1, [r0, #0x400]
           ldr   r1, [r0, #(1<<5)]    /* read pin A3 */
           cmp   r1, #0
           beq   tpwr

The third line (str...) as far as i know is the code to reset the pin. Can anyone explain what I am missing or why one press should keep the pin set (low in this case).?

[atomikpunk]

Well when you read the GPIO, you do read the state of the pin, not a single button press edge, so yes, this is normal. Every read with a button pressed will do the same. And since the code runs awfully fast compared to the speed of a finger, you'll probably always get multiple button pressed state in your loops... You can do something like "if button is pressed, loop until it is unpressed again before continuing" if that's really what you want... But I'd also put a limit to that waiting in case something goes wrong...

Oh and the third line is to set the pin as an input, not to reset its state

[RockRabbit]

Well when you read the GPIO, you do read the state of the pin, not a single button press edge, so yes, this is normal. Every read with a button pressed will do the same. And since the code runs awfully fast compared to the speed of a finger, you'll probably always get multiple button pressed state in your loops... You can do something like "if button is pressed, loop until it is unpressed again before continuing" if that's really what you want... But I'd also put a limit to that waiting in case something goes wrong...

Oh and the third line is to set the pin as an input, not to reset its state

Thanks.

I understand what you are saying, but that does not explain my situation. When I detect the pin signal (low in this case), i execute a subroutine that flashes the button light on and off three times - which takes about 6 seconds. By the time this loop has completed, the button has been released some five seconds ago. The code then resumes the original loop looking at the state of the pin. It immediately detects the pin is low and begins the flashing routine, despite the button being unpressed. In other words the pin state is now "on" and will remain so, presumably till the battery goes flat or I get an epileptic fit watching the flashing button.

Either the pin remains at the button pressed state until "reset" (whatever that means) which seems impossible, or I have a bug in my code - but im damned if I can see it.

Anyone have a comment re the only 2Mbytes of ram on the c200 v2 target? Is thgat a problem being so low (for audio - I could care less about games or video).

[saratoga]

Anyone have a comment re the only 2Mbytes of ram on the c200 v2 target? Is thgat a problem being so low (for audio - I could care less about games or video).

Its somewhat of a problem, see for example the Clip which also has 2MB.

[kugel.]

Either the pin remains at the button pressed state until "reset" (whatever that means) which seems impossible, or I have a bug in my code - but im damned if I can see it.

Anyone have a comment re the only 2Mbytes of ram on the c200 v2 target? Is thgat a problem being so low (for audio - I could care less about games or video).

Well, apparently you have to reset the pins manually. Switch the pin to output (GPIO_DIR = 1<<X) and write the opposite value (GPIO_PIN(X) = [0 or (1<<X]), then switch to intput again (GPIO_DIR = 0).

BTW: I would really welcome if you try my patch and use a bootloader made by the build system. This is way safer, as dual boot remains if you have a bugged bootloader.

[RockRabbit]

Either the pin remains at the button pressed state until "reset" (whatever that means) which seems impossible, or I have a bug in my code - but im damned if I can see it.

Anyone have a comment re the only 2Mbytes of ram on the c200 v2 target? Is thgat a problem being so low (for audio - I could care less about games or video).

Well, apparently you have to reset the pins manually. Switch the pin to output (GPIO_DIR = 1<<X) and write the opposite value (GPIO_PIN(X) = [0 or (1<<X]), then switch to intput again (GPIO_DIR = 0).

BTW: I would really welcome if you try my patch and use a bootloader made by the build system. This is way safer, as dual boot remains if you have a bugged bootloader.

I will try the patch eventually. Its more learning curve for me to figure out how to load and apply the patch, understand what it does, etc, plus it then moves development over into C, which I have never used a lot and have not used for quite a while - more learning curve. At least the assembler is simple. And the current bootlader I understand, and I want make the most of it before I move on to something new.

This situation with resetting the GPIO pins makes me think that all the other buttons are there if I first initialise the pins before trying to read them. Some of the pins adjacent to the C6/right button that are all seemingly permanently low (the same as the right button when pressed) may just need resetting before use, and will prove to be connected to the other buttons. It makes sense for me to try this as it is so simple to do and it is something I currently understand.

By the way - do you have a comment to make re the lack of dram - only 2Mbytes? Or don't you see that as a major problem?

[saratoga]

By the way - do you have a comment to make re the lack of dram - only 2Mbytes? Or don't you see that as a major problem?

I suppose I could have been more specific.  The 2MB RAM problem causes some of the playback issues on the Clip.  It will require some reworking of playback to deal with.  However, since the Clip port is well ahead, I don't think its something you really need to worry about now.

[kugel.]

Well, 2MB is definitely not desirable, but Rockbox is designed to run on a wide range of playes, including those with a plenty of RAM and those with very little RAM.

That means, there might be some feature restrictions (none that matter though, mainly in plugins, unlikely any in the core), and Rockbox will generally run, nicely.

And, due to being a flash target, RAM isn't so critical for audio buffering (for which the rest of the ram, that doesn't hold the binary, is used), since accessing flash is fast and cheap (energy-wise) compared to hard disc drives.

The c200 (and the c200v2 most likely too?) has a color display. Those require slightly more RAM compared to greyscale or mono targets. But I don't expect this to be a real problem - if at all.

Don't mind about the RAM for now. Until we're trying to play music, 2MB will be enough. After that, we'll get onto some optimisations and it'll just run nicely - given that the remaining MP3 & Co. problems can be fixed (which also are present on higher RAM AMS Sansas). That's at least my expectation.

[RockRabbit]

Thanks kugel.

Yes the v2 c200 does have a colour display. The player is externally identical to the v1 and aside from the fact that its completely different it is identical (excuse my odd sense of humour). Put it this way, if I gave you both versions running the original firmware, if you did not look at the firmware revision number or the small "v2" printed on the back of the case, it would not be possible to tell the two apart.

I found three more buttons by pre-setting the logic levels of some of the pins. Using my new flashing-light bootloader, I can detect four buttons at a time. Ive updated the twiki. They are:

c3 - down button , c4 - select button, c5 - up button.

[kugel.]

c3 - down button , c4 - select button, c5 - up button.

That's cool! It would be nice if you could note whether high or low indicate button presses. Maybe not on the HardwareMapping page, but on a dedicated page (like a SansaC200V2Port or so..)

But on the other hand, I guess it really doesn't hurt if the table gets expanded by a level indicator and maybe a default value cell for each pin.

[RockRabbit]

kugel - how do I apply your 9679 patch and to what do I apply it?

[kugel.]

You apply them to SVN (trunk). See here for a small guide: http://www.rockbox.org/twiki/bin/view/Main/WorkingWithPatches

The first patch adds c200v2 to our firmwarepatcher tool, the second one adds the c200 as a target into the rockbox tree.

After you patched, please double-check [sourcedir]/rbutil/mkamsboot/dualboot.S to see if I have done something wrong.

After than you need to build mkamsboot. To do that, just type make in [sourcedir]/rbutil/mkamsboot/.
You can then build a bootloader using these instructions: http://www.rockbox.org/twiki/bin/view/Main/HowToCompile
You should get a bootloader file(bootloader-c200v2.sansa), which you pass together with C200PA.bin to mkamsboot (./mkamsboot <OF file> <bootloader file> <patched file>. The patched file is that what you put on your c200v2 after renaming it to c200pa.bin.

Our bootloader code is situated in  [sourcedir]/bootloader/sansa-as3525.c. This is the file you should edit for your experiments.

Some tests would be: test if buttonlight_on() works. test if backlight_on() works. test if lcd_init() works. While I'm doubtfully about lcd_init, I think backlight should actually work.

[RockRabbit]

thanks. i'll give it a try.

[kugel.]

Uhm, before you build the bootloader (but after patching) edit firmware/target/arm/as3525/system-as3525.c and tools/configure to reflect the correct memory (I guessed 8MB when I made the patch).

And sorry that I need to say it again: Double-check rbutil/mkamsboot/dualboot.S. This file is critical! Wrong code will brick your player. So please check if I added the correct GPIO states for USB present and Right button.

Sorry, we can't be safe enough about that file