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

[DonDan]

Now I get under the same conditions as before the following error:
(I cannot read the entire error msg because it clips right after INT_DMA)

*PANIC*

Unhandled masked IRQ 04: INT_DMAC...
(status 0x00000000)

in the builds before you disabled the dynamic CPU frequency I was always getting the following error when recording:

*PANIC*
i2sin error: 0x4E = push


The PictureFlow freeze is not related to this issue, as csavery confirmed, it is a PictureFlow specific bug. FS#11286

[funman]

Now I get under the same conditions as before the following error:
(I cannot read the entire error msg because it clips right after INT_DMA)

*PANIC*

Unhandled masked IRQ 04: INT_DMAC...
(status 0x00000000)

The entire error msg is here, it's not clipped.

If it still happens with r26257 I guess we'll need to handle i2sin fifo errors one way or another.

[DonDan]

with r26259
the recording does not work at all:

the vu-meter gets stuck in the first second and if you press play to start the recording a filename appears, but the  the time field does not change  and the vu-meter does not move. You still are able to stop the recording but the file is not saved. Gain an Volume still responds to any user induced change. Also no crashing at all .

[funman]

Should be fixed in r26270

[DonDan]

Still getting almost the same error, status changed a little:

*PANIC*

Unhandled masked IRQ 04: INT_DMAC
(status 0x00000010)


Using r26279 with as3525v2-cpufreq-v10.diff

[Ahcsas]

I can't create a bootloader for the Clip+ from r26260 until r26280 (current).

The Issue must be in r26260, building a bootloader from r26259 works.

[funman]

Should be fixed in r26285, but you should really use the binary bootloader on SansaAMS wiki page; we don't check regularly if bootloaders work or not.

[jfinnie]

I just wanted to quickly say big kudos to all you developers working on Sansa AMS - I've installed R26289 on my clip+, and after compiling mkamsboot from SVN source the player seems to work absolutely great (before that, kept rebooting on connection of USB to PC).

The wiki pages are very clear and informative, and got me compiling within an hour - and that was including installing the dev environment and doing an SVN checkout.

I haven't been this impressed with an open source project in a long time.  Keep up the good work guys!

[MasterFen]

Would you mind uploading your compiled version somewhere? I have the same reboot on usb problem.

[marc2003]

my first ever crash with cpu at full speed. r26311. this happened about 2 minutes after starting playback. i didn't see any messages so i turned back on, enabled backlight always on and it crashed again within minutes leaving me this message....

*PANIC*
Unhandled masked IR
Q 04: INT_DMAC (sta
tus 0x00000010)

clip v2, playing ogg, no eq/effects.

EDIT: i created my own 26310 build from SVN  and it appears to be ok. i then put 26311 back on and it crashed again within a minute. i just need to test 26310 for a lot longer to be sure.

[mitk]

Same for me. I've got 3 crashes in 2 hours with Fuze v1 and r26311. Don't have any panic message because of no backlight enabled. I think it's related.

[funman]

Yeah indeed it is caused by r26310, thanks for the report.

I'm working on a fix.

BTW I think it's the same bug than the panics with recording reported earlier (same message), and some other bugs I have seen related to USB/charger plugging

EDIT: should be fixed in r26316 (only for playback/recording, did nothing for USB/charger interrupt)

[jfinnie]

Would you mind uploading your compiled version somewhere? I have the same reboot on usb problem.

Here is a link to my compiled version of mkamsboot:
http://www.mediafire.com/?jtmihgmtw2y
Compiled yesterday under Cygwin, revision 26289. 
I used this to build a firmware image for my Clip+ and it worked, though of course use at own risk.

[ssorgatem]

I have currently two weird issues with my fuzev2:

1 -  Apparently randomly, the screen goes blank. This can happen from the first moment the screen is on, it can happen after the "ver 2.0" screen, and the white screen remains blank; or it can show a blank screen instead of the boot "ver 2.0" screen and then  show rockbox normally. It can also become blank during playback.

 It can also happen that it boots fine, but the colors are very weak, oo have very high brighness or something (black looks light grey). And sometimes it boots normally. It can even be difficult to get one of these white screens when you're intending to do so, and sometimes you can get rid of them, rebooting again and again into a blank screen.

 In all cases rockbox itself still works; I can hear the menus and the usual stuff guided through voice.

 I've tried to see in which revision or when it did happen. Results of my research: the rockbox version doesn't matter; it to be something bootloader-related, and I've tested too older mkamsboot but it's still there.

However, if I install an old patched firmware file I have, with the old bootloader (not "Ver 2.0"), it doesn't happen. I upgraded to the v2 bootloader last week; maybe tuesday or wednesday, but I started to notice the white screen issue this monday. If it's something related to the bootloader, I might have been "lucky" and haven't get a white screen in those first days (I didn't use the fuze too much those days, either), so my hipothesis is that it's bootloader related.Where could I find older working bootloader builds? Or which revisions are known to work? (I know bootloader's status isn't checked regularly).

UPDATE: Using a bootloader built from svn seems to solve the problem (I can't be 100% sure about it until some more hours of testing)

And the second one:

2 - [Not sure if it's fuzev2-specific]I have an artist called "Têtes Raides".They're all mp3 files (the only mp3 files I have) and are tagged as ID3v2.3 ISO  8859-1 (all my music is tagged with these tags, they're the better supported by the OF).

The problem: yesterday, it showed under database/artist as "T[]tes Raides". Also, no unicode character from songs or albums from that artist was shown correctly. I can see unicode characters from other artists, and it even shows correctly (Têtes Raides) under the file browser (so it's not a font issue).

The weirdest: today, I find that, under Database/Artist I have two entries: "Têtes Raides" and "T[]tes Raides". I haven't touched my music in the player. Also, the albums listed for each are different, and unicode characters under "Têtes Raides" are shown correctly, whereas in "T[]tes Raides" they aren't.

Any ideas about why is this happening?

UPDATE: Both entries show exactly the same albums and songs... but one shows them correctly,  while the other doesn't. However, even if I play a non-correctly shown file, it will show correctly on the WPS.

UPDATE: I just needed to rebuild the database, and then it showed properly. Thanks to funman for suggesting it.

[DonDan]

I have done some new recording tests with rev. r26316.

I was able to record from mic to WV for 4 hours without a crash, I aborted my self the recording, everything went alright. Nice!!!  
As you have foreseen, funman! 

Recording from radio also went OK, made a recording with 1,5 hours, then the battery got empty and it shutdown.  Maybe it was a crash, because I got no file with the recorded data.

I also got a freeze once after 3 sec with rec source radio, maybe not relevant, just bad luck?
Afterward I recorded for 57 min from radio to WV, battery got empty again but this time the recorded data was saved to a file. Charging battery for more radio -> WV testing...I will report later.

 
I have noticed that if a crash occurs during a recording, there is no file with the recorded data. It would be a really awful scenario if you have, lets say recorded a 2 hours session, and in the last few minutes it crashes. You would have lost the entire recording.
Is it possible to manage that, if a crash occurs the recorded date doesn't get lost?  This way it would be still awkward but it would not be a total disaster.

EDIT: Got a freeze after 1h 5min recording from mic! It looks like the recording feature is still not reliable.  :'(