Help needed with EPROMs on ATmega - Page 1
Forum section: electronics / general

author: woo
author_rank: Contributor
timestamp: May 31, 2015, 11:00:23 pm
content: Hi fellow tinkerers,has anyone here ever attached EPROMs (the old windowed ones) to AVR microcontrollers successfully before?I've hooked it up pretty straightforward, using various 27C512 EPROMs and an ATmega32, two 8bit ports for the address, one 8bit port for the data, and a simple ten-line C program to count up the address, read a byte and echo it in hex to the UART. However, all I get to read are repetitive bit patterns (FF 7F FF 7F.... FE 5E FE 5E...).If I read the EPROMs with my programmer, I get some real content, so the chips are OK.I've done the usual CMOS troubleshooting (trying AVR-internal as well as external pull-up and pull-down resistors instead of free-floating etc).If anyone knows about some quirkyness of those old devices that I may be overlooking here, please let me know.

author: Andy Watson
author_rank: Super Contributor
timestamp: May 31, 2015, 11:05:59 pm
content: Are you doing a full read cycle, or just incrementing the address of the eprom?

author: SuzyC
author_rank: Frequent Contributor
timestamp: May 31, 2015, 11:07:33 pm
content: Woo, are U supplying these with Vdd=5V address/control line levels that can work with 5V logic?Woo, 3V won't do.Do you have *CS I/O enable pins connected?Otherwise, you must make consideration for access times that can be slow as a 500nS, so you must wait this time for the output pins to have a valid byte.

author: woo
author_rank: Contributor
timestamp: June 01, 2015, 01:39:08 pm
content: I'm doing full read cycles (toggling the Chip Select / Output Enable pins before/after each address change).I'm also working the chip very slowly (reading a 16 byte block every second, with at least 100uS settling time after each pin change).(I've implemented the timing flow after the AMD datasheet for the AM27C256, but the problem is the same with chips from TI, AMD, Fairchild and others.)All the logic is at 5V TTL levels, supply is reasonably clean and stable.

author: niekvs
author_rank: Contributor
timestamp: June 01, 2015, 02:02:53 pm
content: Can you post some pictures of your setup, and some schematics? That way probably we can help you better. Maybe even some scope traces if you have any.

author: amyk
author_rank: Super Contributor
timestamp: June 01, 2015, 04:18:11 pm
content: Those EPROMs are asynchronous and have no minimum clocking requirements, so you could slow down the address counters to the point where you can see the bits change, and use a multimeter on the inputs and outputs to verify that.

author: miguelvp
author_rank: Super Contributor
timestamp: June 01, 2015, 11:52:51 pm
content: I know it's obvious but I'll say it just in case.You know Chip Select logic is inverted right? Meaning you have to drive it low to enable it.Edit: in other words CS is active low.

author: woo
author_rank: Contributor
timestamp: June 02, 2015, 09:34:57 am
content: I'm going to hook the setup up to my scope and LA this evening and provide pics.and I'm actually going through the code again.. miguelvp might be on to something there.. the datasheet I used for reference doesn't have the CE and OE designated as negated inputs / active low...

author: woo
author_rank: Contributor
timestamp: June 02, 2015, 07:08:10 pm
content: ok.. latest experimental version still on the breadboard has CS/OE permanently tied active and I'm just incrementing addresses, waiting 100ms before reading the output pins.

author: SL4P
author_rank: Super Contributor
timestamp: June 02, 2015, 09:14:30 pm
content: ....and?

author: Yansi
author_rank: Super Contributor
timestamp: June 02, 2015, 09:43:54 pm
content: Noo need to do full read cycle on theese eproms. Tie /CS and /OE to ground, set desired address and the output will poke data after somewhat 100ns (70-200, depending on a type of the memory).You probably have the memory miswired, have an error in the program or the memory is damaged.Some years ago, I have made some project for fun - I've programmed a PCM audio sample loop into a 64kB EPROM, added an address counter clocked by a 555 timer, put an R2R DAC on the output of the memory and a 386 audio amp. It plays an audio loop, again again and again, just for fun.

author: woo
author_rank: Contributor
timestamp: June 03, 2015, 10:56:03 am
content: http://paste.debian.net/hidden/7ae27aef/that's the latest sources. Perhaps there's something wrong I've been overlooking all the time.. but it's really a short program.I've verified the board again.. address bus is wired 1:1 to Port-A [0:7], data bus is wired 1:1 to Port-B [0:7], rest of address is tied to ground via 1kR (only reading first 256 bytes would be sufficient for a test),CS and OE are tied to ground via 1kR as well, and I've got 100ms delay between address setting and output reading.I've tried about a dozen EPROMs, some of which I've programmed myself, some others I know still contain some old 286 BIOS.. all read fine on the burner.Even if I messed up some of the bus wiring.. I should be getting something else than repetitive bit patterns..

author: amyk
author_rank: Super Contributor
timestamp: June 03, 2015, 02:26:13 pm
content: - Do you see the address lines getting set to the right value?- Do you see data coming from the EPROM?Like I said in the post above, slow it down enough that you can visually see the address incrementing and inspect manually both the address and data pins. That will narrow down the bug to either how you're manipulating the EPROM, or something else in the code.

author: Yansi
author_rank: Super Contributor
timestamp: June 03, 2015, 06:17:58 pm
content: NEVER use pulldowns on non-CMOS devices! Tie directly ground or use pullup. Just saying. Half problem solved with that.

author: BennVenn
author_rank: Regular Contributor
timestamp: June 03, 2015, 10:30:45 pm
content: A few ideas on what could be going wrong.Are you reading port data with PINx or PORTx instruction/Argument?Is anything else on the control lines to the EPROM - are you sharing them for TX,RX etc...Decrease the read cycle time down to a second or so and put a few LED's (with suitable resistors) on a few of the data, address and control lines. You'll quickly find what is going wrong. If your control lines are OK, the problem is almost certainly in your code/AVR