28Cxxx EEPROM Programmer

[scotws]

Great work, and I think you're right with the Nano. Thanks for the protocol -- I've spent the last couple of days either at work or moving dirt and planting stuff in the garden, so nothing new here with anything else. My father always said that progress in Germany and Scotland was driven by the bad weather ...

[mkl0815]

So your father is a wise man. I've found the time tonight to finish the prototype. It's big, it's ugly, but it works.

My testprogramm still works, writing data to the EEPROM and reading the data again.
I also started with a tool named DipTrace to create a PCB for the programmer. If I've done right, it should be 10cm by 5cm (4" by 2") in size. I have to double check the schema again and then I can post the result of the PCB here. If everything seems right, I would order some boards at http://www.seeedstudio.com, they offer 5 boards of 5x10 cm for about 20$ (without shipping).
Next step is the firmware for the Arduino Nano. First I will try to increase write-speed by using page write mode and polling to minimize the write-cycle time.
Mario.

[mkl0815]

It took some time to figure out how to use /DATA polling to determine the end of a write cycle, but after I found the right sequence I could double the write rate for writing single bytes to the EEPROM.
By writing one byte at a time, the whole 8k EEPROM can be written in 48 seconds.
Here is the output of my terminal during the test:

Code: Select all

5  4  3  2  1  0  
5  4  3  2  1  0  
start writing pattern 42 from 0x0000 to 0x03FF
finished writing
1024 bytes written in 5943 ms
start reading:

0x0000 : 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 
0x0020 : 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 
0x0040 : 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 
0x0060 : 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 
0x0080 : 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 
0x00A0 : 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 
0x00C0 : 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 
0x00E0 : 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 
0x0100 : 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 
0x0120 : 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 
0x0140 : 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 
0x0160 : 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 
0x0180 : 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 
0x01A0 : 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 
0x01C0 : 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 
0x01E0 : 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 

The next step is to play with the page write mode to write 64 bytes very fast. The microcontroller I use has 2k of SRAM and the firmware does not need a lot of this, so I will use a 1k buffer to store the data before they get written to the EEPROM. This should speed up things later, when data comes from an external tool through a serial connection.

[BigEd]

This is good! Please consider publishing your code when you're done (preferably with an open source license)
Cheers
Ed

[mkl0815]

The whole project (hardware and software) of the programmer will be open source.
At the moment I'm testing the page write mode of the EEPROM. It's really fast and almost working, but I'm facing a strange behavior.
I've made a function that gets the start address, a pointer to a databuffer and the number of bytes (up to 64) to be written.
The function follows the sequence of setting /OE, /CE/ and /WE given in the datasheet for a page write.
The first call of the function writes the 64 bytes, but only the first 2 or 3 bytes on the eeprom are modified, the next 16 or 17 bytes stay as they are and the rest of the 64 bytes is modified as expected.
The second call of this function (with the same parameters) writes all bytes without any problems. Also all other calls of the function (with different addresses) writes all bytes are correctly to the eeprom. At the moment I've no idea what causes this behavior. I assume that this is not a problem with the function itself, but with the prior steps of accessing the chip.
Aside from the fact that I have to do the first page write twice, the whole 8k EEPROM can be programmed in about 4 seconds, if the data is already in an internal buffer. If I have to pick up the data from a serial connection between the write cycles, it will take longer. But I hope, that we stay below one minute once the firmware is completed and the external tools are working.

Some additional question for the hardware. At the moment I'm using the Arduino nano as the only communication channel (over a usb-serial connection to the host system). But the both TX and RX lines could be also available at a TTL level and also as "normal" serial connection via a MAX232.
Are there any interests for these additional (optional) features, if we make a PCB for the programmer?

[BigEd]

> open source
That's great - thanks!
> odd bug writing first page
That's an odd bug... but I have no ideas on it.

[GARTHWILSON]

mkl0815 wrote:

Some additional question for the hardware. At the moment I'm using the Arduino nano as the only communication channel (over a usb-serial connection to the host system). But the both TX and RX lines could be also available at a TTL level and also as "normal" serial connection via a MAX232.
Are there any interests for these additional (optional) features, if we make a PCB for the programmer?

I'm sure adding the RS-232 option to free it from USB dependency would make it more popular with some potential users. USB is not hobbyist-friendly like RS-232 is. Some may want to feed it with a home-made computer with no USB, or even with an older PC.

No ideas on the bug here.

[clockpulse]

mkl0815 wrote:

The function follows the sequence of setting /OE, /CE/ and /WE given in the datasheet for a page write.

It could 'possibly' be a timing issue, check the datasheet for setup/access times on your particular EEPROM, maybe you're accessing a little to quickly.

[mkl0815]

I stumbled over Daryl's EEPROM programmer today. (http://sbc.rictor.org/28256.html) He follows a different approach to set the data and the address lines, but at the end the timing for reading and writing should be the same. So I can peek a little bit

[8BIT]

mkl0815 wrote:

I stumbled over Daryl's EEPROM programmer today. (http://sbc.rictor.org/28256.html) He follows a different approach to set the data and the address lines, but at the end the timing for reading and writing should be the same. So I can peek a little bit

That code is only for byte-at-a-time programming. It does poll for write completion vs. timing the write cycle. I didn't bother with page mode as speed was not a primary design goal. Hope it can help. I cannot offer any ideas as to why you get the first time write errors.

good luck!

Daryl

[BigEd]

If the first written packet is always wrong, might the chip not be ready? Does it need some time, or some dummy access, to prepare itself?

[Dr Jefyll]

The "funny" problem you describe makes me wonder about the power supply. I don't see any supply bypass capacitors -- do you have them hidden on the other side of the board? Two possible ways to proceed:

• 'scope the supply to see if you can observe a brief sag as programming commences; or...
• just add some capacitance and see if the symptom disappears. I'd suggest a generous electrolytic (10-100 uF maybe?) and also, located physically close to the EEPROM socket, a .1 or .01 uF with leads kept reasonably short.

Apologies if you've already taken care of this and the advice is redundant. Cheers,

Jeff

[BigEd]

Good thinking - there might well be a charge pump on chip which has to start up.

[mkl0815]

You are right, there are no capacitors on the board right now. But the interesting thing is, that the first bytes are written correctly. I've got my other AT28C64 eeproms yesterday and started also with one of them. There is the same problem, but with other bytes. So I think this is probably a timing problem. It seems that my shiftOut() function that sets the address lines takes too much time. I takes about 250 µs to set the lines and the bytes should be written every 150µs. Strange that it works after the first write attempt, but only for one of the chips.
I will try to speed up the shiftOut function to be sure that it sets the address lines within the timeframe.

For the PCB layout I will add some 10nF or 100nF capacitors between VCC and GND for all chips. I think I will come back with the schema and the layout as soon as it gets finished to get some hints for improvements. I'm not familiar with this kind of design work at the moment, but I'm always trying to learn something new.

@Daryl: I already saw it in the code after a closer look, that you "only" use the single byte mode. This is the mode that already works as expected. The way you build your programmer with the 74HC573 is quite interesting. Setting the address and data lines with the same outputs is a clever approach and should be much faster then my solution.
I'm really impressed from your work for different SBCs and all the "glue stuff" around it. Your page and this forum as well will be a good source for my own project and I'm sure I will have a lot of (maybe sometimes stupid ) questions.

Mario.

[8BIT]

mkl0815 wrote:

@Daryl: I already saw it in the code after a closer look, that you "only" use the single byte mode. This is the mode that already works as expected. The way you build your programmer with the 74HC573 is quite interesting. Setting the address and data lines with the same outputs is a clever approach and should be much faster then my solution.
I'm really impressed from your work for different SBCs and all the "glue stuff" around it. Your page and this forum as well will be a good source for my own project and I'm sure I will have a lot of (maybe sometimes stupid ) questions.

Mario.

Thanks for the kind words Mario. I think both designs have merits - yours requires less resources than mine. It's funny, but I started out just like you. I wanted to make an SBC, but needed a way to program an EEPROM, so I built the programmer first. Mine started with a PC parallel port, using the 74573's. After I built my first SBC, I dropped the parallel port and moved it to the VIA's.

I have a feeling it won't be long before you start on your SBC project. It has been a fun and rewarding experience for me, and I'm happy to share my successes (and failures). I have posted 90% of my work on my website. It's there for others, like yourself, to use for reference in their own projects. When I started, I studied the SBC's that others had built (Chris Ward, Lee Davison, and others), and went from there.

Keep the questions rolling too, there are no stupid questions!

Good luck and have fun!

Daryl