PCMCIA socket for the nanoEngine board

Miguel Freitas
Updated Sep 30, 2002

First of all... Rant mode!

<rant>
nanoEngine is a very well designed StrongArm based board. It includes a 200MHz processor, 32MB SDRAM, 16MB Flash and an Intel 10/100Mbps ethernet chipset at an incredibly small size.
That board was created by a small company called BrightStar Engineering. Be aware they have limited resources and many people have trouble getting support from them.
My case is probably an extreme: I've e-mailed them several times, filled the web support form, sent faxes and got no response. Neither the "sales" nor "support" department gave me any information. I found that the only way you can ever expect to contact them is by calling Stuart Adams (BSE president) directly.
Even after pondering about the lack of resources to offer proper support, any technology company shouldn't, IMHO, completely ignore electronics communications. At least a standard message explaining the situation would be fine, it doesn't take more than 30 seconds to write a two-lines reply! I would really recommend using nanoEngine on your products, however you should seriously think about the support issue.
</rant>

What is this document about?

Although nanoEngine is such a good product it doesn't have an important feature for my project needs: data storage. Fortunately StrongArm processor gives to the experienced engineer most of the support for adding PCMCIA/Compact-Flash cards. This document is about how to do a simple (no buffers, no hot-swap, no 5v) socket for PCMCIA.

Problems

Anyone intending to implement such thing will get into trouble very soon. To start with, the provided nanoEngine development kit is a complete waste of time (and money). They ship an old Linux kernel with things they built (god only knows how) and no documentation at all.

The only thing that keeped me from going crazy was the amazing work from Larry Doolittle: at his site he maintains documentations and patches for building a system for nanoEngine using only the freely available software and utilities. Thanks Larry!

The engineer will then need technical documentation about PCMCIA standard and StrongArm processor. I greatly recommend buying the book "The PCMCIA Developer's Guide". I've made a local copy of StrongArm datasheet.

After patching Larry's kernel, filling the missing gaps like control pins assignment and designing a PCB board you will find out that it doesn't work. With your logic analyzer you will quickly find that somehow BrightStar engineer(s) seem to have forgotten to let addresses lines signals to pass through the nanoEngine CPLD when accessing PCMCIA cards.

If you reach this stage you would be stuck like me. Fortunately Larry sent me the email of a helpful guy called Russell Heibel (thanks Russ!), that had this same problem and after much investigation with BSE got an updated CPLD code to fix the nanobridge. It was surprise for him to find that BSE still ships the buggy nanoEngine cards.

Reprogramming nanoEngine's CPLD

nanoEngine features a Cypress CY37256VP256-100BBC for all the digital logic, our mission is to reprogram it. Assuming that you don't have access to the Cypress ISR you will need three things:

This pdf with the ISR parallel adapter schematics. (make sure to build the UltraISR cable)
ISR programming software from Cypress.
The updated CPLD code, downloadable from here (unless BSE lawyers decide that i'm infringing some copyrighted material by providing it).

You must do the cable to match nanoEngine evaluation board JTAG connector (it doesn't look standard, although i'm no JTAG specialist). This is how you should connect the signals:

UltraISR	nanoevb J5
TCK	TCK (1)
TMS	TMS (3)
TDI	TDI (9)
TDO	TDO (3)
JTAGen	TRST (7)
VCC	(4)
GND	(2,10)

Then follow Cypress documentation for using the JEDEC file and everything should be fine.

PCMCIA socket wiring

PCMCIA signals are connected to the StrongArm in an almost straightforward way. In my application i did not need the PCMCIA fancy features (like dual power voltage and hot insertion capability) therefore i haven't implemented them. Please notice that because of that i can't claim my socket to be PCMCIA compliant, it just works. Also i'm not responsible if you fry your hardware by not using the appropriated buffers the spec demands.

StrongArm manual doesn't specify where you should connect CD1/CD2, RESET and READY lines. I arranged those as following general purpose processor pins:

PCMCIA signals	GPIO lines	direction to cpu
Socket 0: READY	GPIO11	input
Socket 0: CD1/CD2	GPIO13	input
Socket 0: RESET	GPIO15	output
Socket 1: READY	GPIO12	input
Socket 1: CD1/CD2	GPIO14	input
Socket 1: RESET	GPIO16	output

Now here is the complete PCMCIA wiring for the Socket 0. I don't use any external logic, so this is about the simpler interface you can make. In fact, it should be possible to use even less connections by shortening to ground some of the higher addresses lines (thus reducing the usable PCMCIA window). CompactFlash should differ only on pin numbers.

PCMCIA pin	PCMCIA signal	nanoEngine signal	pull-up resistor
1	Ground	GND
2	Data 3	AD3
3	Data 4	AD4
4	Data 5	AD5
5	Data 6	AD6
6	Data 7	AD7
7	CE1#	nPCE1
8	Address 10	AD18
9	OE#	nPOE
10	Address 11	AD19
11	Address 9	AD17
12	Address 8	AD16
13	Address 13	AD21
14	Address 14	AD22
15	WE#	nPWE
16	READY/IREQ#	GPIO11	47k
17	Vcc	VCC
18	Vpp1
19	Address 16	AD24
20	Address 15	AD23
21	Address 12	AD20
22	Address 7	A7
23	Address 6	A6
24	Address 5	A5
25	Address 4	A4
26	Address 3	A3
27	Address 2	A2
28	Address 1	A1
29	Address 0	A0
30	Data 0	AD0
31	Data 1	AD1
32	Data 2	AD2
33	WP/IOIS16	nPIOIS16
34	Ground	GND
35	Ground	GND
36	CD1#	GPIO13	47k
37	Data 11	AD11
38	Data 12	AD12
39	Data 13	AD13
40	Data 14	AD14
41	Data 15	AD15
42	CE2#	nPCE2
43	VS1#
44	IORD#	nPIOR
45	IOWR#	nPIOW
46	Address 17	AD25
47	Address 18	AD26
48	Address 19	AD27
49	Address 20	AD28
50	Address 21	AD29
51	Vcc	VCC
52	Vpp2
53	Address 22	AD30
54	Address 23	AD31
55	Address 24	GND
56	Address 25	GND
57	VS2#
58	RESET	GPIO15
59	WAIT#	nPWAIT	47k
60	INPACK#
61	REG#	nPREG
62	BVD2
63	BVD1
64	Data 8	AD8
65	Data 9	AD9
66	Data 10	AD10
67	CD2#
68	Ground	GND

Kernel support

While debugging PCMCIA and IDE subsystem on kernel i realized it is very well designed. Almost all stuff needed to support PCMCIA/CompactFlash interface is already there, one just need to provide very small hardware dependent functions.

The patch below is partially inspired on sources from BrightStar SDK and other SA1110 drivers. It has not yet being ported to the latest kernel of Larry's site, but that must only require simple changes.

PCMCIA patch against linux-2.4.9-ac10-rmk2-np1-lrd1

linux-2.4.9-ac10-rmk2-np1-lrd1 patch

Testing

This is all you should need for bringing your PCMCIA card alive. After that, i would recommend compiling some pcmcia-cs utilities like "dump_cis" in order to check your adapter (for your convenience here you can grab it statically linked). The PCMCIA kernel code is also full of places were you can printk useful information to debug problems (like bytes read from CIS space).

When designing your application remember that, unlike in PC architecture, you don't have to set any PCMCIA resources. Trying to do so may cause errors to the pcmcia-cs userspace tools.

Have fun! ;)

please send your spam to this email