On Fri, Mar 20, 2015 at 04:47:15PM +1300, IVP wrote:
> > So you might also fix it by doing a write now and then.  ;-)
>=20
> 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
>=20
> 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

Imagine this;

0.  normal operation, with read counters for flash pages incrementing
each time you read the blocks, until;

1.  the read counter for a flash page hits the read disturb limit,
then;

2.  the FTL knows that to read the block it will begin to degrade, and
so refuses the read command.

If the unplayability via SPI is because the flash pages are due for
relocation to avoid read disturb, when you mount the card on a system
via SDIO the first write for filesystem metadata will give the FTL
the right to do that relocation.

So another test is to wait for the problem to happen again, then load
the card into a computer and create a tiny file unrelated to the
application, then see if that fixes the problem for the moment.

> 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
>=20
> That may have been successful
>=20
> 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.
>=20
> 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
>=20
> So I'll fix that and do the test
>=20
> Joe

--=20
James Cameron
http://quozl.linux.org.au/
--=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
.