Can't unlock AT28C256

[Lx32]

I can't unlock my AT28C256 with TommyPROM. I'm using two arduino one, one for the real code and one emulating the two shift register, but thare aren't any problem in reading the eeprom. If I use the unlock command and after the zap command it prompt me a writing error.

[TomNisbet]

I've never tried anything like that. The unlock code can be very picky about the timing and some manufacturers chips are more sensitive to this than others. Make sure that your two arduino solution is still writing the bytes within the specified time windows. Th README-28C file has more details.

Also, be sure to double check your bus wiring to make sure you don't have any pins swapped or shorted so that you are certain that the correct unlock sequence is being written. Maybe verify this be removing the 28c256 and adding delays to observe the write sequence with LEDs. Or, if you have any existing ROM chips laying around, you can read them to see if the data looks reasonable.

[Lx32]

I tried using the hardware HardwareVerify and there is something odd in addressing (the second arduino), so I think that will be better if I wait the shift register. Thanks so much for the help.

[Lx32]

Today are arrived the shift register, but I've the same problem. I've already checked twice the connection and rodone the entire schema but the unlock doesn't work

[TomNisbet]

@Lx32 - If you send more information I may be able to help you track it down.

• Which shift register chips are you using? My schematic uses 74LS164, but others have also successfully used 74LS595 with some modifications.

• Which EEPROM are you using - part number and manufacturer.

• What is the output of a "D0 F" command after a Zap command?
  A copy of a session with the following commands would help: D0 F U Z D0 F

Also, make sure you have compiled the code for the correct chip family in configure.h. It will print as part if the menu header, like "TommyPROM 2.0 - 28C series EEPROM".

You may also want to try the hardwareverify sketch without an EEPROM installed to check the data and address lines with a multimeter or scope or even an LED or two. Make sure that the address and data lines are in the correct order and that there aren't any shorted together. If there is a problem with the address or data then the unlock sequence won't be correct.

Also, watch your wiring lengths. My first build used a ribbon cable for the data bus and it was very flakey. I changed it to use the shorter wiring in the photos and it worked better. This was still during development, so it may be unrelated, but better safe than sorry.

A few people have been using this design and we've always managed to get it working. I'm sure we'll figure yours out too.

Tom

[Lx32]

• The shift register are SN74LS764N

• The EEPROM is a Atmel AT28C256-15PI, but i bought from a chinese store on Ebay so I don't know if is genuine

• D0 f -> ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff U -> Writing the unlock code to disable Software Write Protect mode Z ->ERROR: Write failed D0 f -> ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

The header is TommyPROM 2.0 - 28C series EEPROM so it's the right version I think

Thank you for the support -Luca

[TomNisbet]

@Lx32 - Atmel chips should definitely work, I use those all the time with no problems. I suspect that your chip is locked and that the unlock code isn't getting through correctly. Otherwise I'd expect to see that the zap command would change something, even if there were some address or data lines switched around.

This makes me suspect either a wiring or timing error. If you have added any additional delays that are not in my code then take them back out. The unlock command can be very sensitive to timing.

If you are running the stock code, then the timing shouldn't be an issue.

Use the Hardware Verify sketch to scope out the connections. Without the chip installed, use the A command with a meter, scope, or even some LEDs to verify that each bit in the address can be set and that no other bits are set at the same time.
Measure at the EEPROM location, not at the arduino.

So do: A0 - [no bits set] A1 - [A0 bit set, no others set] A2 - [A1 bit set, no others] A4 - [A2 bit set, not others] A8 - [A3 bit set, no others] A10 - [A4 only] A20 - [A5 only] A40 - [A6 only] A80 - [A7 only] A100 - [A8 only] and so on up to A4000 to verify the A15 bit.

Then do the same with the D0,D1,..D80 commands to verify the D0 to D7 pins at the EEPROM.

Finally, use the W, O, and C commands to verify the Write, Output, and Chip enable signals.

Put some 0.1 or 0.01uF caps on the power rail near the chips. I didn't draw it in the schematic, but you can see them in the picture.

If the individual connections are good, the sketch has been tested by many people, so it should be able to work. Bad wiring or a cheap breadboard with flakey connections may be a culprit, but that's not something I can debug from here.

I'm assuming that you are running the same 74LS164 that I am using, not a 74LS764,

If you post pictures of your build somewhere and post the link here, I'm happy to take a look to see if anything looks odd.

Good luck! Tom

[Lx32]

I don't know why but if I use an A command, like A0, it will pul up all the A line. Same with D

[Lx32]

I've just redone the test, putting any A command will pull up all the address line

[TomNisbet]

First off, someone just pointed out to me the schematic on github doesn't show the power and ground connections on the shift registers. Have you got +5 connected to pin 14 and GND to 7? That would definitely cause problems if it were missing.

Otherwise: The A command is clocking bits into the shift register from the arduino. If you see nothing but HIGH on all of the shift register outputs then that suggests that either the clock or the data pins aren't connected correctly. Check that pin 1 of both shift registers is connected to A5 on the arduino and that pin 8 of one shift register is connected to A3 and pin 8 of the other to A4. For your debugging, concentrate on the chip that is connected to A4 because it is the lower bits of the address and those will change with every A command.

You could add an LEDs and resistors to the A4 and A5 lines to see the pulses if you slow down the clocking to the shift registers. Change the code at the bottom of PromAddressDriver.cpp from this:

        // Toggle the clock high then low
        PORTC |= mask;
        delayMicroseconds(3);
        PORTC &= ~mask;
        addr <<= 1;

to something with a longer delay, like this:

        // Toggle the clock high then low
        PORTC |= mask;
        delay(100);
        PORTC &= ~mask;
        delay(100);
        addr <<= 1;

Other than that, the offer still stands to look at your wiring. Post a few pictures somewhere and put the link here so I can see them.

Good luck!

[Lx32]

Here are the photo of my wiring https://ibb.co/SXZkNW2 https://ibb.co/KNFJLPM https://ibb.co/kQ9659Y https://ibb.co/FDpTj5H https://ibb.co/nD0fhnk

I've rechecked all the wiring but i didn't see any changes. Thanks for your time.

[Lx32]

Any news?

[aemiller51]

Hi Lx32 I can see that you are using the following colour coding Yellow - chip control (A2,A3, a4) green/brown - address lines blue/purple - data lines red - +5v black - Gnd

it's pretty hard to check things out as they are covering the breadboard. Any chance you can tidy them up a bit and post another pic?

[TomNisbet]

I added a new section to the troubleshooting document that gives a detailed list of commands and expected results. This will help if you have a missing or crossed line or two lines shorted together. Try the steps here and see if you get the expected results: https://tomnisbet.github.io/TommyPROM/troubleshooting/

The steps are broken into sections: data, address, and control, so that should help isolate the problem.

I looked at your wiring to check some basics, like power and ground connections to the shift registers. Beyond that, it is difficult to trace and specific connections.

If the troubleshooting steps above all check out, then there may be a noise problem that would only be fixed by cleaning up the wiring. Run all of the troubleshooting steps and we'll go from there.

@aemiller51 - thanks for your help!

[Lx32]

I tried the command, also connecting some led directly to the arduino. But if I une D0 the data led went all up. I don't know why... If can help I use a Genuino Uno, the european version of the split.

@aemiller51 yes, the color code is right, unfortunately this is the only bb that I have

EDIT: I just tried to replicate with another arduino but I have the same resault

[TomNisbet]

@Lx32 - I just checked in a fix for some command parsing problems in the HardwareVerify tool that may have been causing problems for your debugging. It's never good when the debug tools have bugs! The problem and solution are described in Issue #13.