23454b9dad
Also remove slower generic Arduino code so that the project is now tied to specific Arduino versions. Add readme for 28C chips.
2.8 KiB
Notes on 28C EEPROMs
The 28C series parallel EEPROMS, like the 28C256, support fast block writes and algorithms to implement Software Data Protection (SDP). The SDP feature seems to be a leading cause of problems for people trying to program these chips with Arduino or other homebrew hardware.
The first problem many people encounter is that new chips are often locked, even though the datasheet states that they should ship unlocked. It isn't clear if the manufacturing practices have changed or if this might be due to used or conterfeit chips. In any case, the chips may need to be unlocked before they can be programmed for the first time.
The unlock is accomplished by sending a sequence of bytes to specific addresses. Many people have reported problems with this step when using DIY programmers. Some programmers may not be writing the SDP sequences quickly enough to successfully unlock the chips and yet others will report that the same hardware works correctly. This may be due to variences in the behavior of chips from different manufacturers.
When writing SDP lock/unlock sequences, the datasheets note that the timing between bytes must follow the same restrictions as page writes. In particular, the bytes must be written within the tBLC (Byte Load Cycle time). On Atmel parts, this is specified as 150us max, so each write pulse must occur within 150us of the previous write. The tBLC value is even shorter on the Xicor and ON Semi datasheets, stating that the writes must occur within 100us of each other.
In practice, the Xicor chips seem very forgiving of the timing, doing successful SDP and page write operations even when the tBLC is close to 200us. Atmel chips, on the other hand, will refuse to unlock when the timing is outside the acceptable maximum.
Solution
The TommyProm programmer uses direct port access to control the data bus and addressing shift register. This is much faster than doing individual DigitalWrite calls and allows the unlock and page write code to run comfortably with the tBLC constraints. It has been tested with Atmel chips and multiple batches of Xicor 28C256 chips with success.
The capture below shows an unlock command sequence where the tBLC us within 80us for each byte.
