Parallel EEPROM programmer not writing correctly - Page 1
Forum section: electronics / projects

author: SirWhy
author_rank: Contributor
timestamp: June 17, 2016, 11:05:54 am
content: 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.Linkto difference check

author: uncle_bob
author_rank: Unknown
timestamp: June 17, 2016, 01:17:11 pm
content: Quote from: SirWhy on June 17, 2016, 11:05:54 amHiSounds 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

author: SirWhy
author_rank: Contributor
timestamp: June 17, 2016, 01:58:28 pm
content: 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

author: uncle_bob
author_rank: Unknown
timestamp: June 17, 2016, 02:04:42 pm
content: Quote from: SirWhy on June 17, 2016, 01:58:28 pmHiWithout 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

author: SirWhy
author_rank: Contributor
timestamp: June 17, 2016, 05:20:46 pm
content: 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 writecycle."The programmer uses this feature to tell when it can write next.Here is the function that handles this.Code://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 10msvoid fast_write(unsigned int address, byte data){byte cyclecount=0;//first disbale outputset_oe(HIGH);//disable writeset_we(HIGH);//set address busset_address_bus(address);//set databus to outputdata_bus_output();//set data buswrite_data_bus(data);//enable chip selectset_ce(LOW);//wait some time to finish writingdelayMicroseconds(1);//enable writeset_we(LOW);//wait some time to finish writingdelayMicroseconds(1);//disable writeset_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.

author: uncle_bob
author_rank: Unknown
timestamp: June 17, 2016, 05:52:25 pm
content: Quote from: SirWhy on June 17, 2016, 05:20:46 pmHiSo 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

author: C
author_rank: Super Contributor
timestamp: June 17, 2016, 09:18:05 pm
content: 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 $ OECode:while(data != read_data_bus()) {cyclecount++;};C