On Sun, Mar 29, 2015 at 03:35:42PM +1100, James Cameron wrote:
> On Sun, Mar 29, 2015 at 03:42:43PM +1300, IVP wrote:
> > http://home.clear.net.nz/pages/joecolquitt/sdhc.html
>=20
> That's very clear.  In the failure case, why didn't "do" go low
> during "cs" high?  Are you properly detecting and handling that
> possibility?

Also, as I wrote on 20th March, when DO floats when you assert CS, it
means the card is busy programming.

The card may intend to begin programming because of a read disturb
counter reaching zero.

The specification doesn't tell us exactly what to do then, but my
guess is to keep clocking and try to assert CS a few tens of
milliseconds later, or whatever the programming time is.

Conjecture; eventually programming will complete and DO should be
pulled down in response to CS.

You might also measure the programming time for future reference.

Conjecture; since you aren't trying CS again, you aren't facilitating
the read disturb programming, and it never completes, which is why the
card seems to become "infected".

Conjecture; the delay before failure is unpredictable, because it will
depend on mapping from virtual block to flash page, and the read
disturb counters on that page and adjacent pages.

--

And a different observation; in the failure case you are raising CS,
then a delay before DI and CLK rise.  The delay is about the size of a
clock period.

Try changing your dsPIC code to raise DI and CLK at the same time as
CS.

e.g. are you handling a time consuming interrupt at this point;
perhaps you could mask interrupts?

--=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
.