Zero bits cleared in uncontrolled manner. Latent problem in write_data_bus() on AT28C256

[kervinck]

//write a byte to the data bus
//be sure to set data_bus to output before
void write_data_bus(byte data)
{
  //2 bits belong to PORTB and have to be set separtely 
  digitalWrite(D6, (data >> 6) & 0x01);
  digitalWrite(D7, (data >> 7) & 0x01);
  //bit 0 to 6 belong to bit 2 to 8 of PORTD
  PORTD = PIND | ( data << 2 ); // <--- this statement works by accident? (MvK)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
}

I have the impression that the only reason that this statement works is because the bus is put into high-impedance mode for quite a while before every byte write, and apparently that resets all bus bits to 0. In that case "PIND | (data << 2)" sets the correct data.

However, in high-speed operation this is not the case, and earlier 1's get stuck. I found this because I extended the MEEPrommer to lock/unlock AT28c256 chips. They require specific lock/unlock sequences to be sent at a higher speed.

I suggest to rewrite the body along these lines:

  PORTB = (PINB & B11111100) | (data >> 6);
  PORTD = (PIND & B00000011) | (data << 2);

Note the explicit clearing of the old bits prior to OR'ing the new data.

I spent several days with a scope debugging this, fiddling with timings, different voltages, pulldown and pullup resistors until I spotted this. With the above proposal, the lock/unlock sequences work for me...

[retux]

Hey Kervinck,
I'm having probably the same issue. So far my best bet is that it might be due to timing problem. Do you suggest to replace the line

PORTD = PIND | ( data << 2 ); //

By the ones you mentioned? Could I get your code with the unlock sequence?
Thanks!

[kervinck]

Here is my version. It is heavily modified in an attempt to understand the code and add features, so that is why I didn't consider a pull request. But you can see the above-mentioned fragment in it, and the unlock routine is there as well. While it worked and I'm pretty sure his version is the last I used, I don't use this code anymore today. "For reference only"
MEEPROMMERfirmware-kervinck.ino.zip

[retux]

Thanks a lot! I will try to analyze and compare the code to see if i can get it to work.

[retux]

Hey kervinck, thanks to your version I was able move a bit further. Still there is a way to go, but i believe I'm closer. If i read from eeprom (at28c256) I get every byte 0xFF, but when I try to write there must be something wrong with data polling as program remains in the loop:

MEEPROMMER-MvK (derived from MEEPROMMER 1.2), CMD:R,r,w,W,V,v
0000: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0010: FF
%
writeBlock address 0x0000 bytes 0x1
error address 0x0000 expected 0x61 actual 0xFF writeTime 110.89
info retry 1
error address 0x0000 expected 0x61 actual 0xFF writeTime 179.42
info retry 2

I also tried with a sram I had (6264). With it I can write byte by byte through arduino serial monitor, and that works, but when I try to write 8kb from a binary file the data in ram does not match.

[kervinck]

I haven't looked at the code for more than a year. There remained too much experimenting involved with getting the sequences right for each chip. In the end I bought a cheap programmer (MiniPro TL866 like) on aliexpress and never looked back.

[khelifk]

Here is my version. It is heavily modified in an attempt to understand the code and add features, so that is why I didn't consider a pull request. But you can see the above-mentioned fragment in it, and the unlock routine is there as well. While it worked and I'm pretty sure his version is the last I used, I don't use this code anymore today. "For reference only" MEEPROMMERfirmware-kervinck.ino.zip
Hi all,
Thank you Kervinck, I was strugling with the code, and seems your program is working like a charm, thank you