> So you might also fix it by doing a write now and then.  ;-)

My application is intended to be read-only, but I can add
non-user writing. Having a block-size SRAM may be more
helpful than I thought

On my to-do list was to write the file back to the card, as I
suspected it may have been corrupted. After comparing the
"unplayable" with the original though it seems they are the same

As I mentioned before, I was going to look for the simplest
solution, so have just written the file to the card and replacing
what was there, with your suggestion of some sort of garbage
collection or unfinished business in mind

That may have been successful

When I powered the card up before this, it would run for
just one or two reads. After writing the file back to the disk
it does appear to be working again, but I don't know for how
long. The test would be to let it run overnight and see if the
reads stop again.

I have one little glitch to correct in the dsPIC s/w. I didn't take
into account the high word of the cluster number in the directory
entry. Re-saving the files has changed their starts from ~ 0x8500
to ~ 0x001d0060, so my s/w retrieves data from an incorrect
0x0060 pointer. It does fetch the correct amount though. At the
correct sector number is indeed the RIFF header for the file

So I'll fix that and do the test

Joe


-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.5751 / Virus Database: 4311/9339 - Release Date: 03/19/15

--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.