oddblk / eeprom-writer Goto Github PK

In the code the arduino Pin13 is used as kPin_WaitingForInput, but I don't see that in the schematic.. Whereto should I connect pin 13 on the eeprom?

After an hour of trying to write my AT28C256, I could not for the life of me get anything besides FF, meaning that SDP was stuck on. According to the datasheet, the addresses are mistyped (at least for the AT28C256), because the addresses are 0x5555 and 0x2AAA, versus the repository's 0x1555 and 0x0AAA respectfully. Affects lines 259 through 270.

I've been working on a Python 3 version of the sketch used to communicate with the eeprom writer.
It's available on github here: https://github.com/eparadis/megaprogrammer28

It isn't perfect, but -s, -r, -R, -b, and -v have been used successfully. (These correspond to: write to EEPROM, read from EEPROM in ascii and binary format, and verify EEPROM contents.)

Hi, do you share the source code of the windows app?
i remade the arduino code to program an eprom 2532 and this is working very fine.
i use an buck converter to make 25V for VPP.

But i have to program 100 eprom's and want to change your windows program to run it as a batch so i can write and verify automatically and then press next and the next one gets written.
i already made a backup of the 100 old ones and have the bin files ready.
that would help me a lot.

by the way i think the comment section on your website is broken.
it says i have to enable java script but there is a error in background:

Uncaught TypeError: umzwafod is not a function
at HTMLInputElement.onclick (?p=989:183)

thank you for your project.

Hi. Chip & paramater selection implemented.
A=28C16, B=28C64 and C=28C256.
Parameters are SDP adresses and write delays.
Also python script updated.

Can be found at:
https://github.com/petersieg/eeprom

Peter

The current code doesn't wait properly for a write-cycle before crossing a page boundary. As described in the datasheet: once a byte write has been started it will automatically time itself to completion. During the write cycle (which can take a max of 10ms == 10000us), any read operation will effectively be a polling operation. Reading the last byte written will show bit 7 complemented and bit 6 toggling until the write cycle is done, at which point the data should match and a new write cycle can be started. Multiple bytes can be written to the same page as long as each is latched with 150us of the previous byte. Once 150us elapses a write cycle will start and "commit" all the latched bytes.

If you're only writing 16 bytes at a time with human-level delays between writes, and not using odd addresses things will normally be OK. But if you're writing larger blocks or crossing 64 byte boundaries you will often find that some of your bytes end up on the wrong page. For example try W003C:0102030405060708 followed by R0038.

The code needs something like the AwaitWriteComplete in my PR #8.

I'm submitting an issue here because I can't seem to add a comment to your blog entries.

I created a 24 pin variant for 28c16 EEPROMs since I needed to burn some ROMs for a pinball machine. I hacked up your firmware and wrote a quick and dirty python script to read ROM contents as well as write out an image.

There are a lot of improvements to be made(and I'm aware that the read function is returning 16 bytes for every read, which I ignored, but needs to be fixed), and I plan on adding error checking, a ROM compare and a dump function.

Anyway, I listed my GH repo below, and if you like, you can fold it into your project, or I can keep it separate and just credit you however you like.

https://github.com/mikelatiolais/28c16_EPROM_PROGRAMMER

Hi!

For different chip size different addresses have to be used for SDP enable/disable regarding to datasheets.
Now there are hardcoded addresses only for 28C64

For example for AT28C256 code should look like:

  if (bWriteProtect)
  {
    WriteByteTo(0x5555, 0xAA);
    WriteByteTo(0x2AAA, 0x55);
    WriteByteTo(0x5555, 0xA0);
  }
  else
  {
    WriteByteTo(0x5555, 0xAA);
    WriteByteTo(0x2AAA, 0x55);
    WriteByteTo(0x5555, 0x80);
    WriteByteTo(0x5555, 0xAA);
    WriteByteTo(0x2AAA, 0x55);
    WriteByteTo(0x5555, 0x20);
  }