Compact Flash and 8051

Hi,

I'm attempting to implement CF based storage  on an embedded platform
(8051 clone- no OS), and have read a few app. notes on the subject,
but I'm seeing some odd behaviour from the CF devices that I'm using
(Kingston, SanDisk and Integral).

I've tried both memory mode and IDE modes of operation, with IDE
giving me the most satisfactory results (I can read and write to
Kingston and Integral devices), but I can't seem to get the SanDisk
device to read correctly (I can write to it, verified using
HexWorkShop).

Is there more to this than meets the eye? All the app. notes suggest
that this is a trivial thing to do (but I'm led to believe that the
CFA spec isn't worth the paper it's written on since no-one oversees
manufacturers' compliance, etc.)

Has anyone experienced anything similar/ any suggestions?

Many thanks,

David

david@phylida.co.uk (David Fussell) wrote in message news:<c2180e99.0408031103.5d0382bb@posting.google.com>...
> Hi,
> 
> I'm attempting to implement CF based storage  on an embedded platform
> (8051 clone- no OS), and have read a few app. notes on the subject,
> but I'm seeing some odd behaviour from the CF devices that I'm using
> (Kingston, SanDisk and Integral).

What size, model and year of production?

> 
> I've tried both memory mode and IDE modes of operation, with IDE
> giving me the most satisfactory results (I can read and write to
> Kingston and Integral devices), but I can't seem to get the SanDisk
> device to read correctly (I can write to it, verified using
> HexWorkShop).

I would be surprise that it is a design issue.  We tested hundreds of
Cfs (many Sandisks) on many PCs in IDE mode.  Occasionally, some PCs
do not work with any CFs, but most of them work fine.

> 
> Is there more to this than meets the eye? All the app. notes suggest
> that this is a trivial thing to do (but I'm led to believe that the
> CFA spec isn't worth the paper it's written on since no-one oversees
> manufacturers' compliance, etc.)
> 
> Has anyone experienced anything similar/ any suggestions?
> 
> Many thanks,
> 
> David

"David Fussell" <david@phylida.co.uk> wrote in message
news:c2180e99.0408031103.5d0382bb@posting.google.com...
> Hi,
>
> I'm attempting to implement CF based storage  on an embedded platform
> (8051 clone- no OS), and have read a few app. notes on the subject,
> but I'm seeing some odd behaviour from the CF devices that I'm using
> (Kingston, SanDisk and Integral).
>
> I've tried both memory mode and IDE modes of operation, with IDE
> giving me the most satisfactory results (I can read and write to
> Kingston and Integral devices), but I can't seem to get the SanDisk
> device to read correctly (I can write to it, verified using
> HexWorkShop).

Hi David,

Beware that the SanDisk App note relating to 8051 interfacing has timing
problems. I set mine up in common memory mode and had to poll the RDY line
before each register write, not just after a command, to get it to work
right.

It can be done, it has been done, and the FAT16 file system is available for
purchase. www.iinet.net.au/~vanluynm

Regards,
Murray R. Van Luyn.

"M.R.Van Luyn" <vanluynm@NOSPAM.iinet.com.au> wrote in message news:<41106d3d$0$16318$5a62ac22@per-qv1-newsreader-01.iinet.net.au>...
> "David Fussell" <david@phylida.co.uk> wrote in message
> news:c2180e99.0408031103.5d0382bb@posting.google.com...
> > Hi,
> >
> > I'm attempting to implement CF based storage  on an embedded platform
> > (8051 clone- no OS), and have read a few app. notes on the subject,
> > but I'm seeing some odd behaviour from the CF devices that I'm using
> > (Kingston, SanDisk and Integral).
> >
> > I've tried both memory mode and IDE modes of operation, with IDE
> > giving me the most satisfactory results (I can read and write to
> > Kingston and Integral devices), but I can't seem to get the SanDisk
> > device to read correctly (I can write to it, verified using
> > HexWorkShop).
> 
> Hi David,
> 
> Beware that the SanDisk App note relating to 8051 interfacing has timing
> problems. I set mine up in common memory mode and had to poll the RDY line
> before each register write, not just after a command, to get it to work
> right.
> 
> It can be done, it has been done, and the FAT16 file system is available for
> purchase. www.iinet.net.au/~vanluynm
> 
> Regards,
> Murray R. Van Luyn.


A bit more info- 

The SanDisk CF's appear to exhibit a 'data sensitivity' pattern. I can
write data quite happily to SanDisk and other manufacturers' devices,
with all devices (excluding SanDisk) reading back correctly.

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?!).

My read strobe has a transition time of around 25ns, which should be
plenty quick enough.

The SanDisk devices in question are 128MB, blue & red on the cover...

Any suggestions?

David

"David Fussell" <david@phylida.co.uk> wrote in message
news:c2180e99.0408051005.66b39f3c@posting.google.com...
> A bit more info-
>
> The SanDisk CF's appear to exhibit a 'data sensitivity' pattern. I can
> write data quite happily to SanDisk and other manufacturers' devices,
> with all devices (excluding SanDisk) reading back correctly.
>
> 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?!).
>
> My read strobe has a transition time of around 25ns, which should be
> plenty quick enough.
>
> The SanDisk devices in question are 128MB, blue & red on the cover...
>
> Any suggestions?
>
> David

Its a bit of a mystery? How do you have the media wired up?

This was how I ended up having to read registers with a 64MB Sandisk CF. The
trouble I had was making sure that the device was RDY for further register
operations. The Sandisk App note recommends polling RDY only after a command
like READ_SEC, that takes a while to fill the internal buffer. The reality
is that you have to wait for a RDY condition even after some simple register
manipulations. i.e. Setting  CYL_LO_REG etc.

unsigned char cflash_rd_reg(unsigned char reg)
{
    unsigned char byte = 0;

    // Select Register
    P3 &= 0xE3;                    // Clear A0..A2 on P3.2..P3.4
    P3 |= reg << 2;                // Set register address on A0..A2

    // Wait until Compact Flash Ready
    while (~RDY);

    // Select Compact Flash Chip
    CE1 = 0;

    // Select Read operation
    OE = 0;

    // Wait 125ns

    // Input Data
    byte = (P0 & 0x0F) | ((P2 & 0x0F) << 4);

    // Clear Read operation
    OE = 1;

    // Wait 20ns

    // Deselect Compact Flash Chip
    CE1 = 1;

    return byte;
}

Good Luck.

Regards,
Murray R. Van Luyn.

"David Fussell" <david@phylida.co.uk> wrote in message
news:c2180e99.0408051005.66b39f3c@posting.google.com...
> A bit more info-
>
> The SanDisk CF's appear to exhibit a 'data sensitivity' pattern. I can
> write data quite happily to SanDisk and other manufacturers' devices,
> with all devices (excluding SanDisk) reading back correctly.
>
> 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?!).
>
> My read strobe has a transition time of around 25ns, which should be
> plenty quick enough.
>
> The SanDisk devices in question are 128MB, blue & red on the cover...
>
> Any suggestions?
>
> David

Hi David,

Giving it some further thought, I now believe that you are describing the
same difficulty that I observed with the SanDisk media. The important thing
then is just to look for RDY before reading or writing any of the registers.

Please let me know how you get on. If there's a better way of addressing the
situation, I'd be very interested to know.

Regards,
Murray R. Van Luyn.

"M.R.Van Luyn" <vanluynm@NOSPAM.iinet.com.au> wrote in message news:<411378cd$0$16325$5a62ac22@per-qv1-newsreader-01.iinet.net.au>...
> "David Fussell" <david@phylida.co.uk> wrote in message
> news:c2180e99.0408051005.66b39f3c@posting.google.com...
> > A bit more info-
> >
> > The SanDisk CF's appear to exhibit a 'data sensitivity' pattern. I can
> > write data quite happily to SanDisk and other manufacturers' devices,
> > with all devices (excluding SanDisk) reading back correctly.
> >
> > 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?!).
> >
> > My read strobe has a transition time of around 25ns, which should be
> > plenty quick enough.
> >
> > The SanDisk devices in question are 128MB, blue & red on the cover...
> >
> > Any suggestions?
> >
> > David
> 
> Hi David,
> 
> Giving it some further thought, I now believe that you are describing the
> same difficulty that I observed with the SanDisk media. The important thing
> then is just to look for RDY before reading or writing any of the registers.
> 
> Please let me know how you get on. If there's a better way of addressing the
> situation, I'd be very interested to know.
> 
> Regards,
> Murray R. Van Luyn.

Hi Murray,

Well, I've fixed it- Seems my CS line was not being held low hard
enough! The SanDisk devices were causing some slight ringing on the CS
line when data was being output- enough to de-select and re-select the
device a couple of times, and with the read line held low throughout,
pumping out a byte of data for each 'bounce'. Buffering the CS line
resolves the problem.

For a while, I too was convinced that the status reg's RDY bit was
prematurely indicating the devices readiness, until I realised that my
masking condition was always going to return true...!

I'm using a Philips 80C552 MCU running at 14MHz, and I don't know how
this compares with your host, but I only poll for ready prior to
issuing commands, and DRQ once prior to reading the entire sector
buffer. This seems to work fine, maybe I've enough latency in the
instruction execution time...

Thanks for your suggestions.

David

David:  what were you using for the CS line initially? and... what did you 
use to finally?

Hul

David Fussell <david@phylida.co.uk> wrote:
> "M.R.Van Luyn" <vanluynm@NOSPAM.iinet.com.au> wrote in message news:<411378cd$0$16325$5a62ac22@per-qv1-newsreader-01.iinet.net.au>...
>> "David Fussell" <david@phylida.co.uk> wrote in message
>> news:c2180e99.0408051005.66b39f3c@posting.google.com...
>> > A bit more info-
>> >
>> > The SanDisk CF's appear to exhibit a 'data sensitivity' pattern. I can
>> > write data quite happily to SanDisk and other manufacturers' devices,
>> > with all devices (excluding SanDisk) reading back correctly.
>> >
>> > 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?!).
>> >
>> > My read strobe has a transition time of around 25ns, which should be
>> > plenty quick enough.
>> >
>> > The SanDisk devices in question are 128MB, blue & red on the cover...
>> >
>> > Any suggestions?
>> >
>> > David
>> 
>> Hi David,
>> 
>> Giving it some further thought, I now believe that you are describing the
>> same difficulty that I observed with the SanDisk media. The important thing
>> then is just to look for RDY before reading or writing any of the registers.
>> 
>> Please let me know how you get on. If there's a better way of addressing the
>> situation, I'd be very interested to know.
>> 
>> Regards,
>> Murray R. Van Luyn.
> 
> Hi Murray,
> 
> Well, I've fixed it- Seems my CS line was not being held low hard
> enough! The SanDisk devices were causing some slight ringing on the CS
> line when data was being output- enough to de-select and re-select the
> device a couple of times, and with the read line held low throughout,
> pumping out a byte of data for each 'bounce'. Buffering the CS line
> resolves the problem.
> 
> For a while, I too was convinced that the status reg's RDY bit was
> prematurely indicating the devices readiness, until I realised that my
> masking condition was always going to return true...!
> 
> I'm using a Philips 80C552 MCU running at 14MHz, and I don't know how
> this compares with your host, but I only poll for ready prior to
> issuing commands, and DRQ once prior to reading the entire sector
> buffer. This seems to work fine, maybe I've enough latency in the
> instruction execution time...
> 
> Thanks for your suggestions.
> 
> David

Hul Tytus <ht@panix.com> wrote in message news:<cf3n6e$lr3$1@reader1.panix.com>...
> David:  what were you using for the CS line initially? and... what did you 
> use to finally?
> 
> Hul

Hi Hul,

My CF CS line was being driven directly from a GAL device (don't have
the exact part number to hand- Lattice 16CV12???) which performs
address decoding for all the peripheral devcies, but the working
version takes the GAL's CF CS signal and passes it through a pair of
74ACT132 schmidt NAND gates (wired as inverting gates). The reasons
being a) I wanted to make sure the edges were as 'clean & quick'  as
possible, and b) it's all I had to hand. I expect the final version
will use a simple hex buffer device.

HTH

David

"David Fussell" <david@phylida.co.uk> wrote in message
news:c2180e99.0408061156.245555f2@posting.google.com...
>
> Hi Murray,
>
> Well, I've fixed it- Seems my CS line was not being held low hard
> enough! The SanDisk devices were causing some slight ringing on the CS
> line when data was being output- enough to de-select and re-select the
> device a couple of times, and with the read line held low throughout,
> pumping out a byte of data for each 'bounce'. Buffering the CS line
> resolves the problem.
>
> For a while, I too was convinced that the status reg's RDY bit was
> prematurely indicating the devices readiness, until I realised that my
> masking condition was always going to return true...!
>
> I'm using a Philips 80C552 MCU running at 14MHz, and I don't know how
> this compares with your host, but I only poll for ready prior to
> issuing commands, and DRQ once prior to reading the entire sector
> buffer. This seems to work fine, maybe I've enough latency in the
> instruction execution time...
>
> Thanks for your suggestions.
>
> David

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.

Regards,
Murray R. Van Luyn.