Parallel EEPROM programmer not writing correctly

[SirWhy]

Hi,

I am building a homebrew Z80 system and have got to the stage where I need to burn a ROM image. Not wanting to reinvent the wheel I searched around to see if anyone had made an arduino based EEPROM programmer and lo and behold they have (Project page)

Even has a nice java GUI to boot. My problem is that when I write an image, then read it back and run it through a difference checker, there are about 30 bytes different at the start of certain 256 byte write cycles.

I'm using an Atmel AT28C256 and an arduino UNO. Wondering if anyone has any solutions to this problem? Even though I could replace the bytes the hard way, it seems like this is a problem that could be fixed.

Link to difference check

[uncle_bob]

Hi,

I am building a homebrew Z80 system and have got to the stage where I need to burn a ROM image. Not wanting to reinvent the wheel I searched around to see if anyone had made an arduino based EEPROM programmer and lo and behold they have (Project page)

Even has a nice java GUI to boot. My problem is that when I write an image, then read it back and run it through a difference checker, there are about 30 bytes different at the start of certain 256 byte write cycles.

I'm using an Atmel AT28C256 and an arduino UNO. Wondering if anyone has any solutions to this problem? Even though I could replace the bytes the hard way, it seems like this is a problem that could be fixed.

Link to difference check

Hi

Sounds like the people who wrote the code for the programmer did not do it correctly. They probably violated one or another of the various limits on how to do the write correctly. Generally it's a matter of trying to do it to fast. Unless you wrote the programming code yourself, the only real solution is to contact the people who did write it.

Bob

[SirWhy]

Yeah I was just about to send an email to the guy who wrote the code. With further thought zip think it might be when the EEPROM is switching pages that it might be missing the timing window,  resulting in something being written but not correctly. It is only the first byte in some 256 byte blocks.

Will try slowing down the code myself also

[uncle_bob]

Yeah I was just about to send an email to the guy who wrote the code. With further thought zip think it might be when the EEPROM is switching pages that it might be missing the timing window,  resulting in something being written but not correctly. It is only the first byte in some 256 byte blocks.

Will try slowing down the code myself also

Hi

Without looking at the code, going through it line by line, and working out exactly what each line does ... no way to know what the error is. It *could* be timing. It also could be any of a few hundred coding errors. The gotcha is: If it's marginal and failing, you fiddle it a bit and now it's marginal and passing. The bits are OK now and in a month they randomly flip state. You do *not* want to be on the very edge of a timing problem. They generally overdo the write process about 6 to 10X for safety.

Bob

[SirWhy]

Having gone through the code completely it seems that a delay isn't being used, but rather /DATA polling.

From the AT28C256 datasheet
"The AT28C256 features DATA Polling to indicate the end of a write cycle. During a byte or page write cycle an attempted read of the last byte written will result in the complement of the written data to be presented on I/O7. Once the write cycle has been completed, true data is valid on all outputs, and the next write cycle may begin. DATA Polling may begin at anytime during the write
cycle."

The programmer uses this feature to tell when it can write next.
Here is the function that handles this.

Code: [Select]

//highlevel function to write a byte to a given address
//this function uses /DATA polling to get the end of the
//write cycle. This is much faster then waiting 10ms
void fast_write(unsigned int address, byte data)
{
  byte cyclecount=0;

  //first disbale output
  set_oe(HIGH);

  //disable write
  set_we(HIGH);

  //set address bus
  set_address_bus(address);

  //set databus to output
  data_bus_output();

  //set data bus
  write_data_bus(data);

  //enable chip select
  set_ce(LOW);

  //wait some time to finish writing
  delayMicroseconds(1);

  //enable write
  set_we(LOW);

  //wait some time to finish writing
  delayMicroseconds(1);

  //disable write
  set_we(HIGH);

  data_bus_input();

  set_oe(LOW);

  while(data != read_data_bus()) {
    cyclecount++;
  };

  set_oe(HIGH);
  set_ce(HIGH);

}

I'm going to try adjusting the timings anyway, will post back results. However anymore help is appreciated.

[uncle_bob]

Having gone through the code completely it seems that a delay isn't being used, but rather /DATA polling.

From the AT28C256 datasheet
"The AT28C256 features DATA Polling to indicate the end of a write cycle. During a byte or page write cycle an attempted read of the last byte written will result in the complement of the written data to be presented on I/O7. Once the write cycle has been completed, true data is valid on all outputs, and the next write cycle may begin. DATA Polling may begin at anytime during the write
cycle."

The programmer uses this feature to tell when it can write next.
Here is the function that handles this.

Code: [Select]

//highlevel function to write a byte to a given address
//this function uses /DATA polling to get the end of the
//write cycle. This is much faster then waiting 10ms
void fast_write(unsigned int address, byte data)
{
  byte cyclecount=0;

  //first disbale output
  set_oe(HIGH);

  //disable write
  set_we(HIGH);

  //set address bus
  set_address_bus(address);

  //set databus to output
  data_bus_output();

  //set data bus
  write_data_bus(data);

  //enable chip select
  set_ce(LOW);

  //wait some time to finish writing
  delayMicroseconds(1);

  //enable write
  set_we(LOW);

  //wait some time to finish writing
  delayMicroseconds(1);

  //disable write
  set_we(HIGH);

  data_bus_input();

  set_oe(LOW);

  while(data != read_data_bus()) {
    cyclecount++;
  };

  set_oe(HIGH);
  set_ce(HIGH);

}

I'm going to try adjusting the timings anyway, will post back results. However anymore help is appreciated.

Hi

So next thing to check:

Did the "missing" byte get written to the correct page or did it accidentally go to the previous (or next) page before the write cycle started?

Bob

[C]

data sheet page 10 figure 23 shows both CE and OE cycling to check if write is finished.

does this code raise and lower CE $ OE

Code: [Select]

  while(data != read_data_bus()) {
    cyclecount++;
  };

C