problem accessing a specific CF Card (Compact Flash) in 8-bit TrueIDE mode

Compact Flash Card Users!

We have developed a card reader/writer for Compact Flash (and
other cards) as part of a bigger controller chip my company
designs.

For Compact Flash, we have been using TrueIDE mode and the
8-bit feature for operation (each pin used costs money...),
to change the data register from 16-bit to 8-bit.

We have recently come across a CF card
(16Mb, branded "Choice Only", model C16ZH)

Which we are not able to read, all signs being that it is not switching
into 8-bit mode upon request.  This one does not go into 8-bit mode, nor
does it report 8-bit mode in error as an "unsupported feature".  And yes,
this card does know how to report an error; if I give it code for a
non-existant feature, it returns an error code.

We have tried dozens of  other different CF cards without incident, all
of them happy to go to 8 bit mode.

But reading sectors from this one, it is evident I am only getting the
even-numbered bytes, indicating 16-bit operation.

Other devices we have plugged it into (memory card readers, printers)
can read and write the card.

However, the devices we know the hardware architecture of use a
16-bit data path.

Does anyone know if:

a) This is actually a brain-damaged card and is unique.

b) All CF read/writers use a 16-bit data path because this is not a unique 
problem.

c) All CF cards handle TrueIDE and 8-bit operation properly, the error
is in my hardware and/or firmware.


My preferred answer is a.

I could almost live with c, if I had a clue of what I might be doing wrong.

Answer b is seriously painful.


Thanks,


Rufus

Rufus V. Smith wrote:

> Which we are not able to read, all signs being that it is not switching
> into 8-bit mode upon request.  This one does not go into 8-bit mode, nor
> does it report 8-bit mode in error as an "unsupported feature".  And yes,

>From the CF spec:

To conform to this specification, a CompactFlash Storage Card or CF+
Card must conform to all physical, electrical and Metaformat
specifications in this document. A CompactFlash Storage Card must
implement all PC Card and True IDE ATA commands listed in this
specification. Commands can be implemented as "no operation" to
meet this requirement. In addition, a CompactFlash card must implement
all commands in section 6 except the Security commands (F1 to F6).
While the security commands are optional, CFA members are encouraged to
implement them.

Then in the pinout, D8-D15 are marked with this note:

1. These signals are required only for 16 bit access and not required
when installed in 8-
bit systems. Devices should allow for 3-state signals not to consume
current.

Implicitly, all CF cards are required to implement 8-bit mode.

Just out of interest, is the card asserting _IOIS16 after you put it in
8-bit mode and do a sector read?

"larwe" <zwsdotcom@gmail.com> wrote in message 
news:1137108567.074790.187060@f14g2000cwb.googlegroups.com...
>
> Rufus V. Smith wrote:
>
>> Which we are not able to read, all signs being that it is not switching
>> into 8-bit mode upon request.  This one does not go into 8-bit mode, nor
>> does it report 8-bit mode in error as an "unsupported feature".  And yes,
>
>>From the CF spec:
>
> To conform to this specification, a CompactFlash Storage Card or CF+
> Card must conform to all physical, electrical and Metaformat
> specifications in this document. A CompactFlash Storage Card must
> implement all PC Card and True IDE ATA commands listed in this
> specification. Commands can be implemented as "no operation" to
> meet this requirement. In addition, a CompactFlash card must implement
> all commands in section 6 except the Security commands (F1 to F6).
> While the security commands are optional, CFA members are encouraged to
> implement them.
>
> Then in the pinout, D8-D15 are marked with this note:
>
> 1. These signals are required only for 16 bit access and not required
> when installed in 8-
> bit systems. Devices should allow for 3-state signals not to consume
> current.
>
> Implicitly, all CF cards are required to implement 8-bit mode.
>
> Just out of interest, is the card asserting _IOIS16 after you put it in
> 8-bit mode and do a sector read?
>

That is the way I read the spec, too!  I certainly wouldn't expect
a shipped part to not be compatible at this stage of the game.

I will check that signal, assuming it is valid in TrueIDE mode.
(Will look at it in 8 and 16 bit modes on known good and the
"ornery" card)


Stay Tuned.

Rufus 

"Rufus V. Smith" <nospam@nospam.com> wrote in message
news:43c6dbe8$0$30406$6d36acad@taz.nntpserver.com...
> We have recently come across a CF card
> (16Mb, branded "Choice Only", model C16ZH)
>
> Which we are not able to read, all signs being that it is not switching
> into 8-bit mode upon request.  This one does not go into 8-bit mode, nor
> does it report 8-bit mode in error as an "unsupported feature".  And yes,
> this card does know how to report an error; if I give it code for a
> non-existant feature, it returns an error code.
>
> We have tried dozens of  other different CF cards without incident, all
> of them happy to go to 8 bit mode.
>
> But reading sectors from this one, it is evident I am only getting the
> even-numbered bytes, indicating 16-bit operation.
>
> Other devices we have plugged it into (memory card readers, printers)
> can read and write the card.
>
> However, the devices we know the hardware architecture of use a
> 16-bit data path.
>
> Does anyone know if:
>
> a) This is actually a brain-damaged card and is unique.
>
> b) All CF read/writers use a 16-bit data path because this is not a unique
> problem.
>
> c) All CF cards handle TrueIDE and 8-bit operation properly, the error
> is in my hardware and/or firmware.
>
>
> My preferred answer is a.
>
> I could almost live with c, if I had a clue of what I might be doing
wrong.
>
> Answer b is seriously painful.
>
>
> Thanks,
>
>
> Rufus
>
>
>

Hi Rufus,

I've seen this!!  Came across it a few months back while developing a
library.  I have about a dozen cards, all different sizes, all sorts.  And
there's just one card which doesn't behave.  It won't reply to the ID E9h (i
think it is) command.  Put it into a camera or laptop and no problems at
all.  It behaves like this in both 8 and 16bit mode.  Will read and write
sectors no problems though.

Also...  I discovered that some commands return their 512byte results in big
endian, and others little endian..  Spinning IDE drives also do it too...
Not widely documented and made obvious either.

What I've also found out is that you can 'kill' a CF card by writing to it's
lower sectors.  Well 'killed' is perhaps a bit OTT as you can still use it
in a CF reader and via the logger library I've developed.  But insert it
into a camera and it can't initialise it, format it, nothing.

Hope this helps somewhat :-)  It's a balance between following the specs to
the letter and trial and error.

alyc wrote:
> "Rufus V. Smith" <nospam@nospam.com> wrote in message
> news:43c6dbe8$0$30406$6d36acad@taz.nntpserver.com...

<snip>

> What I've also found out is that you can 'kill' a CF card by writing
> to it's lower sectors.  Well 'killed' is perhaps a bit OTT as you can
> still use it in a CF reader and via the logger library I've
> developed.  But insert it into a camera and it can't initialise it,
> format it, nothing.

I'd like to know more about what parts of the CF you write to in order to 
cause these problems. And what cameras you have experience of that are 
unable to re-format.