Hello again everyone!

Attached is a picture of my home-brew EEPROM programmer. I had done one variation a couple of weeks ago, but I found that I need something automated in order to unlock it (speed requirements), and of course to program it at any reasonable speed once unlocked. This will eventually attach directly to a Raspberry Pi's GPIO pins, but I wanted the manual controls as an option.

It has a 28C256 in the top-left corner, 2x 74LS373 Octal Latches, 1x 74LS245 Trans Bus, some LED's, a DIP switch, and buttons. The buttons and switches are pulled up or down to whatever is needed. Anything going in or out of that EEPROM is running through a 74LS' chip, so I'm not (very) worried about frying my Pi.

And guess what. It works... sometimes. [ AH not that again! ] I checked, I didn't cross any wires, haha.

I've been looking at it, and checking different things. It seems that BOTH latches enable whenever I push one of the buttons. I put the scope to it, and I see that sometimes I get a different voltage level on the oppose latch's enable line. As in, when I push one button both activate for some reason. The scope shows interference sometimes, but others it's clean and smooth.

And when I mean "activate" it must be a fluke because when I push one button it goes from 0V to 5V, easy, but the other does not nearly reach 5V. Idk.

I did a lot of different things with capacitors and other kinds of switches, but it seems to always be this way. Both latches want to enable at once.

Obviously this is on a breadboard, and probably a cheap one. I suspect major ground bounce stuff.

What options do I have (with a breadboard) to stop ground bounce and inconsistency? You can reply, "Print a board" or "Solder a board" or something. I could do that, I got some perf board left over from the last project. But I want to explore breadboard options first. Ideas? Thoughts?

[ You can make jokes about crossing wires if you like, I deserve it from the last project. ]

Thank you all!

Chad

EDIT:

So I put in two tiny push buttons that can make one or the other latch's enable go to ground (disabling it). That has helped some. It is not perfect, but has worked more often.

It would be best if you posted a schematic along with your questions, because it's not clear what's attached to what from your description.

There's no reason why you shouldn't be able to get a circuit built with 74LS series logic to work on a breadboard.

Last time I checked, raspberry pi's have 3.3V I/O pins and I don't think they will take kindly to being driven with 5V signals.

What are those giant yellow things? They're connected where I'd expect decoupling capacitors, but they look more like MOVs to me.

I don't see any debouncing on the buttons, and I don't see anything to control the length of the programming pulses. The second might not be an issue, but the first probably will be.

(edit): it looks like you're pulling up the DIP switches through LEDs. That might cause problems too. There's a considerable voltage drop across the LED, so your 'high' signal will be a fair bit below 5V. Whether that's a problem depends on the thresholds of the chips taking it as an input.

Here's the schematic for mine. I think it has the corrections I made to the board. Either this, or something very similar to it, is working fine. Put the starting address in the address DIP switches, then press "Load". The data LEDs will show the current contents of that location. Put new data in the data DIP switches, then press "Write". That will program one byte. Then press "Inc" to move to the next location.

@kernelthread

Thank you for the reply, I did not create a schematic for it yet, but I will consider doing that soon.

Yes I have been considering the Pi's 3.3V. I haven't attached it yet. The idea was that the 28C256 will accept 3.3V TTL logic levels, but will output 5V. Because the data lines on the 28C256 are going through a 74LS245, which *will* accept the 5V and convert it to 3.3V, I was thinking that would make it safe for the Pi. Will test additionally before doing that of course.

@John West

Thank you for the schematic! I had been thinking of doing something like that for a while. I like the use of the counters.

Those giant yellow things are the decoupling capacitors, but apparently when I purchased them I didn't notice the size.

I am not debouncing the buttons, I am not controlling length of pulses. The debouncing part certainly would be an issue if I were using counters, but I'm just putting in DIP switch value directly into '373 latches and the '245 bus.

The LED's are directly on the data line and all that, but they are not on the enable lines at all. I was changing the pull-up and pull-down resistor values to make it work. 10k for the DIP switch was too much, so right now it's 3.3K seems to work for that. I think I will change the values of of the control line pull-up and pull-down resistors, and see if that helps.

Thank you both!

EDIT:

I adjusted the pull-down resistor values for the latch enables, and that also helps a lot. Using both the "ground the other guy" method, AND this new resistor value, it seems to work most of the time now, if not always.

Hm! I'll be thinking this over, why it's happening, etc. And next, to see if it's safe for the Pi! Thanks!

No pictures for now, but I got the Raspberry Pi hooked up to the breadboard. I ripped out all those buttons, switches, and pull/down resistors. The latches are great now.

Using python, I've been able to read and 'write' to the EEPROM. Yay, nothing has blown up!

But it's not actually writing because the software protection on it. I have tried that unlock sequence many times, and it's not working. It *is* still reading what is on there, exactly as it should, so I'm pretty sure my pins are not switched. As in, everything is working as expected except that it's not *actually* writing, just making blinky lights, etc.

Found this:

https://www.avrfreaks.net/forum/problem ... om-arduino

Very last post says Arduino can't do it for an Atmel. I have an Atmel. I also have a Pi, which might even be slower than an Arduino(?).

I can't find a straight answer on the internet or the datasheet, so I have a question going forward: If I use the chip erase feature, would that disable the software write protection? I have 12V somewhere, but trying to make that happen will not be an easy (or safe) task for me. Again this is the Atmel 28C256 EEPROM.

Thank you all for the help and advice.

Chad

Chad,
Sorry for causing you troubles by data protect the AT28C256. I have plenty of AT28C256 and the equivalent Xicor X28C256. I don't use them because they are the slow 250nS parts. I can un-protect them with my programmer and send them to you Monday. You can use more AT28C256 anyway. They will work in your 1MHz 6502 board and should work up to 2MHz. I'll send you 4, they are just here collecting dust anyway.
Bill

That's not what the last post says...

For clarity, then: a locked EEPROM needs to see the bytes of the unlock sequence in rapid succession. Using the high-level "DigitalWrite" functions in the Arduino library may be too slow for this, whereas using low-level direct port access can be fast enough.

See also

This doesn't sound quite right... I've about 30 AT28C256 EEPROMs... and none are locked by default! I also have code in my monitor program that can write to them insitu. I've also written a couple loadable utilities that will update the BIOS and the Monitor sections separately. I use the bit toggle mode for writing, which is outlined in the datasheet. Locking the EEPROM is an option also documented.

I did find out recently that the AT28BV256 (3.3V EEPROM) is locked by default and I had to make a minor modification to my write routine, which was trivial.

_________________
Regards, KM
https://github.com/floobydust

Part of the problem using the high overhead Arduino DigitalWrite() function with TommyProm and similar programmers that use a pair of serial-to-parallel shift registers is that it can take up to 56 port write operations (in the case of TommyProm) to load 16 address bits into the shift registers. Compare that to a pair of cascaded latches that only require 8 port write operations. Also, while it may seem more intuitive to use a pair of serial-to-parallel shift registers to "save pins" on the Arduino, a pair of cascaded latches actually use less pins because you can re-task the eight data pins and one of the control pins to load the address latches while the EEPROM is off (/CE = 1).

I'll go in reverse order!

Michael, yes indeed, "saving pins" is important, but directly tying them in is also important. My Raspberry Pi has 17 pins I can work with. My original design was to manually set the upper address byte, and have the program write to the lower address byte's worth, 8 data bits, and a single enable pin. I went with the latches and bus here because I was "saving pins". Yet, because I'm using these "high level" functions in Python, it'll probably not work regardless.

floobydust, you are exactly right. Factory out of the bag, I got it WITHOUT the write-protect. If it were off, I *know* this Pi will program the thing without any issues. I was able to program it with a couple of DIP switches and a push button a few weeks ago. But now with the write-protect on it, and in particular this Atmel brand, the Pi is having a hard time with the required timing.

BigEd, yes, it seems Python is not very good at this thing. I'm using code like:

GPIO.output(PinNumber, GPIO.HIGH)

That's about as low-level as Python will go. I am sure I can find some C++ way of doing this, but honestly time vs. effort is weighing heavily here. The chip is like $10, no more than $15, and comes with the write-protect disabled. Do I want to spend the next X hours finding a way that *might* make this Pi into a EEPROM unlocker, with possibility of failing? I don't know anymore.

Michael again, yes I abbreviated. The post says I'm using a 'super difficult' model, and I'm not even using an Ardunio here. The post was telling me (in my own language) that I'm basically SOL with the equipment I have, unless I want to spend much much more time figuring out what this Tommy guy had to figure out. That or I spend much much more money getting a proper programmer. Time verses money, that's what this is coming down to for me at the moment.

plasmo, I will not say no to that. Thank you. It is not required, but I will accept. See, this is just another problem I need to solve, and that builds character. It builds my library of things I know how to do! This experience pushed me into using the Pi at all, which was DEFINITELY a good thing. So, this experience was a good one, and I have learned a lot on this side of things. So, in the end, thank you for this.

I will try *one* more thing, I have another idea which will definitely end poorly but I can at least try it.

Thank you all.

Chad

EDIT: I tried a program of only a lot of GPIO.output(PinNumber, GPIO.X) and that did not work. I combined the even and odd addresses together so to use less pins yet also less things for the Pi to do. Nothing.

Hey, I forgot! So, my question last time was "does the chip erase function disable software protection"?

Has anyone ever done the EEPROM chip erase function, using the 12V or whatever from the datasheet (super unclear btw)?

From AN544 attached below;

"The software data protection is still enabled even after the software chip erase is performed."

First, bummer. Second, ah! It's a separate sheet. Hm, ok that's why I was confused about what the datasheet said. Ok, thank you Michael!

Chad

EDIT:

Wait wait wait. This is the software erase procedure. I was thinking of the 12V variety on the datasheet.

Ok I'll go look into this more. Maybe there's a separate sheet for THAT.

Thanks again.

I don't see anything about a hardware erase procedure. Let me look for a more recent datasheet.

Some of our members are familiar with Raspberry Pi and might be able to help. Can you share your schematic or wiring diagram and your Python script?