Compact Flash and 8051

What size, model and year of production?

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.

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.

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

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 wrote:

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

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.

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

Check the manual again. I just looked at some code used for programming a

161 and 162 and only the 53h byte was checked. The manual might agree.

Hul

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

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

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:

. Contact me directly if you need someone at avisaro who speeks Englisch.

Matt

Avisaro AG