On Fri, Mar 20, 2015 at 02:30:19PM +1300, IVP wrote:
> >> The only non-data activity is when the PIC sets CS for ~700us
> >> during the " > 74 clock cycles " re-init after a data time-out.=20
> >=20
> > Do you gate the clock at all?
>=20
> 10 bytes of 0xFF are sent, with clock, from the PIC's SPI module
>=20
> > Or perhaps the card needs an external clock source for executing
> > the code in the firmware, and if you are starving it of a clock it is
> > never getting a chance to do necessary garbage collection after a
> > command.
>=20
> Hmmm, there's a thought. As SPI is in h/w it takes only a couple
> of instructions to send 0xFF. After the block has been read I can
> send plenty of dummy bytes + clock without impacting on the s/w
> which follows
>=20
> I'll do that now and see how it's doing in the morning. Currently
> there's just one dummy byte, sent before each CMD17. ISTR
> that is suggested in a pdf

Good, let us know how it goes.

> > Perhaps you'd be able to prove that by scoping the current drawn
> > by the card after a read command with extra clocks provided. You
> > might need to scope it for thousands of reads before it needed to
> > cleanup though.
>=20
> So you think a current change should be detectable when it goes
> into a proper idle state ?

Yes.  And depending on your decoupling capacitors nearby, you may see
the noise induced on the supply by the FTL CPU.

I've had a quick look at the SD Specifications, Part 1, Physical Layer
Simplified Specification Version 3.01, May 2010.

In this document, "programming" means the erasing or writing to flash
pages.

In the "SPI" section, it says if the card is busy programming, and you
reset CS, it will release DataOut line (float it) and continue with
programming.  Do you check for that?

The specification goes on to say that if you force a reset, it will
terminate programming, and may destroy data.  As you know your card
has destroyed data, it may be worth going back to make sure you don't
force a reset while it is programming.

Also, in the "clock control" section, it points out that a card is
meant to complete programming even if the host stops the clock, so
that goes against my earlier theory.

Looking at the state diagrams, CMD17 (read block) isn't meant to go
into programming state.  This implies that read disturb damage would
accumulate and be handled on the next write.  If your application
never does a write, damage would never be handled.

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

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