Can you slow down EPROM access time? UPDATE: AT28C256 is worse!?

[Rat_Patrol]

I'm working on some old boards that need the memory chips replaced.

Originally, they had TMS27PC256 chips. https://pdf1.alldatasheet.com/datasheet-pdf/view/82578/TI/TMS27PC256.html I'm not sure which version chips these boards use, but the fastest option was 100ns according to the datasheet.

Since those are obviously obsolete, and I would like to use a modern equivalent not "NOS" from China, I basically only have the option of an Atmel AT27C256R

There are 45ns and 70ns versions of the ATMEL EPROMs.

I programmed up the 45ns version. It "works" but is unstable, causing the micro (AN80C196KB) to reset every few seconds. I programmed up some 70ns version and it is mostly stable, but not 100%.

I'm thinking the old Intel micro can't handle the modern higher speed chips. Is there a good option to slow down the access time for these chips to make them stable for the Intel micro? Or did I miss a critical spec in the datasheets causing an incompatibility?

Thoughts?

[CaptDon]

You can't really slow down the access time of the chip. The fast chips are probably causing ringing on an old buss structure. About the only thing you could try is to generate a brief HOLD perhaps by using a 200ns one-shot delay or inserting 1 wait state so the processor will wait on the buss reflections to stabilize before accepting the data as valid. We have a ton of obsolete 80C186 stuff around here. Maybe I have some old stock, I'll look. I have eproms all the way back to 1702's and 2708's around here. We used to make our own boards but went outside in the '90s. Probably 50% of all the old parts stock is still here but every time someone needs a place to store their junk more of these 'obsolete' parts find their way to the trash.

[SiliconWizard]

If ringing is your main concern, wouldn't adding resistors in series with the data signals do the trick?

[CaptDon]

I just checked, I have 3 pcs of Intel LD27C256-120 and about 100 American Microdevices AM27C512-120 I think the 512's could go into the 256 socket if you tie the extra address line lo?? I am not sure without spending some time looking if I have any junk boards I could rob 27C256's from. I personally use our 28C256 and 28C64 eeproms. I think they are real slow at around -200ns although I forget exactly. If you have any slow 28C256's you could try them although I think you may have to hard wire the write pin hi?

[Ian.M]

Subject to the CPU or MCU not using dynamic logic, you can slow the bus accessing ordinary EPROMs like the AT27C256R right down to DC though you may encounter data retention problems if you cycle it slower than 2 nHz at elevated temperature!    However that needs to be done by the processor - its *NOT* something that can be done at the EPROM socket

You need a comprehensive datasheet with bus timing diagrams for the AN80C196KB MCU.  Its likely that it samples the data bus after the instant /CE or /OE goes back high or one of the address lines changes, and the faster EPROM's data hold time is too short for the data to still be valid at the sampling point.   It could also be due to differences in output drive strength and/or logic levels.    Once you've established what's going on, *if* its a timing problem you *may* be able to patch in a monostable to stretch one of the control signals to hold the data for longer.  If however its an address line changing early, or signal level/strength incompatibilities that cant be alleviated by a simple pullup you are most likely S.O.L!

Adding series resistors to reduce ringing is a PITA, best done on a daughterboard if you aren't certain it will be effective.  Also your probing technique needs to be exemplary, especially minimal length grounding, and you probably need a high bandwidth active probe to be reasonably certain any ringing isn't an artifact of your probing technique, and that the probe isn't damping the glitch you are looking for.

[Rat_Patrol]

If ringing is your main concern, wouldn't adding resistors in series with the data signals do the trick?

I was hoping for something simple like this, but I've never ran into nor considered this issue before, so my knowledge is lacking in this case.

The board is simple enough to re-design to add resistors to the data lines (or just cut traces on a board for prototyping purposes), but I don't have access to the original source code to change anything there.

[Rat_Patrol]

I just checked, I have 3 pcs of Intel LD27C256-120 and about 100 American Microdevices AM27C512-120 I think the 512's could go into the 256 socket if you tie the extra address line lo?? I am not sure without spending some time looking if I have any junk boards I could rob 27C256's from. I personally use our 28C256 and 28C64 eeproms. I think they are real slow at around -200ns although I forget exactly. If you have any slow 28C256's you could try them although I think you may have to hard wire the write pin hi?

I was looking at the 28C256's, and the pinout is different. Since I can re-design a board, this could be an option. The 27C256's are EPROM, so there is no writing done on the PCB. I could butcher one in for prototyping reasons. I have 3 boards I can sacrifice to make this project work.

ETA: Looking at the pinouts again, the only difference is on the 27c chip, pin 2 is VPP (not used on the board, but tied to +5v) and pin 31 is A14. On the 28C chip, pin 2 is A14 and pin 31 is Write Enable (not needed here). One trace cut and jumper should work, at least for testing purposes perhaps?

Is it generally OK to use an EEPROM to replace an EPROM, using the same bin?

[Rat_Patrol]

The plot thickens...

I found an example that I have which is running ST M27C256B-70C1

https://media.digikey.com/pdf/Data%20Sheets/ST%20Microelectronics%20PDFS/M27C256B.pdf

70ns access time on this chip.

[james_s]

I would start by scoping the data lines to see what is actually going on. I have never encountered an issue where a memory chip was too fast, the access time is just the fastest you can expect the data to be ready, not the speed at which the device must be accessed. I suppose ringing is possible, the slower chips may have also had a much slower slew rate in the signals, but access time and the slew rate of the output devices are not necessarily tied.

You *do* have adequate power supply decoupling on the EPROM?

[Rat_Patrol]

I would start by scoping the data lines to see what is actually going on. I have never encountered an issue where a memory chip was too fast, the access time is just the fastest you can expect the data to be ready, not the speed at which the device must be accessed. I suppose ringing is possible, the slower chips may have also had a much slower slew rate in the signals, but access time and the slew rate of the output devices are not necessarily tied.

You *do* have adequate power supply decoupling on the EPROM?

Yes. The boards work fine, I'm refurbishing them. New caps, clean up, etc., and some have faulty EPROMs. I would like to replace all EPROMs as part of the standard work.

[srb1954]

I would start by scoping the data lines to see what is actually going on. I have never encountered an issue where a memory chip was too fast, the access time is just the fastest you can expect the data to be ready, not the speed at which the device must be accessed. I suppose ringing is possible, the slower chips may have also had a much slower slew rate in the signals, but access time and the slew rate of the output devices are not necessarily tied.

You *do* have adequate power supply decoupling on the EPROM?

Early in my career (43 years ago) the firm I was working for encountered an issue with memory chips that appeared to be too fast.

They had an in-house designed uC system that originally ran fine with 450ns access time RAM chips that were originally available. When the RAM manufacturer upgraded the access time to 250ns the uC started behaving unreliably with data being corrupted in multiple RAM addresses.

After a lot time running RAM test programs and a lot of head-scratching it was found that there were some glitches on some of the address lines due to noise coupling between address lines on the system back-plane. These glitches were ignored by the original slow RAMs but the newer RAM chips were fast enough to respond to these glitches modifying data in additional locations to the intended one.

I didn't work on the fix but I believe it involved a redesign of the CPU board to change the address bus drivers and add damping resistors to slow the edge rise times. A lot of extra decoupling was also added throughout.

[james_s]

Yes. The boards work fine, I'm refurbishing them. New caps, clean up, etc., and some have faulty EPROMs. I would like to replace all EPROMs as part of the standard work.

I strongly advise against the shotgun method of replacing parts that are not defective just as a matter of course. I have seen many times where somebody creates new problems where there were none to begin with. You might refresh the code in the EPROMs by reading and then re-writing without erasing first if they are getting up there in age, I have fixed devices that were starting to have problems by doing that but there is not really any reason to replace the chips unless you encounter a specific type with a high failure rate. Don't just blindly replace the caps either, maybe some electrolytics depending on the type and age, but make sure you use good quality and appropriately selected parts.

[dmendesf]

If you have a 50+MHz scope just probe the memory lines and compare rise times of old and new chips. Add series resistors as needed to make them similar. Use a short ground path for the ground (no alligator probe).

[Doctorandus_P]

You might refresh the code in the EPROMs by reading and then re-writing without erasing first if they are getting up there in age...

Indeed. Data retention is usually guaranteed for somewhere between 10 and 20 years. A data bit in an eprom is just a bunch of electrons stored in a capacitor. It's quite amazing those things work at all, and that those same electrons stay in their capacitor for 20 years.

[m k]

70ns access time on this chip.

Manual page 8 says that 27C256-10 output enable (_G) time is 55ns max and for 27C256-20 it's 75ns max.

Comparing A0 and _G(OE) should give a hint how late read is happening.
My guess is that the whole output enable cycle happens clearly inside of an address.

Keep in mind that the thing is most likely edge triggered.
Means that MCU ROM read is not happening again, after _G + MCU access time, before next _G.

Manual page 9, read cycle is misleading.
Check tv(A) data valid time from earlier page.

[Rat_Patrol]

70ns access time on this chip.

Manual page 8 says that 27C256-10 output enable (_G) time is 55ns max and for 27C256-20 it's 75ns max.

Comparing A0 and _G(OE) should give a hint how late read is happening.
My guess is that the whole output enable cycle happens clearly inside of an address.

Keep in mind that the thing is most likely edge triggered.
Means that MCU ROM read is not happening again, after _G + MCU access time, before next _G.

Manual page 9, read cycle is misleading.
Check tv(A) data valid time from earlier page.

Software and MCU to ROM interaction is not my strong suit, so if you have any advice as to the best course of action here, I'd be extremely appreciative!

[Rat_Patrol]

Just tried an AT28C256, and it is far worse. As soon as the board was powered up, it would just start rebooting constantly.

After about 10 seconds of this, it did stabilize long enough to run a task, and it did that....before it started rebooting right away.

So I would say it is certainly a chip incompatibility.

[james_s]

Have you looked at the bus with a scope yet or are we still just guessing? There is no substitute for measurement.

I would advise just finding some old stock EPROMs to replace any that are defective and going with that. Otherwise just refreshing the bits in the existing chips is likely to get you another 20 years out of most of them. They fade over time.

[m k]

So I would say it is certainly a chip incompatibility.

Do the measurings.

Is there a socket, is it good?

[Rat_Patrol]

So I would say it is certainly a chip incompatibility.

Do the measurings.

Is there a socket, is it good?

NO sockets, these are soldered directly to the board.

I'll get back to this project late this week, hopefully, then I'll probe some boards with the scope, see what it shows.

[james_s]

No socket? That's very unusual for EPROMs. Is there space to install a socket?

[Rat_Patrol]

No socket? That's very unusual for EPROMs. Is there space to install a socket?

Sort of. The caps are stupid close to the pads, it would be close.

[HB9EVI]

what clock speed is the system running at?

I'm using an AT28C256 on my Z80 board clocked at 6.144MHz - and that's working reliably

[james_s]

Sort of. The caps are stupid close to the pads, it would be close.

Try a machined pin socket, the plastic body on those is elevated slightly so there's a bit of clearance. I don't like to solder EPROMs, they have to be removed for programming and heat also reduces the data storage time.

[Rat_Patrol]

what clock speed is the system running at?

I'm using an AT28C256 on my Z80 board clocked at 6.144MHz - and that's working reliably

12MHz, regulated internally by the 80c196KB