Simple parallel EEPROM programmer

[Xenophotean]

View attachment 11598Hello,

I have been recently working on a simple EEPROM programmer using only 74XX series logic. I am currently using Logicworks to simulate my design. Click on logic works to download the tool, which is very useful for designing with logic chips, my design is attached to this post.

A bit of reference. Most parallel EEPROMs contain three control signals; write enable, chip enable, and output enable. (Active Low) So for a basic write procedure you would want the chip enabled (Low), the output disabled (High), and to start the Write disabled (High). You would then put the address you would like to program your data into on the address bus pins, and the data you want to program on the data bus pins. If you then transition Write from disabled (High) to enabled (Low) you would program that data on the data bus into the address on the address bus. Seems easy enough.

It got me to thinking, could I use shift registers and counters to do this automatically? By the miracle of logic works I think I have. The flow of steps is simple.

1.) Shift data into a 8-bit serial to parallel register one bit at a time (8 clock cycles)
2.) On the 9th clock cycle toggle write enable (one clock cycle)
3.) On the 10th clock cycle count up the address and clear the serial to parallel register (one clock cycle)
4.) Go to step one and repeat until you have programmed every adress up to the highest address.

Schematic PDF

To explain this in terms of my schematic. The lower 74LS595 accepts a toggle button (for now) which simulates data in. Each time the clock source pulses is shifts in a bit of data into the 74LS595 register. The 74LS590 8-bit counter directly above the 74LS595 then counts up. When it 74LS590 reaches the 9th count and all 8-bits of data have been shifted in, it triggers a NAND gate whose output will be connected to the write enable pin on the EEPROM. One the 10th cycle another NAND gate triggers the clear pin on the 74LS595 and the clock pins on the upper two cascaded 74LS590s which are keeping track of the 16-bit address. Then the cycle continues until you reach the upper address which toggles the output enable pins to shut down for the whole design.

This current design focuses around programming a 32KB x 8-bit CAT28C256, but the design could be expanded for any size EEPROM with any word length given the EEPROM has active low control signals, which most EEPROMs have.

My problem is developing input from a computer. I have considered using an RS232 to TTL adapter, but I am not use how I would implement the clocking.

I am looking for a simple solution to send a data and clock line directly from my computer without using a micro-controller. If anyone has any suggestions I would greatly appreciate it. Thanks

 

[KrisBlueNZ]

That's an interesting design. Thanks for the circuit description!

A small point relating to your description of programming parallel EEPROMs: it's not necessary to drive -CS low before presenting the address and data; you just need to have it low in conjunction with -WE being low, to program a byte. In fact the data sheet for the CAT28C256 says that you could even tie -WE low and use -CS to initiate a byte program operation.

First some comments on your schematic.

Your schematic shows a whole lot of rectangles connected to the outputs of the ICs. This isn't a symbol I've ever seen before. I guess they are Logicworks' way to indicate signal states? Most of them need to be connected to the socket for the device being programmed (But not the outputs of the control counter.) If you can't show them connecting to the actual programming socket, you should at least identify them with signal names (e.g. EE_A0, EE_A1 etc) and perhaps socket pin numbers. Also your OEN and CEN labels don't seem to be attached to the relevant gate outputs; they're just nearby.

It would also help if you assigned references to the ICs, so we don't have to identify them as "control counter", "address counters" etc!

Another small point: I don't think there's any need for the HC595's -SRCLR input to be connected to the main clear signal. You're clocking data through the shift register constantly anyway. I would tie it high to show that it's not relevant.

OK. My first concern about the design is the issue of race conditions between the control clocks and the output latch clocks in the 74HC595 and the 74HC590s. Generally when you have a clocked register feeding a clocked latch, if you clock them both at the same time, the outputs of the latch will be one clock cycle behind the register, because on the active-going clock edge, the register will take a short time before its outputs change, due to propagation delays within the register, and the latch will load the states that were present at the register's outputs just before the active clock edge, due to setup time requirements.

In other words, clocking the register and the latch from the same clock source (assuming they both clock on the same edge) normally introduces a one-clock-cycle delay.

I've used the HC595 before and I'm pretty sure that's how it will behave. I had never heard of the HC590 so I've looked at TI's data sheet, and it explicitly states that "f both clocks are connected together, the counter state always is one count ahead of the [latch] register."

This isn't necessarily a problem; it's just something you have to bear in mind, in relation to all three circuit positions (control counter, address counters, and data register) to ensure that the right data is in the right place at the right time.

I would draw up a timing diagram, like the ones shown in the data sheets, to show exactly which signals will change when, so you can be confident that you've got the timings right and you're using the right outputs of your control counter for the gate logic.

Next, I would be worried about the potential for a missed or bogus clock pulse to disrupt the whole thing. There's no feedback so your control program can check that the control counter is in sync, and no way for the control program to reset it. One missed clock and everything goes crazy. You'll be programming wrong data at the wrong addresses!

You would also need some way to implement the 5 ms delay for the byte programming time.

As for controlling the circuit using a serial port, you can send a byte for each clock pulse, and set the data from the content of the byte. A 0x00 byte will clock a 0, and a 0xFF byte will clock a 1. This isn't hard to do.

Receive your RS-232 signal with a standard receiver such as a MAX232, etc. This gives you a signal that is normally high. At the start of each byte sent from the computer, it goes low (the start bit), then follows the eight data bits, then goes high (stop bit).

Use an edge-triggered monostable that's triggered from the falling edge of that signal, and has a period of about half a byte, i.e. around 5 bit times. It will time out in the centre of the byte, approximately. This timeout becomes your rising clock edge, and the RS-232 receiver's output is the data signal.

If you transmit a 0x00 byte, the falling edge of the start bit triggers the monostable, and half way through the byte, the monostable times out, the clock signal goes high, and one of the middle bits of the byte (they are all zeros) is clocked.

If you transmit a 0xFF byte, the data that's clocked when the monostable times out will be one of the 1-bits from the middle of the byte.

 

[Xenophotean]

Thanks for the response!

I had never looked into the chip enable versus write enable specifically for the CAT28C256, not sure if that statement blankets all EEPROMs for using WE or CE for a programming toggle, my guess is that it is different from chip to chip, but for the most part you are right.

I actually am building a Z80 computer, and needed to program an EEPROM. I have a 'G540' programmer, but the thing is a piece of garbage. I wanted a way to build an EEPROM programmer, but still stay true to 'Z' 80's. I spent about an hour developing this system, and I thought I would post it on here to see if someone knows of a piece of hardware that already exists like this. I also was in need of help developing it further by finding the holes. (Thanks for finding some of the pitfalls)

z80project.wordpress.com

I really had no end goal in mind for this small side project, but now I think I would like to build it up a bit.

I currently have no 74LS590's or 74LS595's. (darn Jameco and their 74LSXX kit)

I think in the end what I envision is polishing the design a bit, and breadboarding it. The design seems a bit rigid to go all out and make a PCB and all of that.

Now as for logic works, I was using this program to show the simulation. I plan on moving to Eagle once I have a bit more concrete evidence that this design will pan out. If you know of any other simple simulators I would be open to trying them out.

Logicsworks' output is crude at times. Those blocks are their "LEDs" which I just found visually more appealing than a logic probe box with a one or zero within, which was my other option to show output.

There are many race conditions within this design that I will have to cope with when realizing the hardware. I had know about the clocking issue, but a bigger issue is when all the data has been clocked in and you take one more step to do a Write Enable. In the current design that next clock pulse would load more data in, which is a no-no. Then the cycle after to you will load more data in when all you want to do is increase the address.

I forgot about start and stop bits.

Why don't I just use the start and stop bits to trigger the mono-stable for eight cycles? Why would I want timeout in the middle of the byte sent. If this was the case then these steps I see so far are,

1.) Start bit - enable clock
2.) Clock/shift in 8 bits
3.) Stop bit - disable clock / Write Enable / Count up address

This may end up changing the design a bit if I could implement it this way. What are your thoughts?

 

[KrisBlueNZ]

I had never looked into the chip enable versus write enable specifically for the CAT28C256, not sure if that statement blankets all EEPROMs for using WE or CE for a programming toggle, my guess is that it is different from chip to chip, but for the most part you are right.

Sort of. No device will have a problem with leaving -CE active while the data and address are being set up, as long as -WE is high. Whether you need to control -CE at all may depend on how (or if) you want to detect completion of the write cycle using data polling. (Not sure if that device supports that feature.)

I currently have no 74LS590's or 74LS595's. (darn Jameco and their 74LSXX kit)

I would go for 74HC instead of 74LS. Digikey had 74HC590s listed but I didn't check whether they were ex stock. 74HC595 is readily available.

Logicsworks' output is crude at times. Those blocks are their "LEDs" which I just found visually more appealing than a logic probe box with a one or zero within, which was my other option to show output.

I was going to say, I love the look of the schematic. Whatever Logicworks' limitations may be, it sure makes a tidy-looking diagram.

There are many race conditions within this design that I will have to cope with when realizing the hardware. I had know about the clocking issue, but a bigger issue is when all the data has been clocked in and you take one more step to do a Write Enable. In the current design that next clock pulse would load more data in, which is a no-no. Then the cycle after to you will load more data in when all you want to do is increase the address.

Right. Perhaps you could use one of the outputs from the control counter to drive the clock disable input of the 595. But the whole approach looks more and more like an accident waiting to happen. Multiple derived logic signals that all need to be in the right state, and no way to detect whether they are or not, or to reset anything, and hundreds of thousands of clocks for a full program of the device... It might work in simulation but in reality it's like a house of cards.

Why don't I just use the start and stop bits to trigger the mono-stable for eight cycles? Why would I want timeout in the middle of the byte sent. If this was the case then these steps I see so far are,
1.) Start bit - enable clock
2.) Clock/shift in 8 bits
3.) Stop bit - disable clock / Write Enable / Count up address

My suggestion would clock one bit into the circuit for every byte you send. If you have ten or eleven bits (whatever it is) per byte programmed, you can't clock eight bits at a time. If you change the design so the byte is programmed automatically after the eight bits have been transferred, or during a second dummy byte, then that approach might be workable. You would either need eight cascaded monostables (a bit silly) or some sort of synchronisable clock oscillator with a counter. I prefer one byte transmitted == one bit received, but I'm sure you could make it work with one byte transmitted == one byte received.

 

[Xenophotean]

The more I look at it. The more it seems like a train wreck with the amount riding on exact timing.

I would go for 74HC instead of 74LS. Digikey had 74HC590s listed but I didn't check whether they were ex stock. 74HC595 is readily available.

The 74HC series is not compatible with the 74LS series correct? I would need to get the 74HCT if anything.

My suggestion would clock one bit into the circuit for every byte you send. If you have ten or eleven bits (whatever it is) per byte programmed, you can't clock eight bits at a time. If you change the design so the byte is programmed automatically after the eight bits have been transferred, or during a second dummy byte, then that approach might be workable. You would either need eight cascaded monostables (a bit silly) or some sort of synchronisable clock oscillator with a counter. I prefer one byte transmitted == one bit received, but I'm sure you could make it work with one byte transmitted == one byte received.

If I understand you correctly the hardware flow changes to:
1.) Start bit - transition clock
2.) Clock/shift in 1 bit
3.) Stop bit - transition clock
4.) Repeat steps 1-3 eight times.
5.) Shoot Write Enable to program the byte at the current address
6.) Increase Address Counter

There is a clock disable input on a 595? Maybe you are thinking of output enable, which is what I thought of, but if you disable the output then the EEPROM will not be able to see the byte you want to program.

I will more clearly define this systems inputs and outputs using a CAT28C256 and a MAX232 with a DB-9 connector. The meat of the logic I am still going to test in Logicworks, unless you have an alternative. Thanks.

 

[KrisBlueNZ]

The more I look at it. The more it seems like a train wreck with the amount riding on exact timing.

Yeah, I think the whole idea is too fragile for practical use.

The 74HC series is not compatible with the 74LS series correct? I would need to get the 74HCT if anything.

As I expected, 74HCT590 is not listed on Digikey. So you would have to use 74HC and put pullup resistors on the outputs of any 74LS devices that were driving the circuit, or use a 74HCT device as a level translator (74HCT outputs are compatible with 74HC, AFAIK).

If I understand you correctly the hardware flow changes to:
1.) Start bit - transition clock
2.) Clock/shift in 1 bit
3.) Stop bit - transition clock
4.) Repeat steps 1-3 eight times.
5.) Shoot Write Enable to program the byte at the current address
6.) Increase Address Counter

I don't really understand what you're asking here. If you're asking about my suggestion of one bit received per byte transmitted, go back and read my description carefully a few times. I think I explained it fairly clearly.

There is a clock disable input on a 595? Maybe you are thinking of output enable, which is what I thought of, but if you disable the output then the EEPROM will not be able to see the byte you want to program.

No, I meant clock disable. If it doesn't have a pin for that, you can add an external gate.

Iwill more clearly define this systems inputs and outputs using a CAT28C256 and a MAX232 with a DB-9 connector. The meat of the logic I am still going to test in Logicworks, unless you have an alternative. Thanks.

What are your project parameters? You know you can get PICs, AVRs, etc with USB endpoints built-in? You would need to write the software at the computer end too, but you would be able to implement lots of nice features - read, verify, etc, and with guaranteed reliability.

 

[Xenophotean]

Ehh. Not really worth the effort. The reliability will just never be there with such a simple system, and the more logic you add the more convoluted the system becomes and the more propagation delay.

Just going to stick it out with the G540 EEPROM programmer. Maybe a little more reliable. (but not by much)

 

[KrisBlueNZ]

Good call