Software not writing to EEPROM #31
-
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 3 replies
-
It appears that your serial communication problem is solved. What was the issue? Given that all of the data is coming back as FF, I suspect that the chip is still locked. Once unlocked, it is ridiculously easy to write something to the chip, even by accident. Ben's design ties the WE line to the D13 line of the Arduino and that is used to flash the LED at boot, so you could even see stray bytes written by that if the chip were unlocked. The problem is unlikely to be timing because the sketch unlock code is well within the specs for all of the chips I've seen. It is possible that you have an address or data line swapped, unconnected, or shorted. That would mean that the chip wouldn't see the correct sequence to disable SDP. A few things to try:
The TommyPROM documentation has a section on hardware debugging. That code isn't written for the Ben Eater hardware, but the ideas are the same: remove the EEPROM chip and set know address and data values and probe the lines to make sure that the correct signals are present. |
Beta Was this translation helpful? Give feedback.
It appears that your serial communication problem is solved. What was the issue?
Given that all of the data is coming back as FF, I suspect that the chip is still locked. Once unlocked, it is ridiculously easy to write something to the chip, even by accident. Ben's design ties the WE line to the D13 line of the Arduino and that is used to flash the LED at boot, so you could even see stray bytes written by that if the chip were unlocked.
The problem is unlikely to be timing because the sketch unlock code is well within the specs for all of the chips I've seen. It is possible that you have an address or data line swapped, unconnected, or shorted. That would mean that the chip wouldn't see t…