1 Introduction
2 ------------
3
4 The ArduinoAm29F010 project provides software and a circuit to program
5 Am29F010 flash memory devices using an Arduino board (tested with the Arduino
6 Duemilanove, but likely to work with the Arduino Uno and directly-related
7 boards). In addition, guidance about the use of such flash memory devices is
8 provided for use with microcomputer systems, such as the Acorn Electron and
9 BBC Microcomputer range.
10
11 The Am29F010-90PC product has been used to test the software and hardware
12 design described here. The PDIP variant of the device, as opposed to the
13 various other packages employed in the product range, is the variant most
14 suitable for use with the Arduino.
15
16 It is attractive to try and use such flash memory devices as an alternative to
17 EPROM devices, mostly for the practicality and increased convenience involved
18 in programming them, needing only a suitably-wired circuit and conventional
19 microcomputer/microcontroller voltage levels. It is also interesting to try
20 and make the extra space provided by such devices available to the systems in
21 which they will be deployed.
22
23 Contact, Copyright and Licence Information
24 ------------------------------------------
25
26 The author can be contacted at the following e-mail address:
27
28 paul@boddie.org.uk
29
30 Copyright and licence information can be found in the docs directory - see
31 docs/COPYING.txt and docs/gpl-3.0.txt for more information.
32
33
34
35 Using the Software
36 ==================
37
38 First of all, to use the Arduino-based programming solution, the Arduino needs
39 to have a program transferred to it. The program is compiled using the
40 Makefile provided, using the simple command...
41
42 make
43
44 To upload the program, the "upload" target is used as follows:
45
46 make upload
47
48 It is likely that this will fail unless appropriate permissions are available
49 on the device through which the Arduino is accessed on the host machine. Thus,
50 a privileged invocation is likely to be necessary:
51
52 sudo make upload
53
54 Testing the Program
55 -------------------
56
57 With the program uploaded, it should now be possible to communicate with the
58 Arduino. Unless the programming circuit has been constructed, however, there
59 will not be any effect of communicating with the Arduino, other than to check
60 that the program is operational. Running the upload.py script as follows will
61 permit such a test:
62
63 ./upload.py -i
64
65 Again, it is likely that this will need to be run in a privileged fashion as
66 follows:
67
68 sudo ./upload.py -i
69
70 The script should act as a terminal, showing a ">" prompt that can accept
71 various commands. Merely getting the prompt should be enough of an indication
72 that the program is functioning on the device.
73
74 Issuing read commands permits the testing of addresses in the device:
75
76 location sector
77 R00000 0x0000 0 (the first location in the device)
78 R07fff 0x7fff 1 (the final location in sector 1)
79 R10000 0x10000 4 (the first location in sector 4)
80 R1ffff 0x1ffff 7 (the final location in the device)
81
82 Uploading and Testing Images
83 ----------------------------
84
85 Once the programming circuit has been constructed (see "Arduino Interfacing"
86 below), the upload.py script can be used to upload data to the Am29F010
87 device. For example:
88
89 sudo ./upload.py jungle.rom
90
91 This will take jungle.rom and write it to the first sector of the Am29F010. To
92 verify the operation, the following command can be used:
93
94 sudo ./upload.py -v jungle.rom
95
96 To write to other sectors, an option can be specified. For example:
97
98 sudo ./upload.py -s 1 junglecode.rom
99
100 Again, the operation can be verified as follows:
101
102 sudo ./upload.py -s 1 -v junglecode.rom
103
104 Note that the -s option must appear first.
105
106 The upload.py script can accept multiple files and will write each of them to
107 consecutive sectors. However, it can be more prudent to write files
108 individually, especially if the circuit is behaving in a less than completely
109 reliable fashion.
110
111 A Note on Sectors
112 -----------------
113
114 Each sector is 16 kilobytes long, which corresponds to a 14-bit address range
115 (0x0000 to 0x3FFF). The Arduino interface described below supports 17-bit
116 addressing (A0...A16), permitting access to eight sectors (at 0x0000, 0x4000,
117 0x8000, 0xC000, 0x10000, 0x14000, 0x18000 and 0x1C000). The simple mapping from
118 a ROM cartridge to the device leaves A16 grounded and thus unable to access the
119 upper four sectors in the device. However, A16 could be connected to VCC to
120 access the upper four sectors.
121
122
123
124 Making a Printed Circuit Board
125 ==============================
126
127 The pcb directory contains resources for making a PCB with the Fritzing
128 software. In order to track changes in these resources, they have been
129 unpacked from a file saved by Fritzing, and so must be packed together into
130 such a file before being given to Fritzing. This can be done using a script
131 provided:
132
133 ./make_pcb.sh
134
135 This will produce a file called ArduinoAm29F010-arduinouno.fzz containing the
136 resources in a zip archive as Fritzing expects.
137
138 This PCB is featured as a project on the Fritzing Web site:
139
140 http://fritzing.org/projects/arduino-am29f010-programming-shield
141
142
143
144 Device Compatibility
145 ====================
146
147 For use with an Acorn Electron ROM cartridge or other board providing a ROM
148 socket, the compatibility of the Am29F010 needs to be assessed in the context
149 of the ROM sockets likely to be provided.
150
151 Original ROM Pinout Am29F010 Pinout
152 ------------------- ---------------
153
154 1 \/ 32 VCC
155 A16 2 31 WE#
156 1 \/ 28 VCC A15 3 30
157 A12 2 27 A14 A12 4 29 A14
158 A7 3 26 A13 A7 5 28 A13
159 A6 4 25 A8 A6 6 27 A8
160 A5 5 24 A9 A5 7 26 A9
161 A4 6 23 A11 A4 8 25 A11
162 A3 7 22 OE# A3 9 24 OE#
163 A2 8 21 A10 A2 10 23 A10
164 A1 9 20 CS# A1 11 22 CE#
165 A0 10 19 D7 A0 12 21 DQ7
166 D0 11 18 D6 DQ0 13 20 DQ6
167 D1 12 17 D5 DQ1 14 19 DQ5
168 D2 13 16 D4 DQ2 15 18 DQ4
169 GND 14 15 D3 GND/VSS 16 17 DQ3
170
171 Superimposing the Am29F010 onto a ROM socket would provide compatibility for
172 all pins from A12 to GND/VSS and from A14 to D3/DQ3.
173
174 Pin 1 in a ROM socket would correspond to A15 but is not necessarily
175 connected, nor, perhaps, is A14 since only 14 bits are required to address 16
176 kilobytes, although there may be 32 kilobyte sockets connecting A14 and using
177 15 bits to address 32K. A16 and A15 would probably be connected to ground to
178 ensure correct operation, but could also be wired to a selection mechanism so
179 that the entire contents of the flash memory might be exposed.
180
181 Pin 28 in a ROM socket would provide power, but the corresponding pin 30 on an
182 Am29F010 is not connected. Thus pin 30 would need routing to pin 32 for the
183 flash device socket.
184
185 Pin 31 for the Am29F010 would need to be asserted. Thus pin 30 might also be
186 routed to pin 31, so that the device would remain read-only at all times.
187
188 Dual ROM Adapter Usage
189 ======================
190
191 A single Am29F010 device could be wired to two ROM sockets in order to provide
192 data to both. The above wiring guide would be employed, with connections from
193 both sockets being connected to the Am29F010, but additional logic would be
194 required for the CS# signals originating from the sockets in order to expose
195 the appropriate region of flash memory. ROM #1 would be served by a "lower"
196 16K region; ROM #2 would be served by an "upper" 16K region; A14 would be used
197 to switch between these regions.
198
199 When ROM #1's CS# signal is low, an attempt to read from ROM #1 would be
200 occurring, and thus A14 would be held low. And when ROM #2's CS# signal is
201 low, an attempt to read from ROM #2 would be occurring, and thus A14 would be
202 held high.
203
204 Meanwhile, the CS# signal for the two ROM sockets would need to be combined to
205 produce a resultant CE# signal for the Am29F010.
206
207 ROM #1 CS# ROM #2 CS# Am29F010 A14 Am29F010 CE#
208 ---------- ---------- ------------ ------------
209 0 0 Not defined Not defined
210 0 1 0 0
211 1 0 1 0
212 1 1 Not defined 1
213
214 It might therefore be possible to connect A14 to ROM #1's CS# signal. And the
215 resultant CE# signal could be the product of an AND gate:
216
217 Am29F010 CE# = ROM #1 CS# AND ROM #2 CS#
218
219 Wiring Details
220 --------------
221
222 ROM #1 ROM #2 74HC08 Am29F010
223 ------ ------ ------ --------
224 CS# 1A A14
225 CS# 1B
226 1Y CE#
227 OE# OE#
228
229 ROM (Common) 74HC08 Am29F010
230 ------------ ------ --------
231 VCC VCC
232 GND GND
233 VCC VCC
234 VCC WE#
235 D0 DQ0
236 D1 DQ1
237 D2 DQ2
238 D3 DQ3
239 D4 DQ4
240 D5 DQ5
241 D6 DQ6
242 D7 DQ7
243 A0 A0
244 A1 A1
245 A2 A2
246 A3 A3
247 A4 A4
248 A5 A5
249 A6 A6
250 A7 A7
251 A8 A8
252 A9 A9
253 A10 A10
254 A11 A11
255 A12 A12
256 A13 A13
257 GND A15
258 GND A16
259 GND GND
260
261 Note that A15 and A16 are left grounded, effectively exposing only the first
262 two sectors of the device. By connecting either or both of these to VCC, other
263 pairs of sectors can be manually selected. A mechanism could also be devised
264 to allow selection using logic, but this is not explored here.
265
266
267
268 Arduino Interfacing
269 ===================
270
271 Arduino can employ at most 14 digital pins (plus 5 switchable analogue pins),
272 whereas the Am29F010B requires 17 address pins, 8 data pins, plus 3 control
273 pins to be utilised.
274
275 One solution is to map the 3 control pins directly to the Arduino, then to
276 channel address and data via 8 common pins to latches, and then employ two
277 remaining pins to control the latches. When neither latch is selected, the
278 data pins will be used to read or write data from the flash memory.
279
280 In this scheme, A16 must be directly controlled by an additional pin, separate
281 from the latch-based mechanism. As a result, only 14 pins are needed on the
282 Arduino.
283
284 74HC273 Pinout
285 --------------
286
287 MR# 1 \/ 20 VCC
288 Q0 2 19 Q7
289 D0 3 18 D7
290 D1 4 17 D6
291 Q1 5 16 Q6
292 Q2 6 15 Q5
293 D2 7 14 D5
294 D3 8 13 D4
295 Q3 9 12 Q4
296 GND 10 11 CP
297
298 Arduino 74HC273 #1 74HC273 #2 Am29F010
299 ------- ---------- ---------- --------
300 A5 CE#
301 A4 OE#
302 A3 WE#
303 2 CP
304 3 CP
305 4 D3 D3 DQ3
306 5 D2 D2 DQ2
307 6 D1 D1 DQ1
308 7 D0 D0 DQ0
309 8 D4 D4 DQ4
310 9 D5 D5 DQ5
311 10 D6 D6 DQ6
312 11 D7 D7 DQ7
313 Q0 A0
314 Q1 A1
315 Q2 A2
316 Q3 A3
317 Q4 A4
318 Q5 A5
319 Q6 A6
320 Q7 A7
321 Q0 A8
322 Q1 A9
323 Q2 A10
324 Q3 A11
325 Q4 A12
326 Q5 A13
327 Q6 A14
328 Q7 A15
329 A2 A16
330 5V MR# MR#
331 5V VCC VCC VCC
332 GND GND GND VSS
333
334 Set Address
335 -----------
336
337 74HC273 #1 CP = 1; 74HC273 #2 CP = 0
338 74HC273 #1 D[7...0] = A[7...0]
339 74HC273 #1 CP = 0; 74HC273 #2 CP = 1
340 74HC273 #2 D[7...0] = A[15...8]
341 Am29F010 A16 = A[16]
342
343 Write Data
344 ----------
345
346 Configure pins as D[7...0]
347 WE# = 0
348 74HC273 #1 CP = 0; 74HC273 #2 CP = 0
349 74HC273 #3 D[7...0] = D[7...0]
350 WE# = 1
351
352 Read Data
353 ---------
354
355 Configure pins as Q[7...0]
356 OE# = 0
357 74HC273 #1 CP = 1; 74HC273 #2 CP = 0
358 Q[7...0] = 74HC273 #0 Q[7...0]
359 OE# = 1
360
361 Pins
362 ====
363
364 A0-A16 17-bit addressing
365 DQ0-DQ7 8-bit data transfer
366 CE# chip enable
367 OE# output enable
368 WE# write enable
369 VCC 5V
370 VSS ground
371 NC (not connected)
372
373
374
375 Technical Notes
376 ===============
377
378 Information about the operation of the Am29F010 device can be gained from a
379 perusal of the datasheet, and a summary of some of the pertinent details can
380 be found below.
381
382 Low-Level Operations
383 --------------------
384
385 CE# high standby
386 CE# low read, write or output disable
387
388 OE# high, WE# high output disable
389 OE# low, WE# high read
390 OE# high, WE# low write
391
392 Thus, for reading and writing:
393
394 OE# = not WE#
395
396 Timing
397 ------
398
399 According to the datasheet, addresses are latched on the falling edge of the
400 latest of WE# and CE#, data is latched on the rising edge of the latest of WE#
401 and CE#.
402
403 Strategy:
404
405 1. Start with CE#, OE#, WE# high (standby, output disable)
406 2. Bring CE# low (output disable)
407 3. Set addresses
408 4. Bring WE# or OE# low for operation (write or read)
409 5. Read or write data
410 6. Bring WE# or OE# high (output disable)
411
412 Operation Modes
413 ---------------
414
415 By default, the device is in read mode, meaning that merely bringing OE# low
416 will produce data for the asserted address.
417
418 To issue commands to change the mode involves write operations with specific
419 address and data arguments.
420
421 Sectors
422 --------
423
424 A[16...14] selects each 16KB sector and is referred to as the sector address
425 or SA in the documentation.
426
427 Commands
428 --------
429
430 Reset (A=$5555; D=$AA); (A=$2AAA; D=$55); (A=$5555; D=$F0)
431
432 Autoselect (manufacturer) (A=$5555; D=$AA); (A=$2AAA; D=$55); (A=$5555; D=$90);
433 (A=$X00; read)
434 => D=$01
435
436 Autoselect (device) (A=$5555; D=$AA); (A=$2AAA; D=$55); (A=$5555; D=$90);
437 (A=$X01; read)
438 => D=$20
439
440 Simple reset (A=$XXXX; D=$F0)
441
442 Sector erase (A=$5555; D=$AA); (A=$2AAA; D=$55); (A=$5555; D=$80);
443 (A=$5555; D=$AA); (A=$2AAA; D=$55); (A=SA; D=$30)
444
445 Program (A=$5555; D=$AA); (A=$2AAA; D=$55); (A=$5555; D=$A0);
446 (A=PA; D=PD)
447
448 Note that A16 is held low when issuing the constant addresses in the above
449 commands.
450
451 Progress
452 --------
453
454 Programming and erasure commands employ data pins as follows:
455
456 Programming Erasure
457 DQ7 On completion: DQ7-out On completion: 1
458 DQ6 During: toggling value During: toggling value
459 DQ5 On failure: 1 On failure: 1
460 DQ3 Sector erase begun: 1
461
462 A read operation is required to obtain these outputs, typically with the same
463 address used to initiate each operation. The algorithm described in the
464 datasheet that tests DQ7 and DQ5 is employed to determine whether an operation
465 has completed. It should be noted that the toggling effect on DQ6 occurs from
466 read to read, not at some particular frequency.