CF-CARD Read Problems

[cbscpe]

Hi,

first I wish you all a happy new year.

But now to the real subject. I have hear a very strange problem. Strange in a sense that I have no clue how I should further debug the issue. Here some background information.

I have a 65C816 based system and use a CF-Card as the main storage. For this I used normal CF-Card IDE-40 PIN Adapters and connected the IDE directly to the CPU BUS. That is the IDE is connected to A0, A1, A2 and D0..D7 of the CPU. IORD and IOWR are qualified with PHI2 and CS0 is the select signal all these signals are created using a GAL22V10. CS1 is tied to VCC. Very much the same as in Grants Z80 CP/M setup.

Now the strange thing: I have one CF-Card IDE-Adapter that works perfectly with all CF-Cards I have tested so far. I can boot, read and write files. But all other CF-Card Adapters fail. Even a CF-Card Adapter that is identical to the one that works does not work.

I have started to write test programs and what I see with the non-working Adapters is that I do not get all bytes from a block. For example if I check DRQ then I do not get 512 times a DRQ when transferring the block/sector.

It actually does not matter If I run the system with lower clock speeds (I tried anything from 100kHz to 5MHz). The working adapter works perfectly with any clock rate.

I'm completely lost and any idea how I should proceed is appreciated.

Cheers

Peter

[Dr Jefyll]

cbscpe wrote:

first I wish you all a happy new year.

Happy new year to you, too, Peter, and to the rest of the gang!

Quote:

I have one CF-Card IDE-Adapter that works perfectly [...] But all other CF-Card Adapters fail.

Maybe they all "should" fail.

I've seen cases where something was built wrongly or hooked up incorrectly, but nevertheless managed to work due to a fluke -- for example, an unused CMOS input that was supposed to be tied high or low but instead was accidentally left unconnected. The fluke is when stray resistance on the PCB causes the unconnected input to drift to the appropriate state. A situation like this can become a real nightmare if one is misled into believing "the circuit must be OK -- it works!" Unconnected CMOS inputs aren't the only potential source of "trouble" -- trouble in this context meaning the thing works!

Well, my theory may not have a bearing on your situation at all, but it seemed worth mentioning. Can you supply more info, Peter -- photos, maybe, and more detail re the signals involved? Also -- just double-checking -- you mean you tied directly to the '816 multiplexed data bus (NOT downstream of a '245 transceiver)?

cheers,
Jeff

[8BIT]

I'd double check how the 5v power is getting to the CF module. Some adapters allow pin 20 of the IDE connector to provide 5v, others require you to use the 4 pin power connector. If you are using pin 20, I'd suggest trying the 4 pin connector.

Daryl

[cbscpe]

Thanks for you input

Dr Jefyll wrote:

Maybe they all "should" fail.

good point, perhaps I should try to connect all unused pins to GND / VCC one after the other until I see a change in behavior. Either to the good or the worse. It's really as if the only CF-Card Adapter that works is only working by chance and not be design. However the fluke is quit reliable, even when I reconnect all connections to test other CF-Card adapters and then go back the working one this one never fails.

And yes I have connected the CF Card directly to the CPU, no '245 or whatsoever. I don't see any reason why this should be a problem IORD and IOWR are gated with PHI2 so the bus-states of all data pins are as they would be using a '245. Also if this is an issue then why is one CF-Card adapter working and the other's not, which brings us back to your first point. So I will do this first. I need to understand the difference in the behavior.

8BIT wrote:

I'd double check how the 5v power is getting to the CF module. Some adapters allow pin 20 of the IDE connector to provide 5v, others require you to use the 4 pin power connector. If you are using pin 20, I'd suggest trying the 4 pin connector.

Power is feed on a dedicated power connector, this is a 40-PIN IDE Adapter for CF-Cards. PIN 20 is normally the "key" and typically has no PIN as the IDE Cables have PIN20 covered/filled. It is currently not connected in my setup and I use as you say the 4-poin power connector to feed 5V.

[Aslak3]

Quote:

Power is feed on a dedicated power connector, this is a 40-PIN IDE Adapter for CF-Cards. PIN 20 is normally the "key" and typically has no PIN as the IDE Cables have PIN20 covered/filled. It is currently not connected in my setup and I use as you say the 4-poin power connector to feed 5V.

Using the normally "keyed" pin 20 as power is a little trick done on some IDE->CF adapters, to save a Berg. I make use of this on my own PCBs to save a power connector. I can always pull out the pin if I wanted to attach a regular PATA IDE cable for a hard disk.

[BigDumbDinosaur]

cbscpe wrote:

Now the strange thing: I have one CF-Card IDE-Adapter that works perfectly with all CF-Cards I have tested so far. I can boot, read and write files. But all other CF-Card Adapters fail. Even a CF-Card Adapter that is identical to the one that works does not work.

Working on the cheerful assumption that it is unlikely you have multiple defective adapters, perhaps there is a subtle voltage level issue involved. Do you have a data sheet for the adapter? Perhaps there's something involving input and/or output voltage levels that is not consistently producing solid logic states.

[Dr Jefyll]

cbscpe wrote:

Dr Jefyll wrote:

Maybe they all "should" fail.

good point, perhaps I should try to connect all unused pins to GND / VCC one after the other until I see a change in behavior.

Alright. But unconnected CMOS inputs is just an example. I once had a device that worked... but only in the dark. The problem was a sleeper -- and had nothing to do with unconnected CMOS inputs. Another time I accidentally created a situation where a program relied on the contents of one uninitialized byte of memory (which, after power-up, was unfortunately about 95% consistent). Another sleeper. (Lotta hair-pulling on that one. I was under pressure, and it was murder. )

The moral of the story is, "working" doesn't always mean unworthy of further thought and examination. With your CF-Cards, if you approach the situation asking, "why do most of these fail?" then that line of thought could be a dead end. Asking instead, "why are these ALL defective" can lead to different answers.

Quote:

yes I have connected the CF Card directly to the CPU, no '245 or whatsoever. I don't see any reason why this should be a problem

I didn't mean to imply it was incorrect. I'm just trying to get more background, as you haven't posted a schematic. It may be fairly trivial, but I don't trust myself to simply imagine it.

[cbscpe]

I reactivated my old ATmega162 based project where I tested all the 8-bit data bus mode of CF-Cards. So I can confirm the adapters are working. Anyhow these adapters are 100% passive, they just physically adapt the 40-pin IDE to a CF-Card Slot wired for CF-Cards operating in TRUE IDE mode.

At the moment I'm still following the suggestions of Jeff and try to find the "loose" input.

[cbscpe]

I checked all wires and signals and found one major issue. The working adapter is defect!!! The trace from VCC of the CF Card slot to the power connector is broken. As a cross check I attached one of the non working adapters to the 65C816 system but did not connect VCC (5V) to the CF adapter and the system boots perfectly from this setup. I suppose one of the inputs tied to Vcc (DMACK and CS1) provides power to the CF CARD. But I don't understand what really happens and why a correct setup with a working VCC connection does not work but one without VCC does. Any ideas?

Btw the trick to use pin 20 as power pin is excellent, thanks for the tip.

[Dr Jefyll]

Huh! You've confirmed the theory that it's the seemingly correct unit which is anomalous, rather than the superficially suspect units -- the ones which don't work. But I'm still puzzled. You still haven't posted a schematic, Peter!

Quote:

I suppose one of the inputs tied to Vcc (DMACK and CS1) provides power to the CF CARD.

Meaning the CF's Vcc is powered from current flowing through the on-chip input-protection diodes? That sounds logical. Which brings a thought to mind...

Correct me if I'm wrong, but I thought CF cards (or at least some CF cards) are supposed to run on 3.3V, not 5V. And if the card is powered through its input-protection diodes then there'll be a voltage drop, meaning that the card sees not 5V but something closer to its 3.3V spec. In those conditions the CF could be reliable, but with the full 5V applied maybe it becomes flaky. Can you confirm the rated voltage and actual voltage, please?

[barrym95838]

Dr Jefyll wrote:

... I once had a device that worked... but only in the dark. The problem was a sleeper -- and had nothing to do with unconnected CMOS inputs ...

You didn't tell us the story, doc!

Slightly off-topic anecdote:
My friend came to me with a concern on her old Toyota ... the cruise control refused to engage at night, but worked fine during the day! I was able to trace it to a defective "1157" combination tail-light/stop-light bulb. The lead nipples at the base of the bulb had deformed enough to barely touch each other, causing the tail-light power to back-feed the brake-light circuit. The cruise-control module checks for brakes-applied and disengages for safety reasons. There was a considerable voltage drop across the short, so the tail lights actually did brighten noticeably when the brake pedal was pressed, but there was enough voltage to convince the cruise control module that the brakes were on even when they weren't. The clue that caught my attention was a dimly-lit center brake light when the tail lights were turned on. Fresh bulb ... problem solved!

1157.jpg (4.55 KiB) Viewed 2598 times

Mike B.

[Dr Jefyll]

barrym95838 wrote:

Fresh bulb ... problem solved!

Good one, Mike!

Quote:

You didn't tell us the story, doc!

Yeah, well, it's kinda embarrassing -- as is the story about the uninitialized memory byte. In that case my downfall was wondering whether I was fighting a hardware or software fault, since the hardware and software were both new. But in fact both hardware and software were involved.

I knew the fault was intermittent. And, by mucking around with the power supply and I forget what else I discovered it was possible to have some limited influence on whether the system worked or failed (in hindsight, whether that uninitialized byte in RAM would wake up "right" or "wrong" after power-up -- it was actually only ONE BIT that mattered). Anyway, mucking around with hardware produced a result, and that convinced me I was dealing with a hardware problem. But it was 100% a software fault -- one of the face-palm variety -- which produced a flaky result based on hardware.

The details are foggy, as this all happened in the late 1980's. But IIRC I was actually aware I was accessing an uninitialized byte, and concluded it didn't matter! I was using an RTI instruction to jump to an address that had gotten pushed on stack. Through some forgotten chain of cause & effect, that meant the processor status register, P, would get loaded with garbage from a dummy byte also pushed to stack. But it didn't seem important, since all I cared about was the address of the routines I'd be jumping to. The routines made no assumptions about Negative, Overflow and so on, so who cares, right? Um... Except. For. Decimal. Mode.

As for the system that only worked in the dark, that was much simpler. I was using an EPROM-based microcontroller (MC68HC705), and in those days I never bothered to cover up the little window in the EPROM because I didn't know any better and had never had a problem. Fortunately, when my luck ran out a colleague informed me that photoelectric effects can upset the chip, and it really is best to cover the window so it's kept in the dark.

[BigDumbDinosaur]

Dr Jefyll wrote:

As for the system that only worked in the dark, that was much simpler. I was using an EPROM-based microcontroller (MC68HC705), and in those days I never bothered to cover up the little window in the EPROM because I didn't know any better and had never had a problem. Fortunately, when my luck ran out a colleague informed me that photoelectric effects can upset the chip, and it really is best to cover the window so it's kept in the dark.

That's why I keep my office lighting dim. Plus if it's dim I won't see any crawlers that are hanging around.

[cbscpe]

Here the current schematic.

CF Card System

As for CF-Cards those with the parallel interface all support 5V (they must support 5V operation in order to meet the ATA standards) and most work with 3V3 as well.

[Dr Jefyll]

cbscpe wrote:

As for CF-Cards those with the parallel interface all support 5V (they must support 5V operation in order to meet the ATA standards) and most work with 3V3 as well.

Well, I'm no expert on CF cards, but I still think the theory of a voltage drop across the input-protection diodes bears investigation. For one thing, the issue you're facing is pretty clearly related to power. And, the adapter in the photo Aslak3 posted above has a jumper that pertains to 3 volts vs 5 volts. Granted, most CF's may work with 5V or 3V3 as you say, but apparently they don't just automatically accept whatever voltage they get.

Just thinking out loud...