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

[csavery]

Yes, but look further down. It does a check in a function called get_model - this returns unknown with the new 2.03.33 image - well, the one I have anyway - just downloaded from sansa site.

I added,

case 0x71:

and then compiled and ran mkamsboot. It succeeds with this model_id value added. I haven't copied it to my Fuze yet because I'd like to confirm somehow that others have seen this new model_id in 2.03.33. The md5 checks out so I don't see how others could not have 0x71 in their OF file as well.

The model_id is not the version # but seems it should refer to the device model. Of course, my device has changed but I am definitely seeing the value 0x71 in location 0x219 in the latest OF image fuzpa.bin

Maybe this is why they rolled 2.02.31 -> 2.03.33 ?

[Jennifur]

Yes, but look further down. It does a check in a function called get_model - this returns unknown with the new 2.03.33 image - well, the one I have anyway - just downloaded from sansa site.

I added,

case 0x71:

and then compiled and ran mkamsboot. It succeeds with this model_id value added. I haven't copied it to my Fuze yet because I'd like to confirm somehow that others have seen this new model_id in 2.03.33.

The model_id is not the version # but seems it should refer to the device model. Of course, my device has changed but I am definately seeing the value 0x71 in location 0x219 in the latest OF image fuzpa.bin

I see it too. Yet when I patched the OF I didn't get(notice) the error. I can try again and see if I get it.

EDIT:
I didn't get the error at all. This is the output from mkamsboot

Code: [Select]

jennifur@alice:/mnt/disk$ mkamsboot fuzpa_orig.bin bootloader-fuzev2.sansa boot.bin
mkamsboot Version r26241-100521
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[INFO] Original firmware MD5 checksum match
[INFO] Model: Sansa Fuze v2 - Firmware version: 2.03.33
[INFO] Firmware patching has begun !

[INFO] Original firmware size:   168920 bytes
[INFO] Packed OF size:           90016 bytes
[INFO] Bootloader size:          76240 bytes
[INFO] Packed bootloader size:   33945 bytes
[INFO] Dual-boot function size:  364 bytes
[INFO] UCL unpack function size: 168 bytes
[INFO] Total size of new image:  124493 bytes

[INFO] Patching succeeded!
jennifur@alice:/mnt/disk$

[csavery]

That's weird. It's exactly what I get after I add the model id.
How could the md5 match the one embedded in mkamsboot when the model byte 0x71 != 0x70 ?
Baffling... I guess I'll wait a bit before trying to boot on it.

[Jennifur]

I ran md5sum on the OF and got the same result as in mkamsboot.c. Can you try downloading the firmware once again and run md5sum on it?

[funman]

get_model() isn't called if the md5sum of the OF is in the list.

Btw, before we add an OF release it is always tested on a real device first.



I see indeed that the model id has changed from 0x70 to 0x71 so it makes me wonder:

Perhaps we should not rely on this field to detect model of the OF ?

What if Sandisk decides to release a Clip+ firmware with model id = 0x71 too ?

[csavery]

I just checked it all again. Downloaded again, ran md5sum at linux prompt. Matches value in mkamsboot.
Mine is 1599cc73d02ea7fe53fe2d4379c24b66
Opened fuzpa.bin in hex editor again and double checked value at 0x219 is 0x71

Looking at mkamsboot code I see the model id is only checked when the md5 doesn't match.
So it must be that the model id increment has not yet been added into a new mkamsboot.

I think what *must* of happened is that at first I compiled mkamsboot with r26185 and it didn't yet have the correct md5 for 2.03.33 so it failed and gave me the wrong model id reason. Then after I updated and re-compiled I didn't realize it wasn't the model id but the md5 that was actually wrong before.

I just verified this by removing the "case: 0x71" I had added and the result is good OF.

Except... the mkamsboot DOES need to have the new model_id value added since otherwise it DOES give the wrong error message about model_id.

I guess I should add a bug in FlySpray for that then.

Update - funman: Ahh, yes, thank you for checking that. I see it too. Probably just needs a second case statement so it now accepts either model id. It's no longer unique.

Anyway, happy here. Firmware upgrade worked ok. Should I add a bug or patch for this?

As of r26239 I am not hearing clicks any more during play state changes. Sweet. Thanks!

[funman]

Should I add a bug or patch for this?

Well I'm not sure what to do, see my post just above

As of r26239 I am not hearing clicks any more during play state changes. Sweet. Thanks!

Hmm I didn't know about this : is it caused by r26238 ? (r26237 still has them?)

[csavery]

Actually I'm noticing it in r26239 still. It happens during pause at the end of the fade and during play before the fade starts. It fades down and then a little "phhht" sounds occurs, or when play is pressed after a pause it makes a slight "phht" and then fades up. During shutdown it may happen a couple times or just once. It pretty much always there, though I've noticed a few times when pause is quiet.

[NightWalker]

I have a fuvev2 and a clip+
Rename and erase on SD fails with
*PANIC* wait for TRAN state failed <PRG> 1 on both (Not something new)
Using a 16GB class 6 card and the current build (r26241)
everything works fine with 4GB class 2 card
Keep up the great work!

[funman]

@FlynDice

sd_wait_for_state() timeouts after 1 second, is that an arbitrary choice ?

I looked for maximum delays after STOP_TRANSMISSION in the spec but I didn't find any

As soon as the data transfer is completed, the card will exit the data write state and move either to
the Programming State (transfer is successful) or Transfer State (transfer failed).

I think TAAC / NSAC / TRAN_SPEED don't take in account how much time the card spends in PROGRAMMING state.

I tried to read linux source code for MMC/SD but it is a nightmare of object code, I can grep for STOP_TRANSMISSION but I don't know where/when it is issued.

[FlynDice]

The one second is indeed arbitrary I think.  Perhaps just increasing it will take care of that problem or we could wait for the card to signal not busy after the transfer is complete.  Since the card is basically programming the info on its own and we don't need to manage it I think just increasing the timeout here would be the preferable solution if it works.  I'll have time later tonight to look at this, I'm between flights right now.

 I can't access the irc logs  and flyspray for some reason so I can't see if you got my message about the cpu_freq_patch that I left in the log.   With v10 I did get my clip+ to run down to empty by clearing my settings.  However when I juiced it back up and looked at the hardware page I noticed that there was no frequency switching going on, just a steady 40 MHz until there was a card access.  It seems that 40 MHz is enough performance that boosting is not needed at least without the equalizer & compressor enabled.  If I enable the compressor and equalizer I get boosting on a regular basis and the clip+ crashes after about 30 mins.


EDIT:

http://pastie.org/973066 will definitely solve the card stuck in PRG state problem.  It passes write & verify but I got mixed results for speed, some faster some slower on tests.  I can't be sure that it won't introduce something else though without more widespread testing.

[funman]

The one second is indeed arbitrary I think.  Perhaps just increasing it will take care of that problem or we could wait for the card to signal not busy after the transfer is complete.  Since the card is basically programming the info on its own and we don't need to manage it I think just increasing the timeout here would be the preferable solution if it works.  I'll have time later tonight to look at this, I'm between flights right now.

http://pastie.org/973066 will definitely solve the card stuck in PRG state problem.  It passes write & verify but I got mixed results for speed, some faster some slower on tests.  I can't be sure that it won't introduce something else though without more widespread testing.

OK, going to test it. No idea for the the slower speed though.

I'll see if yielding while the card is busy affects speed too much, it shouldn't change a lot since we yielded anyway if the card was in programming state, unless if had finished programming immediately.

EDIT: I got some "read multiple blocks failed" when playing off µSDHC class 6 on Clip+. I'll try to add back the wait for state TRAN after the busy wait.
EDIT2: same crashes, I'll now try with extended delay when waiting for TRAN state

I can't access the irc logs  and flyspray for some reason so I can't see if you got my message about the cpu_freq_patch that I left in the log.

I think logbot is on the same server than the website so no irclogs until the site is back. (and messages while the site went down won't be logged).

With v10 I did get my clip+ to run down to empty by clearing my settings.  However when I juiced it back up and looked at the hardware page I noticed that there was no frequency switching going on, just a steady 40 MHz until there was a card access.  It seems that 40 MHz is enough performance that boosting is not needed at least without the equalizer & compressor enabled.  If I enable the compressor and equalizer I get boosting on a regular basis and the clip+ crashes after about 30 mins.

It still boosts but if it's fast enough you won't have the time to see it in the debug page.

DSP settings and voices make crashing happen more quickly, I'll run my tests with it enabled.

Here are some results with cpufreq:

With v10 (I think it's that one, can't access flyspray, anyway it was CPU@40MHz and no delays when changing freqs) on Clip+ playing from internal I had 15h15 runtime, so even if we make it work it makes battery life not better if not worse, probably because of the higher DRAM/PCLK freq (40MHz instead of 24).

On Fuzev2 I got 19h from internal, 11h33 from µSD (Samsung 1GB, not HC, no class). I'll try with the Transcend SDHC 4Gb class 6, some messages on the forum said higher class cards crashed more.

I also tried another version for Clips which use 24MHz PCLK, but doesn't go lower than 24 when switching (24, 30, 60), and it crashed quite fast (freezes, data abort in thread code).

I wonder if there is anything special about Fuzev2 or if we just didn't see any crash because we tested this model less.

[funman]

get_model() isn't called if the md5sum of the OF is in the list.

Btw, before we add an OF release it is always tested on a real device first.



I see indeed that the model id has changed from 0x70 to 0x71 so it makes me wonder:

Perhaps we should not rely on this field to detect model of the OF ?

What if Sandisk decides to release a Clip+ firmware with model id = 0x71 too ?

I checked other firmwares and this field has already changed in the past:

It is 0x23 on the one c200v2 OF we have, and on the last 2 Fuzev1 OFs.

So we must disable this check completely because it is not representing of the model.

EDIT: I have a patch for that, just waiting for svn to be up again.

To be clear, if you use released binaries or unmodified SVN there is no risk of bricking.

[DonDan]

I have tested the "as3525v2-cpufreq-v10" patch with the 26241 revision on a fuze2 8GB with a transcend CL6 8GB uSD .

I still have a few crashes with the v10, when recording and when browsing  the PictureFlow demo. During playback with crossfeed enabled and everything else disabled, I have no crashes at all.

Without the "as3525v2-cpufreq" patch I can record Mic/Radio for more than 4 hours without a crash (tested with output to mp3 and wv).

I have done a battery-bench with a 33 min rock music album with 258 VBR (Lame3.99 --vbr-new -V 0) with Crossfeed enabled (forgot to disable), playback from internal memory. Earplugs with impedance = 16 Ohm and volume set to -20dB.
It lasts for 12h and 30 min, "Battery bench ended, reason: power off", no crash.

If you need more fuze2 testing give a shout!


EDIT: I can't reproduce the PictureFlow freeze, maybe it is some PictureFlow specific bug.
The Recording crashes come every time, it is just a matter of time, sometimes just a few seconds other times I must wait for 30 min. I doesn't matter if the source is radio or mic neither if the output is mp3 or wv.
The error message is always the same:

*PANIC*
unhandled IRQ (source unknown!)

[funman]

The Recording crashes come every time, it is just a matter of time, sometimes just a few seconds other times I must wait for 30 min. I doesn't matter if the source is radio or mic neither if the output is mp3 or wv.
The error message is always the same:

*PANIC*
unhandled IRQ (source unknown!)

I have just made a commit (r26250) which should make this panic message a bit more precise, I suspect it should now show I2SIN interrupt.

Can you confirm?


FlynDice, I have put a patch for SD on FS#11312