CF-CARD Read Problems

[Martin A]

Try disconnecting the 5v from pin 29.

[cbscpe]

Hi Jeff,

I fully agree with you, it has to do with some supply voltage level. Even more as the following works: CF Card is powered using a 1N4148 and /CS1 is connected to VCC via a 2k2 resistor. But on the other hand the following SanDisk CF Card specifications clearly state they support 5V and 3V3 volts https://images-na.ssl-images-amazon.com ... 007765.pdf

Still no clue what is the cause. At least I have a working setup, only can't tell why it works.

Cheers Peter

[cbscpe]

Hi Martin,

disconnecting pin 29 has no effect. Whether I connect it to 5V or via 2k2 to 5V or leave it open. Only with VCC connected via a diode makes the CF Card behave as I like.

Cheers Peter

[BigDumbDinosaur]

cbscpe wrote:

But on the other hand the following SanDisk CF Card specifications clearly state they support 5V and 3V3 volts https://images-na.ssl-images-amazon.com ... 007765.pdf

Yes they do. However, there is also a somewhat cryptic comment about "0 volts". It's not making a whole lof sense to me, but then, I'm up relatively early.

[Dr Jefyll]

BigDumbDinosaur wrote:

cbscpe wrote:

But on the other hand the following SanDisk CF Card specifications clearly state they support 5V and 3V3 volts https://images-na.ssl-images-amazon.com ... 007765.pdf

Yes they do. However, there is also a somewhat cryptic comment about "0 volts". It's not making a whole lof sense to me, but then, I'm up relatively early.

To me the cryptic comment (below) seems to say this particular Sandisk CF will run at 5V or 3.3V, but at powerup you must apply one or the other and subsequently stick with that voltage. If for some reason (low battery?) the voltage you supply goes off the chosen spec by more than 20% then you need to start over by taking the CF to zero volts and powering it up again.

• "This is a dual voltage product, which means it will operate at a voltage range of 3.30 volts ± 5% or 5.00 volts ± 10%. Per the PCMCIA specification Section 2.1.1, the host system must apply 0 volts in order to change a voltage range. This same procedure of providing 0 volts to the card is required if the host system applies an input voltage outside the desired voltage by more than 20%. This means less than 4.0 volts for the 5.00 volt range and less than 2.70 volts for the 3.30 volt range."

cbscpe wrote:

At least I have a working setup, only can't tell why it works.

Glad you got things working! Do you want to get to the bottom of this? A few questions:

You've provided a spec for a Sandisk product, but are the CF's you're using actually that particular product? (I expect the PCMIA spec they cite is more general, and would be preferable, but apparently a copy costs $100, and seems to be unavailable anyway. A web search reveals that PCMCIA evolved through a transition -- well, several, actually -- but single-voltage and dual-voltage devices are part of the saga.)

cbscpe wrote:

CF Card is powered using a 1N4148 and /CS1 is connected to VCC via a 2k2 resistor.

The 1N4148 goes from the CF's Vcc to +5, right? And the 2k2 goes from /CS1 to the CF's Vcc (not the '816's Vcc, which is +5), right? Just checking!

Can you put a voltmeter on the CF's Vcc please and tell us:

• what's the voltage when connected in the won't-work configuration? (Nominal +5, I realize, but is it within ± 5%?)
• what is the voltage in the configuration that works?

-- Jeff

[clockpulse]

"-VS1 -VS2 - pin 33, 40
Voltage Sense Signals. -VS1 is grounded so that the CompactFlash Card CIS can be
read at 3.3 volts and -VS2 is open and reserved by PCMCIA for a secondary voltage."

Maybe check these pins?

[Dr Jefyll]

clockpulse wrote:

-VS1 is grounded so that the CompactFlash Card CIS can be read at 3.3 volts

Good call! -- this is apparently part of the transition saga. If Peter's using the Sandisk product whose doc he provided then voltage selection doesn't rely on voltage-select pins. But the pins may be relevant for anyone using a CF of different vintage or from a different manufacturer.

[clockpulse]

Also, the Sandisk PDF document shows that Vcc is Pin 13 and Pin 38.

[cbscpe]

Thanks for your inputs and suggestions.

As Jeff says, the CF Cards run at either 3.3V or at 5V and you cannot switch between the supported ranges without going via 0V. At power-up they "learn" which logic levels they need to operate at.

I'm indeed using a 256Mbyte SanDisk CF Card and the specs are for this model. Cards from other vendors show the same behaviour. So I don't think it is a SanDisk specific issue.

The voltmeter tells me 5.006V at VCC and 4.5...V after the diode. It's a calibrated Fluke voltage meter, so I'm definitively within the accepted range. And yes the 2k2 connects the 4.5V side of the diode with /CS1.

The Diode goes from VCC to the CF-Card and connects to Pin 13 and 38 of the CF Card. (Pins 13 and 38 on the 50-Pin CF-Card slot are indeed VCC for the CF-Card this is perfectly correct). The official CF Cards specs up to version 3.0 are available on the internet and they don't tell really new things about the CF Cards. I don't use the legacy PCMCIA modes, I'm only interested in the True IDE mode as this provides the easiest interface to a Microprocessor (it just is a IO device with 8 registers, in fact a perfect match, also CF Cards must support an 8-bit data interface, in fact they can be seen as IDE disks with a 8-bit data bus) and decent CF Cards with several hunderds of Megabytes are very fast (at the moment using the diode the SBC runs at 5.5MHz without any glitch).

-VS1 and -VS2 are not applicable to True IDE mode. True IDE mode is mandatory for storage only cards (there are also CF+ cards with other features than storage) and they signal to the host at which voltage the CIS can be read. In True IDE mode this information must be retrieved via an ATA command the -OE signal is not available in this mode as it is used to signal the card to boot up in True IDE mode and it must be tied to ground. In True IDE mode the must support operation at 5V.

I really would like to understand the issue in order to be sure the final setup works per design and not by trial and error. Next thing will be some buffers (one 74HC245 and one 74HC244) so all signals to the CF-Card will be buffered in order to be able to power cycle the CF-Card for tests (actually I consider this also in the final setup so I can hot-swap CF-Cards)

[Dr Jefyll]

Quote:

The voltmeter tells me 5.006V at VCC and 4.5...V after the diode.

Hmm, 4.5V or so is probably what the CF was getting on Friday, back when it was inadvertently being powered via the input-protection diode (rather than the 1N4148).

I have a half-baked theory that says the main board has noise on the +5 -- spikes during which the voltage briefly sags below +5 -- to which the CF is sensitive (more sensitive than the circuitry on the main board). Having the diode there tends to isolate the CF from the noise because the diode will stop conducting during the sags, and the CF will be sustained by its bypass caps. (The diode also changes the current waveform on the Gnd & supply conductors feeding from the main board to the CF, thus possibly alleviating some unnoticed shortcoming in the layout or wiring practices.... but that's a different half-baked theory! )

Can I suggest you try adding a lot of extra bypass capacitance to the main board? As an experiment, temporarily connect one or more high-quality electrolytic caps (tantalum, maybe, not aluminum) from Gnd to Vcc, keeping the leads short. Then see if the CF will work when you connect it directly to +5 (ie, short out the diode). If adding extra bypass capacitance allows normal operation (ie, with the CF tied straight to +5, no diode), then I'd look into the matter further. For example you may well have fractional-cycle instants of bus contention that cause so much extra noise the original caps are inadequate.

ETA:

cbscpe wrote:

Next thing will be some buffers (one 74HC245 and one 74HC244) so all signals to the CF-Card will be buffered in order to be able to power cycle the CF-Card for tests (actually I consider this also in the final setup so I can hot-swap CF-Cards)

I overlooked your mention of the '245. Adding THAT could be crucial, and not because of hot-swap considerations. Presently you have no transceiver isolating the multiplexed lines d7-d0 from the rest of the data bus, and that means increased risk of contention.

(I'm talking about contention on a fine time scale, where the opposing drivers have no problem for the majority of each half-cycle but they butt heads for 5 ns or so during the handover from one driver to the other. This is illustratated in Managing the 65816 multiplexed bus).

[cbscpe]

Hi Jeff,

yes 4.5V is probably what it got on Friday as well via the internal diode and your theory is more then a half-baked suspicion. You are right all other components currently used in the system are specified for a large voltage range (all components support at least a 3 to 5.5V range) so they are quite immune to noise. Thanks for pointing out. As for the congestion, I doubt this is the issue. First I have added the buffers (74HC245 and 74AC541) in the meantime without any change in the behavior and second all output enables are gated with PHI2 (OE of RAM, IORD of CF-Card, etc) so there should be no congestion even with a 65C816.

So next topic is checking power.

Cheers

Peter

[Dr Jefyll]

cbscpe wrote:

I have added the buffers (74HC245 and 74AC541) in the meantime without any change in the behavior and second all output enables are gated with PHI2 (OE of RAM, IORD of CF-Card, etc) so there should be no congestion even with a 65C816.

It's good that you isolated the CF from the CPU's D7-D0, but the EPROM is still tied in directly, n'est pas? I realize the EPROM /OE is deasserted when Ø2 is low, but there could still be a significant degree of contention. It's a bit optimistic to suppose the EPROM, the UART and the RAM are all capable of relenquishing the bus promptly when told to do so. EPROM's in particular aren't especially fast devices, and I can easily believe it's head-butting with the CPU for 10 ns or more before finally letting go of the bus. During that time the power supply rails get smacked!

Here's another way of explaining. If someone had an '816 system and failed to qualify an OE (for example) then there'd be contention that lasts for half-cycles at a time. THAT kind of contention is very severe, but luckily it's widely understood, and also pretty easy to fix.

Less severe but still a problem -- also much harder to fix and NOT widely understood -- is contention on a finer time scale, caused by the chips' internal delays in obeying their OE input. Contention could be eliminated if all chips on the bus received their OE commands simultaneously and obeyed those OE commands in a timely fashion, but reality conspires against both of those propositions!

WDC recommends using a '245 bus transceiver with the '816, which means the data bus is split into two portions. IMO that doesn't eliminate the problem but it can help a great deal. The mux'ed portion is driven only by the '816 and the '245, which means RAM and I/O needn't participate in timing-critical bus handoffs with the CPU. Having the '245 there also physically shortens the mux'ed portion of the bus, helping with EMI and signal integrity. Perfect handovers can't be guaranteed, which means contention-related current spikes won't be entirely eliminated. That's a good reason to keep the bus short.

Certainly it's possible to deviate from WDC's recommendation of including that '245 bus transceiver, but it's a tradeoff with downsides that including potential difficulty with power supply noise. I'll be interested to hear what you discover, Peter!

[cbscpe]

I added some tantalum and some other capacitors and I have now two CF-Cards that work without a diode. Your half-baked theory is more like bulls-eye In other words the final setup needs to pay special attention to noise on 5V. I'm sure that was the issue, else those capacitors would never have helped.

As for the other points they will disappear soon. First I had no intention to use a W65C816 but I have no W65C02 at hand. I still need to order some. That was definitively a big mistake and might be the source of most of the noise on 5V. Especially when you think that disabling outputs is slower than enabling, so it is make before break and not break before make, which is very bad actually. The EPROM will be replaced by a blind-load mechanism. The goal actually was to add the CF-Card to ROMulus 1st but before messing up with a running system I built a dedicated test environment.

One point I'm still not convinced is the importance of the contention situation. It is true that the databus of the W65C816 is always an active output when PHI2=low. But that does not cause any issues with reading data from any device (IO, EPROM, RAM). It will only cause some excess current during transition but not more. Mostly during the leading edge of PHI2. When you don't need A16..A23 this will not be an issue. On the falling edge of PHI2 this is less an issue as the W65C816 will definitively wait tdhr (10ns) before activating the output, else it would violate it's own requirement regarding data hold time.

Thanks a lot for your thoughts and hints, they were very useful.

Cheers

Peter

[Dr Jefyll]

cbscpe wrote:

I have now two CF-Cards that work without a diode.

Awesome! I love how you ended up fixing the computer (which was working) and also a Compact Flash (which was working), but you didn't have to do anything to the other CF's -- which weren't working!

Quote:

break before make

Right, break before make (or, worst-case, simultaneous break/make) is what you want. IOW the dead time should be >= 0. (But I'm not sure why you said, "disabling outputs is slower than enabling." Surely for some chips that'll be true, and for others not?)

Quote:

On the falling edge of PHI2 this is less an issue as the W65C816 will definitively wait tdhr (10ns) before activating the output, else it would violate it's own requirement regarding data hold time.

Good point. Part of the spec for the 816's output enable is found by examining the spec for its input requirements!

Quote:

I'm still not convinced is the importance of the contention situation.

Quote:

It will only cause some excess current during transition but not more.

Quote:

I had no intention to use a W65C816 [...]That was definitively a big mistake and might be the source of most of the noise on 5V.

So you're not convinced the source of most of the noise is important? Maybe you're saying the problem will go away when a 'C02 replaces the '816, so why worry.

Quote:

Thanks a lot for your thoughts and hints, they were very useful.

You're welcome -- thanks for sharing a great story with us! BTW, after you put a 'C02 in there, would you be willing to try removing those extra caps you added, and reporting back to us regarding the result?

-- Jeff

[cbscpe]

Dr Jefyll wrote:

So you're not convinced the source of most of the noise is important? Maybe you're saying the problem will go away when a 'C02 replaces the '816, so why worry.

No I'm not and if it is then it would be the same issue with any 65816 based System. Because if you look at a 65816 system you can assume that only one peripheral device (RAM, IO, ROM, ....) will have it's chip select asserted and that will be the only one involved in a contention situation with the data bus of the CPU. Now when we follow the recommendation of WDC then we have 'only' a '245 competing for the data bus with the CPU on the leading edge of PHI2. And in most cases a '245 is worse than any peripheral, this beast is a high current bidirectional buffer/Driver with a very low output impedance. I argue that a '245 produces even more noise. As my final goal (not this system) still is a 65C816 based system I need to find a solution for this and anybody building a 65C816 system as well. I always thought that it is a pitty that there is no 65C816 with a non multiplexed address bus, a TQFP-44 case would have enough pins for A16..A19 and if you ommit some of the rarely useful signals even for all address signals.

Dr Jefyll wrote:

..., after you put a 'C02 in there, would you be willing to try removing those extra caps you added, and reporting back to us regarding the result?

I will but it will take some time before I place an order with mouser. The problem in Switzerland is that customs and handling is so expensive that you better make sure your order is worth the administration fees of swiss customs. Mouser, digikey etc. all have swiss web pages but they do not deliver from within Switzerland, and those which do send from within Switzerland are very expensive and do not have the W65C02.


Cheers

Peter