Compact Flash and 8051

> Watching the data bus during reading of the SanDisk device shows
> something interesting- During a corrupt read operation, the data bus
> shows the correct byte being output following the read strobe, but
> before the data signals have had time to rise to VCC, the byte is
> removed from the bus. It's almost like the CF card is seeing multiple
> read strobes (only on certain data byte values?!).

I had a similar problem once, and it was related to signal integrity.
The card saw two read strobes where I sent only one (in memory mode,
where each strobe increments the card's internal address counter).

The problem was fixed by properly terminating all asynchronous signals
like RD and CS, and inserting series resistance into the bus data lines
(near to the card) to decouple the cards' drivers from the data bus
capacity.

Marc

> I'm curious to know what sort of analysis equipment you are using David. I'm
> used to a sickeningly theoretical approach to all things, and would be very
> interested to know what the pro's, such as yourself and Hul, would use to
> investigate the CS-line problem.


Hi Murray,
All this work is done with a decent digital storage 'scope (i.e. one
that can see a 5ns bounce), a hot iron balancing on the end of my
desk, and compassionate enough employers to realise that my initial 5
day quote for completing this work was somewhat optimistic!

Hi Marc

Despite having found a 'fix' for the original problem, I've had
nagging worry that the actual cause remains somewhat unknown. I did
suspect ground bounce, until I realised that my apparent skipping of
bytes during reading occurs only when a reading a byte with a high 1's
count (0xFF). This would suggest to me that there's an issue with the
inductance on the VCC rail (as opposed to GND), but however much I
decouple the supply rails, it still happens. Also, ground bounce would
make logic 1's on any control lines appear as logic 0's, which doesn't
fit with my symptoms

As a precautionary measure, I had added some serial resistance (which
to my mind reduces di/dt through any supply inductance, and hence
voltage droop) which improved things slightly, but not enough to
remove the CS buffering. Since buffering the CS line (which fixes the
problem) has the effect of lowering its source impedance, I'm left
thinking that during the placing of 1's on the databus, there's a
sharp current demand placed on the CS line, which left unbuffered,
allows it to rise sufficiently to de-select the device momentarily.

... do the words 'straws' and 'clutching' come to mind?! Does anyone
agree, or is there a more rational explanation?


Thanks 

David

On 15 Aug 2004 03:10:11 -0700, david@phylida.co.uk (David Fussell)
wrote:

>Hi Marc
>
>Despite having found a 'fix' for the original problem, I've had
>nagging worry that the actual cause remains somewhat unknown. I did
>suspect ground bounce, until I realised that my apparent skipping of
>bytes during reading occurs only when a reading a byte with a high 1's
>count (0xFF). This would suggest to me that there's an issue with the
>inductance on the VCC rail (as opposed to GND), but however much I
>decouple the supply rails, it still happens. Also, ground bounce would
>make logic 1's on any control lines appear as logic 0's, which doesn't
>fit with my symptoms
>
>As a precautionary measure, I had added some serial resistance (which
>to my mind reduces di/dt through any supply inductance, and hence
>voltage droop) which improved things slightly, but not enough to
>remove the CS buffering. Since buffering the CS line (which fixes the
>problem) has the effect of lowering its source impedance, I'm left
>thinking that during the placing of 1's on the databus, there's a
>sharp current demand placed on the CS line, which left unbuffered,
>allows it to rise sufficiently to de-select the device momentarily.
>
>... do the words 'straws' and 'clutching' come to mind?! Does anyone
>agree, or is there a more rational explanation?
>

Hi,

I am getting late into this thread so my answer might be total
nonsense. Anyway I had a similar problem once with a VME clock
on one of my cards. I was getting spurious corruption of data.
Buffering the clock line "fixed" the problem. I was not happy however
since the card supplying the clock was a well designed and often used
VME bus master - hence the clock should  and could source and sink
upto something like 64mA, and I was driving only 3 inputs.  After
further investigation it turned out that the clock was rising to slow,
hence the data corruption. I could confirm this using a clock
generator with a programmable slope. Anyway you might want to look
at your CS slope.

Hope this helps

Regards
   Anton Erasmus

"David Fussell" <david@phylida.co.uk> wrote in message
news:c2180e99.0408150210.48aec58@posting.google.com...

> Despite having found a 'fix' for the original problem, I've had
> nagging worry that the actual cause remains somewhat unknown. I did
> suspect ground bounce, until I realised that my apparent skipping of
> bytes during reading occurs only when a reading a byte with a high 1's
> count (0xFF).

Yep, that's the same pattern matching nonsense I ended up with.

Regards,
Murray R. Van Luyn.

Hi,

the company I work for has modules which do all the Compact Flash card
and FAT handling.

You interface to the moduls via RS232 (TTL level). By sending "AT" like
commands, you can read and write files, check the presents of a card
and so on. Pretty nice module.

Check them out at: www.avisaro.com . Contact me directly if you need
someone at avisaro who speeks Englisch.

Matt

Avisaro AG