Basic EEPROM programmer

[floobydust]

Unless you locked it by sending the SDP enable sequence to it, it shouldn't be locked. In any case, you can unlock by sending the SDP disable sequence. Both are shown on Page 10 in the attached datasheet.

doc0006.pdf

(659.59 KiB) Downloaded 61 times

Also note that you can always write to the (protected) chip by sending the 3-byte enable SDP sequence first, then send the data to any address you want.

[sburrow]

This is the datasheet I've been using. In this one, they have "Chip Erase Waveforms", which indicates that /OE must be driven to 12V for some time while doing other things, and apparently things should be erased.

The datasheet is so vague about this that I don't know *what* they want me to do. But, I tried it anyways. I applied 12V to /OE, moved the /CS and /WE pins appropriately, etc, tried to write to it, and still nothing. Still software locked.

I'm giving up on unlocking it. Either I pay $50 for a programmer, or I buy a new one for $15 on Mouser. The Pi can definitely program an unlocked EEPROM, just like I could with DIP switches and push buttons.

Ok, thanks everyone, sorry for this ending as it did. Hopefully someone else can see this topic in the future and have some use for it.

Chad

[sburrow]

floobydust wrote:

Unless you locked it by sending the SDP enable sequence to it, it shouldn't be locked. In any case, you can unlock by sending the SDP disable sequence. Both are shown on Page 10 in the attached datasheet.

doc0006.pdf

Also note that you can always write to the (protected) chip by sending the 3-byte enable SDP sequence first, then send the data to any address you want.

It got locked when plasmo was helping me with the last project. I definitely thank him for the help he has done for me. I was just not expecting (or ready) for the EEPROM to be locked.

You know what, I'll try this single-byte write real quick. It's true I haven't been trying that, maybe it's not as picky about single bytes or something.

Thank you.

EDIT: Yeah, that didn't work either. It was worth a shot though!

I'm done here guys, I just don't have the equipment for this. Thanks though!

[floobydust]

You have options.... here's some simple code that will send the SDP sequence and allow a single byte to be written... in 65C02 assembler. You can pattern your own code after this. Note the EEPROM label is the physical address offset in the memory map. In other words... for my C02 Pocket SBC, the EEPROM address starts at $8000, so that needs to be added as an offset to the actual addresses used for the SDP sequence. Note that this code can NOT be run from the same EEPROM... so it's a segment of code that gets copied to Page Zero in my Monitor code and executed by a JSR after the Page Zero variables are setup for the Source and Target addresses.

Code: Select all

;Byte write code for EEPROM.
; Note: AT28BV256 requires an unlock sequence for all write operations.
;  This is different from earlier Atmel EEPROMs (i.e., AT28C256). The
;  sequence must be sent first to unlock the device, then data can be
;  sent for programming. Note that byte writes can be 1 to 64 bytes.
;  The EEPROM is defined in constants for the Offset of the EEPROM in
;  the hardware memory map.
;
BYTE_WRS        SEI                     ;Disable interrupts
;
                LDA     #$AA            ;Get code $AA
                STA     EEPROM+$5555    ;Send to EEPROM
                LDA     #$55            ;Get code $55
                STA     EEPROM+$2AAA    ;Send to EEPROM
                LDA     #$A0            ;Get code $A0
                STA     EEPROM+$5555    ;Send to EEPROM
;
                LDA     (SRCL)          ;Get source byte
                STA     (TGTL)          ;Write to target byte
                LDA     (TGTL)          ;Read target byte (EEPROM)
                AND     #%01000000      ;Mask off bit 6 - toggle bit
BYTE_WLP        STA     TEMP3           ;Store in Temp location
                LDA     (TGTL)          ;Read target byte again (EEPROM)
                AND     #%01000000      ;Mask off bit 6 - toggle bit
                CMP     TEMP3           ;Compare to last read (toggles if write mode)
                BNE     BYTE_WLP        ;Branch back if not done
                CLI                     ;Re-enable interrupts
BYTE_WRE        RTS                     ;Return to caller
;

Also note that once you send the SDP sequence, you can use Page Mode and send 64 bytes sequentially. Of course, refer to the datasheet on this. Also, you can easily modify the code aboe and send the SDP disable sequence to unlock the EEPROM.

[sburrow]

floobydust wrote:

You have options.... here's some simple code that will send the SDP sequence and allow a single byte to be written... in 65C02 assembler.

Thank you Kevin, I appreciate this. If I had a working 6502 computer I would DEFINITELY be doing this. This wouldn't even have been an issue from 4 days ago. Thing is, my computer needs a ROM to boot, and I can't get that at the moment.

If I got this ROM unlocked, and I wanted *another* ROM unlocked, then I could use 6502 to do it. Or if I my ROM was locked, but I was able to jump to RAM and do something on that, then this would work. I'm just stuck between a rock and a hard place here without any capability of utilizing the rest of my board.

Thank you again.

Chad

[floobydust]

Understood.... you're in a "catch-22". My personal view on this kinda stuff is having some minimal set of tools you can count on to ensure you can get certain functions done correctly. Programming a memory device is one of them. Even if you get an inexpensive one, you'll save yourself a ton of time and get to a working system much quicker.

Before I bought a programmer, I jury-rigged the AT28C256 to an expansion board I built for a Vic-20 over 30 years ago, It supported an 8KB memory chip, so I just had to tie the two additional address lines for which 8KB segment I wanted to write to... then used the code above with the Vic-20 (which has a Rockwell R65C02 in place of the NMOS 6502). It worked fine, but I eventually bought a decent programmer and never looked back.

[sburrow]

floobydust wrote:

My personal view on this kinda stuff is having some minimal set of tools you can count on to ensure you can get certain functions done correctly. Programming a memory device is one of them. Even if you get an inexpensive one, you'll save yourself a ton of time and get to a working system much quicker.

Indeed!

Because I'm still so new to all of this, every dollar I spend is a dollar I don't have for my wife, kids, food, bills, gas, etc. I'm much more a video game programming hobbyist, which basically takes $0, so this "spending money on my hobby" thing is foreign to me. Also, I have to get permission from my wife

That being said, you are exactly correct. If I am seeing myself continue down this road as the months progress, a EPROM programmer is one of those essential tools. I know that now.

Thanks again, I'll keep y'all updated on the printed board whenever that comes in and I have time to play with it, and on any additional significant things that might happen with my wired board.

Chad

[BigEd]

Just a couple of thoughts: this page reckons python can switch GPIO at 7us intervals, in the best case, on an original Pi 1. I haven't checked with the datasheet as to whether this ought to be fast enough, or not.

Also, as the unlock sequence involves writing particular bytes to particular addresses, any intended or inadvertent swapping of the data bits or address bits on the way to the chip may mean that the chip isn't seeing the intended sequence. Sometimes it's fine to swap bits of a bus for implementation reasons, and sometimes it will have consequences!

It might be that you already have the equipment to measure how fast you are able to send the unlock sequence. But even if you can't measure it electronically, you could perhaps measure it in python itself, by sending 1000 unlocks and timing the overall time, for example. Or 1000000.

[sburrow]

BigEd wrote:

Just a couple of thoughts: this page reckons python can switch GPIO at 7us intervals, in the best case, on an original Pi 1. I haven't checked with the datasheet as to whether this ought to be fast enough, or not.

Also, as the unlock sequence involves writing particular bytes to particular addresses, any intended or inadvertent swapping of the data bits or address bits on the way to the chip may mean that the chip isn't seeing the intended sequence. Sometimes it's fine to swap bits of a bus for implementation reasons, and sometimes it will have consequences!

It might be that you already have the equipment to measure how fast you are able to send the unlock sequence. But even if you can't measure it electronically, you could perhaps measure it in python itself, by sending 1000 unlocks and timing the overall time, for example. Or 1000000.

This is what I'm seeing for Python.

Python RPi.GPIO 70 kHz 243 kHz 2,5x

Am I reading something different? I do see the C library stuff is much faster. Hm... I might try this again if I have the time today. Thank you BigEd.

[BigEd]

Yep, so 70kHz as a waveform is 14uS period, which is 7us between transitions.

[sburrow]

BigEd wrote:

Yep, so 70kHz as a waveform is 14uS period, which is 7us between transitions.

I'm sure I have a fairly bloated "WriteByte" function, and I can probably whittle it down some if I wanted to, but I'm getting 0.006 seconds each, so about 166 Hz.

Again, even if I find a way to make it 100x faster, that's nowhere in the range of what they are saying.

If I get more time (between children and the like) I'll see about a straight "GPIO change this pin" speed test. I had tried using that method yesterday to unlock it, but that didn't work.

Does the Python IDE have anything to do with this? Or perhaps I could minimize some background programs while doing this? I'll look into that as well.

On the bright side, I just tested the breadboard with a 62256 SRAM chip, and it reads and writes beautifully! Working as expected, that's always a good thing.

Thank you BigEd.

Chad

EDIT: I disabled the GUI, went TTY, tried the same thing, got 450 Hz now. So that's great, but still nowhere near where I need it.

[drogon]

sburrow wrote:

BigEd wrote:

Just a couple of thoughts: this page reckons python can switch GPIO at 7us intervals, in the best case, on an original Pi 1. I haven't checked with the datasheet as to whether this ought to be fast enough, or not.

Also, as the unlock sequence involves writing particular bytes to particular addresses, any intended or inadvertent swapping of the data bits or address bits on the way to the chip may mean that the chip isn't seeing the intended sequence. Sometimes it's fine to swap bits of a bus for implementation reasons, and sometimes it will have consequences!

It might be that you already have the equipment to measure how fast you are able to send the unlock sequence. But even if you can't measure it electronically, you could perhaps measure it in python itself, by sending 1000 unlocks and timing the overall time, for example. Or 1000000.

This is what I'm seeing for Python.

Python RPi.GPIO 70 kHz 243 kHz 2,5x

Am I reading something different? I do see the C library stuff is much faster. Hm... I might try this again if I have the time today. Thank you BigEd.

I wrote the wiringPi C library for the Pi ... While now deprecated it's still there and very usable. It's capable of toggling a pin on a 1Ghz Pi at around 14Mhz, give or take jitter caused by Linux, DRAM refresh and Video refresh - which makes it very non-determanistic, however it's workable for this purpose. Using delayMicroseconds() the resolution is "fair" in the 1-100µS range as it's a polled loop based on a hardware timer, but over 100µS it's a kernel call. (Where the delay is "at least" what you want, but almost always a little more. wiringPi has support for up to 4 cascaded 8-bit shift registers but the delay per pulse is a few µS - most of them that I tested weren't that fast. Almsot faster to use something like the mcp23017 I2C devices or the 23S17 SPI devices.

You may also want to look at the PiGPIO library too. It has a 5µS timing resolution though but is much more deterministic but probably about the same for what you're wanting to do with it.

-Gordon

[plasmo]

Chad,
Have you thought of wiring even addresses and even data for "2AAA", "AA"; odd addresses and odd data for "5555", "55", and control it with few GPIO pins? Here is a quick sketch of the idea that allows you to generate 2AAA, 5555 for addresses and AA, 55, 80, 20 for data with 6 GPIO pins, plus 1 GPIO for WRITE control.
Bill

[sburrow]

Replying to two posts:

Bill, yes I tried that one time when I was trying all kinds of things. I did even's and odd's as 2 pins, and that would speed up the process a lot. It turns out it didn't speed it up enough, at least under the software configuration I was using with Python. Good idea though!

Gordon, did you know that you are famous? Seriously! I didn't read your post until just now, but I actually found your "wiringPi" library on my own in between posts. It's actually all over the internet!

And... it worked! Yes, I actually got it to unlock. WOW!

So: C++ and "wiringPi.h" library did the trick. Thank you Gordon for that, it was very helpful. I'm MUCH more comfortable in C++ anyways (C++ is my first language, English is my second, haha jk), so this ended up for the better anyways. Thank you again.

Continuing, in my glee, I said, "Well, the rest of my code should *obviously* work now!" And it didn't. But I did get some blinky lights and that's a start. That was about 3 hours of back and forth. That little EEPROM has seen better days at this point, darn pins have been bent so much I'm scared to pull it in and out anymore (but I still do anyways).

Thank you both very much, I appreciate all the help and I'll report back soon.

Chad

[BigEd]

Splendid news! (And thanks Gordon, for wiringPi)