Compact flash pinout?

[barnacle]

We're getting somewhere, I think. I gave up with the original code and wrote it all from scratch, and was able to demonstrate that I could read and write the visible registers - at least for the SanDisk ultra II 2.0GB card. From that card also - and only that card - I do get something which appears at least sensible, contains ascii, and is consistent between reboots.

I note a _long_ delay after the reset - several thousand loops. I still need to break out the appropriate fields of the info block to see if it's sensible, but...

Code: Select all

10869 [loops waiting for not busy)                                                  
0 20  [data read before writing]                                                                            
1 01                                                                            
2 01                                                                            
3 01                                                                            
4 00                                                                            
5 00                                                                            
6 00                                                                            
7 50                                                                            
809                                                                             
0 20  [and after writing]                                                                            
1 00                                                                            
2 01                                                                            
3 01                                                                            
4 00                                                                            
5 00                                                                            
6 e0                                                                            
7 50                                                                            
End init                                                                        
0                                                                               
1                                                                               
8a 84 82 0f 00 00 10 00 00 00 40 02 3f 00 3d 00 - ���@-+                        
e0 0f 00 00 20 20 20 20 30 30 31 34 33 32 31 42 - �    0014321B                 
30 33 53 35 37 32 35 34 02 00 02 00 04 00 44 48 - 03S57254DH                    
20 58 2e 34 30 33 61 53 44 6e 73 69 20 6b 44 53 -  X.403aSDnsi kDS  (hmm, there's some byte reversal there)              
46 43 32 48 32 2d 34 30 20 38 20 20 20 20 20 20 - FC2H2-40 8                    
20 20 20 20 20 20 20 20 20 20 20 20 20 20 04 00 -                               
00 00 00 03 00 00 00 02 00 00 03 00 82 0f 10 00 - �                             
3f 00 e0 0f 3d 00 00 01 e0 0f 3d 00 00 00 07 00 - ?�=�=                         
03 00 78 00 78 00 78 00 78 00 00 00 00 00 00 00 - xxxx                          
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -                               
10 00 00 00 00 00 04 40 00 40 00 00 04 00 00 40 - @@@                           
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -                               
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -                               
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -                               
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -                               
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -

Neil

[barnacle]

Hah, turns out they're stored as sixteen bit words, big endian. How strange... a certain amount of turning around gives me:

Code: Select all

  Serial:     004123B1305S2745                                                  
Revision: HDX 4.30                                                              
   Model: SanDisk SDCFH2-2048 

Neil

[BigDumbDinosaur]

barnacle wrote:

Hah, turns out they're stored as sixteen bit words, big endian. How strange... a certain amount of turning around gives me:

Code: Select all

  Serial:     004123B1305S2745                                                  
Revision: HDX 4.30                                                              
   Model: SanDisk SDCFH2-2048 

Sixteen-bit, big-endian format and mass storage seem to be old friends.  All the multibyte fields in a SCSI command descriptor block (CDB) are big-endian, which was inherited from the ancestral SASI bus developed in the late 1970s.  I’ve long suspected that Motorola had something to do with it, since an early use for the big-endian MC68000 was in minis that used SASI to talk to their disks. 

When I adapted SCSI to my POC unit, I took advantage of the 65C816’s XBA instruction to reverse the endianess of 16-bit data that is processed during a SCSI transaction.  Back when I did that sort of thing with the 65C02, it had to be done a byte at a time—a lot more code was involved. 

[barnacle]

After an afternoon's investigation, I'm not much further along. It turned out that the sandisk was unrecognised as a drive by by Linux box (via a generic adaptor thingie) though it saw it going in and got the size right. It decided it was unformatted, so I reformatted FAT32 and stuck a few text files and directories on it for later testing. It still reads the info block correctly (after adding an extra busy check) so we're all good there.

The other two cards are both correctly recognised by Linux, but don't even read and write to the visible registers using the Nucleo to talk to it. Strange... possibly I'm missing something on the adaptor card; I have a couple of generic CF to IDE adaptors coming from China.

I investigated the timings further. At 3v3 CF cards are basically 600ns parts; at 5v, 300ns. There are interesting required delays within the timing, too, but my Nucleo is pretty slow: setting the bit in the register to set or clear a control pin output takes four ARM instructions with a minimum time between toggle changes of a microsecond or so. Perhaps it's too _slow_ for the cards that don't work?

Neil

[barnacle]

Very strange: things which worked yesterday work only very intermittently today. I'm suspicious of the hardware...

Neil

[Dr Jefyll]

Can you post photos and a schematic of what you're doing? It's a common refrain, I know...

In particular, supply bypassing and the routing of Gnd/Vcc connections may merit special attention. The unstable nature of the behavior you report is consistent with (though not proof of) a signal integrity problem. And I've heard that compact flash devices are challenging in this regard, given the fast switching speeds and the large number of simultaneously changing outputs on the parallel interface...

-- Jeff

[barnacle]

There's a pdf of the circuit diagram of the interface card between a Nucleo and the CF card in an earlier post, Jeff.

I'm not sure how helpful a photo will be: here's the PCB, absent the ground plane where all those red ground connections stick out.

Usual JLCPCB circuit board, double sided, nothing fancy, perched on top of the Nucleo.

I am starting to wonder if the Nucleo is just too slow to drive it; the edges are fast enough, but the access time is coming out around five microseconds. Seems unlikely though.

Neil

[plasmo]

I have not commented about your CF issues because all my CF interfaces are through the IDE44 header which requires a CF-to-IDE adapter so I didn't think I'm qualified to comment on your CF issues. However, in term of signal integrity, I do know something about fast edges and simultaneous switching of CF data bus. I usually have 100 ohms serial terminator close to CF data pins and I also have a 100ohm/100pF RC filter close to CF read line. Please see the lower right corner of the attached schematic. This is a picture of my ZG6502 rev1 with prototyped CF interface correspond to the schematic. You can see a row of 8 100ohm resistors connected to CF data bus and a 100ohm/100pF RC filter on the CF read line.
I'm able to talk to CF card via W65C22 which is not particularly fast since I have to wiggle the control lines (CFchipselect, CFread, CFwrite) in software. I don't believe speed of CF access is an issue.
Bill

[barnacle]

That's a thought; perhaps I should slow down the edges! I'm using the ARM pio ports in push-pull mode, and they're reaching the rails speedily enough.

I have a Mesolithic board lying around which I can use to drive a cf card either directly, or via a (ahem) 6522 VIA, which might be the next port of call. Also, I have some 44 pin IDE to CF adaptor cards arriving in a few days.

Neil

[Dr Jefyll]

barnacle wrote:

That's a thought; perhaps I should slow down the edges!

Hmm. Slowing down the edges output by the ARM pio ports might reduce the symptoms somewhat, but (going in the other direction) you'll still be left with the fast edge rates output by the CF card. I like the series resistors plasmo mentioned, but before trying that useful suggestion I myself would begin by bolstering the Gnd/Vcc network.

Neil. you mentioned a ground plane, but -- because it's only a two-layer board -- I suspect your "plane" is what I'd call a pour or a fill. Electrons don't care what it's called, of course. Also, I'm sure the Gnd connections on the CF card do ultimately find their way to the Gnd connections on the headers going to the Neo (and likewise the Vcc pins do ultimately connect). But the route taken by the current flow is important, and a two-layer board can be unsatisfactory unless special attention is given.

As an experiment, if I were in your place I'd just add some wiring (as shown below) to provide additional -- and probably less circuitous -- paths for the current to follow. Also shown are a coupla bypass caps, because IMO that CF card needs to be treated like a big, noisy 74AC Series chip.

-- Jeff

[barnacle]

Floods, of course, not planes. But the ground is pretty low impedance and direct to both earths (though of course I have no control at the Nucleo side). I don't think the 3v3 is bad, but I wonder whether the 3v3 from the Nucleo can keep up with things; I'll hang a scope on that tomorrow. And the caps aren't a bad idea (though all I have are SM parts, oh well, that's what 26awg wire is for!)

Neil

(From the sublime to the ridiculous: today we started commissioning the electric launching winch we've been building: 15kWh of LiFePO4 cells, 500A fuses, 320A at 50v nominal peak to the motors! Spent a long time routing canbus controls well clear of 70sqmm power leads.)

[BigDumbDinosaur]

Dr Jefyll wrote:

Neil. you mentioned a ground plane, but -- because it's only a two-layer board -- I suspect your "plane" is what I'd call a pour or a fill.

A fill is worthless as a ground plane and may end up being a snake in the grass due to added extra parasitic capacitance.  No way I would have a fill in the vicinity of high-speed signal traces.

Quote:

...also shown are a coupla bypass caps, because IMO that CF card needs to be treated like a big, noisy 74AC Series chip.

That’s a good recommendation.

From a signal transition rate and noise perspective, the CF card looks a lot like a 74AC245 bus transceiver, producing transients that go well into the multiple-hundred MHz range.  On a two-layer board, the resulting electrical racket can be a real bear to tame.  The CF card needs short and direct power and ground connections, substantial bypassing, and signal trace lengths minimized as much as possible.  Given that it is possible for the card’s signals to change state en masse when driving the data bus, a high momentary current draw should be expected when /OE is asserted.  A low-ESR electrolytic in parallel with the bypass MLCC would be a good idea to smooth out local VCC excursions.

Incidentally, most SRAMs and ROMs exhibit similar behavior.

SRAM_board_design_guidelines.pdf

SRAM Design Guidance — Also applies to ROM, bus drivers, etc..

(822.24 KiB) Downloaded 37 times

[plasmo]

Two factors that makes troublesome CF interface: simultaneous switching of 8 or 16 data lines and fast FIFO-based read buffer. Simultaneous switching can generate ground glitches so high that CF read line sees double read pulses which causes the FIFO to clock out two set of data. FIFO is read-destruct so that causes missing data. To make it even harder to debug, the error is data dependent, so some sectors read OK, but others do not. Error is also make/model dependent; old Cisco disks are slow and insensitive while Transcend disks are particularly sensitive. Just the 100ohm/100pF RC filter at CF read strobe can solve errors with many brands of CF disk, serial termination of data lines can solve additional errors.
Bill

[barnacle]

Having added Jeff's suggested extra capacitance, no great change though it _may_ be slightly more reliable than it was; hard to say as it's certainly not 100% working. The 3v3 rail and the ground both show high frequency noise of about 100mV pk-pk, including what looks like a DC-DC converter switching; don't know where that's coming from but perhaps the USB expander power supply? The CF-USB adaptor may be negotiating a higher current availability; I don't expect the Nucleo to do so, but it measures only 50mA or so when idle.

Still no joy for the two cards that didn't previously work, but at least when the SanDisk works it is grabbing the whole of the first sector, matching byte-for-byte the same data extracted via (linux) dd and viewed with hexedit.

Got to go to the UK for a couple of days tomorrow to sort some stuff out, probably will have the IDE adaptors when I return to play with.

Neil

[barnacle]

Always the optimist, I've just sent this off to JLC...

6502_cf_2_a.pdf

(584.75 KiB) Downloaded 40 times

Let's see how it goes with a real data bus and address decoding. It runs at 1.8MHz, might run at 3.6 (I will have oscillators at both rates) but that's way over spec for the 68B50. We'll see. There's plenty of room for a few more chips if required.

Neil