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

[mc2739]

with r21780 and unboosted cvdd=1.05v on microSD insert I get:

*PANIC*
microSD init failed : -4


If microSD is inserted on boot, I do not get a panic, <microSD1> is listed under Files but no files or folders are listed under <microSD1>. Shortly after I enter <microSD1>, the unit locks (backlight timeout still works).

[jberkenbilt]

This is my first post to the forums, though I've been a happy Rockbox user for some time.  I just got a Sansa Fuze v2 to replace my iRiver H320 which finally died.  I'm heartened to see that the v1 is starting to work, and am eager to see some progress on the v2 Fuze.  I would be willing to donate a v2 Fuze or make a PayPal donation to cover a device if it would help, and I would also be willing to try experiments with my device.  I have 20+ years of programming experience (though not a whole lot of free time) and an equal amount of Unix sysadmin experience, so making dd images of the flash, compiling builds, formatting the drive and recovering from data corruption, etc., should not be a problem.  I'll check back here from time to time to see whether there's interest in my offer to donate a device and to find out how to do that.  Is just making a donation in PayPal with a comment appropriate?  Thanks, and I wish the developers the best of success in getting the Fuze v2 into the fold.

[saratoga]

I just got a Sansa Fuze v2 to replace my iRiver H320 which finally died.  I'm heartened to see that the v1 is starting to work, and am eager to see some progress on the v2 Fuze.  I would be willing to donate a v2 Fuze or make a PayPal donation to cover a device if it would help, and I would also be willing to try experiments with my device.

I think someone here would be glad to accept a donation of a V2 Fuze.  Would you be willing to mail your new Fuze to someone rather then make a donation?  Its tricky to make sure someone buying a V2 Fuze for development actually gets a V2 Fuze (the last 3 I bought were all V1s).   And of course you might get lucky and get a V1 fuze and be able to start using it right away . . .

[funman]

with r21780 and unboosted cvdd=1.05v on microSD insert I get:

*PANIC*
microSD init failed : -4

This means the send_cmd() failed, which is quite rare (we don't support recovery if sending a command failed, but this should be trivial to implement).

Can you check if the command fails because of a timeout or something else ? Just add panicf() in send_cmd() before the places where it return false.

If microSD is inserted on boot, I do not get a panic, <microSD1> is listed under Files but no files or folders are listed under <microSD1>. Shortly after I enter <microSD1>, the unit locks (backlight timeout still works).

It's a bit strange, I thought r21776 would remove the possibility of a deadlock ..

[jberkenbilt]

I think someone here would be glad to accept a donation of a V2 Fuze.  Would you be willing to mail your new Fuze to someone rather then make a donation?  Its tricky to make sure someone buying a V2 Fuze for development actually gets a V2 Fuze (the last 3 I bought were all V1s).   And of course you might get lucky and get a V1 fuze and be able to start using it right away . . .

Yes, I would be willing to do that, and I would also be willing to buy another one from the same place and ship it in its original packaging, etc.  Probably shipping mine is the least risky in terms of guaranteeing that whoever gets it gets a v2.  Where did you get your V1 from?  Maybe I should order one from there. :-)

[mc2739]

Can you check if the command fails because of a timeout or something else ? Just add panicf() in send_cmd() before the places where it return false.

The command fails with MCI_CMD_TIMEOUT (status = 4)

[funman]

Can you modify send_cmd to retry on error (at least 1 time) and see if it will eventually succeed?

[mc2739]

Can you modify send_cmd to retry on error (at least 1 time) and see if it will eventually succeed?

I tried this and still get the same timeout, although I'm not positive I did the retry properly.

[funman]

The SD spec says that if a command CRC check fails the card will not change its state, and no error recovery procedure is described (I understand that sending the command should be retried)

For some reason the transfer line will not function properly (see this post about data transfers).

Can you attach your diff here so we can check if it's correct?

[mc2739]

Can you attach your diff here so we can check if it's correct?

Here is the diff I used to test (I had to rename to .txt to attach)

[FlynDice]

EDIT: Don't waste a whole lot of time here, while it may not be precisely correct I think the code does what it needs to do.

@funman:

re SDHC determination:
  I've attached a flowchart I found on a webpage that illustrates the way I read the SD docs as far as SD_SEND_IF_COND (CMD8) is concerned regarding getting a response or not.  I can't say that this is the correct interpretation or not it just illustrates how I read the docs.  I found the following comment in ata-sd-pp.c which seems to illustrate the opposite interpretation:

    /* Check for SDHC:
       - non-SDHC cards simply ignore SD_SEND_IF_COND (CMD8) and we get error -219,
         which we can just ignore and assume we're dealing with standard SD.
       - SDHC cards echo back the argument into the response. This is how we
         tell if the card is SDHC.
     */

I believe this is incorrect.  I think the absence of a response indicates a non v2 card, which would of course be non hc but I think you could have a non hc v2 sd card that would give you a response with the correct voltage and check pattern.
 
The way I read the docs, the way we can tell if we've got an sdhc card is by sending acmd41 with the CCS(30) bit set to tell it the host can use hc, and then reading the CCS bit it sends back after power up to see if the card is hc.

Or am I missing something again....?

[funman]

mc2739 : your patch looks correct, I don't know what's the problem ..

Perhaps we should try to reinitialize completely the card when a problem happens, like ata-sd-pp.c does.

FlynDice: thanks for pointing this out, the variable sdhc should in fact be named sd_v2, since its only use is for setting bit 30 in acmd41 argument.

High Capacity or Standard Capacity is determined by CSD structure in sd_parse_csd().

[jberkenbilt]

I think someone here would be glad to accept a donation of a V2 Fuze.  Would you be willing to mail your new Fuze to someone rather then make a donation?  Its tricky to make sure someone buying a V2 Fuze for development actually gets a V2 Fuze (the last 3 I bought were all V1s).   And of course you might get lucky and get a V1 fuze and be able to start using it right away . . .

Yes, I would be willing to do that, and I would also be willing to buy another one from the same place and ship it in its original packaging, etc.  Probably shipping mine is the least risky in terms of guaranteeing that whoever gets it gets a v2.  Where did you get your V1 from?  Maybe I should order one from there. :-)

So, uh, how would I go about finding someone to accept the donation and figuring out where to send it to?  I could look at the svn logs to see who is working on this, or I could email the address to which PayPal donations are made, or I could wait to see if someone posts interest here in receiving it.  Or is there some different option?  I would very much like to make the donation to someone who is interested in getting the Fuze v2 to work, but don't worry...there are no strings attached.  I'm not going to suddenly expect quick results or even a change in priorities.  I do open source work myself and know how it works. :-) I don't even need to know who receives the donation as long as it goes to someone who will actually benefit from it.  If no response, I'll try emailing the address that receives PayPal donations and go from there.  Thanks!

[funman]

All developers working on the Sansa AMS port read this thread, so if one of them is interested he will likely step up.

I would gladly work on it, but i have already a lot of other priorities and I hope someone else will want to make work on Fuzev2 happen quicker.

One of those priorities is working on the Clipv2 port which is (hopefully) very similar to Fuzev2, just like Fuzev1 code is similar to Clipv1.

Some work on Fuzev2 has already been made, so the Fuzev2 is able to dual-boot, but there is still no LCD or complete buttons/wheel support.

[-]

I've got rockbox (version: r21520M-090714 ) on my sansae200v2 :

-Bootloader works pretty fine.
-Even if the backlight from the WheelLight is disabled, when my sansa is "computing", it's lighting.
-There is no possibility of seeking an mp3 file.
-The database building is crashing.
-Except the "database crash", I don't have many crashes.