Sure, here's the datasheet to this particular chip. I'm going for the write timing shown in this exactly. I've found out that writing is not working, not sure if it ever was, although read is very reliable now.datasheet

Lightning edit: That is, the write timing for single byte writing, I'll mess with page writing later.

EDIT: to elaborate further

(these first 2 are not exactly to the timing diagram, I tried it their way and it still isn't working, and I'm confident this won't cause problems by setting them up before hand, gives them ample time to slew to the correct values)
Assert Address on bus
Assert Data on bus
CE LOW
small delay
WE LOW
less small delay
WE HIGH
small delay
CE HIGH

I really need to get all my thoughts out in a single post rather than coming back here to dump more out. I forgot to mention that all values are reading 255 now, which makes sense since that's what they're supposed to be at when the chip is new, which is why I think writing hasn't been working at all. I've tried delays as long as a second between each step I stated above, still no dice.

After looking at that github once more for the project that is verified working, they lower and raise CE and WE at the same time, so I'm switching to that methodology because it's easier and should save some delay. So now the timing I'm going for is simply:

Addr
Data
CE and WE LOW
delay
CE and WE HIGH

Have you got the right nanosecond and millisecond timescales?

Are you changing the data pins from outputs when writing to inputs when reading? I see no mention of the data lines being tristated in your messages.

Just checking.

Is the code anywhere on the web?

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

From the datasheet most things are in ns, a couple in us, and a couple in ms, presently I'm using ms timing for everything so it's very slow, and has the best chance of success.



Yes, I'm changing the data lines from outputs to inputs when reading, and inputs to outputs when writing, it's not anywhere on the web, but I may clean it up and post the file here.

Ok, I've verified that the write setup works fine with SRAM, just not with the eeprom. I've also got it doing the "exit cycle" for software data protection during setup, although I'm not sure if it's completely correct (looks like it, but writes still aren't working, so who knows). At this point, I'm thinking one of 3 possibilities, in order of possibility:

The EEPROM timing has some requirement that is different than SRAM, and not easy to spot in the documentation
The EEPROM has software data protection on, and my method of turning it off is not working
The EEPROM is bad.

Am I missing any possibilities?

This is interesting, in the project I mentioned earlier I see this code for disabling software data protection:



But my code looks like this:



(I know, mine is backwards, it takes data first then the address). The documentation seems to agree with my way, stating hex addresses:

5555
2AAA
5555
5555
2AAA
5555

in that order, why is their code doing it differently? There's is verified working, so I may try this, I'll have to throw the eeprom back on it though, I'm presently playing with the SRAM to check and make sure everything is, indeed, kosher

EDIT: I've found out why his is different. Atmel 64 chips (8k eeprom variant) don't have addresses that high, and require the setup he has put in there. This means his kit probably wouldn't be able to unlock a 256, but that is why his is written the way it is. This puts me back at square 1 for finding out why I can't write to this.

The problem is really starting to annoy me, I even tried slowing down read, thinking maybe the outputs weren't valid yet (which they were, and they all still read FF). I found some issues with how I was setting up the address pins, and those are fixed, and I've run the software protection disable probably a hundred times now, straight from the datasheet. I'm really stumped.

Here's my present code, I'm still working on it, it's not entirely clean yet either.

I have now pasted in the code from the project I mentioned earlier, changed pin numbers to match my setup, and it still will not write (also modified the software write protect function to use the values for my chip). I'm at a total loss at this point, it must be something hardware related, but it works just fine with the SRAM chip.

Your list of possibilities isn't bad. A fuller set might look something like:
- you missed something in the datasheet
- you misinterpreted something in the datasheet
- your software doesn't do what you think it does
- your wiring doesn't do what you think it does
- your EEPROM doesn't work

As the EEPROM needs to generate a high voltage on-chip, I expected to see something about power up timing, and maybe needing to do some number of read cycles to get the charge pump and/or PLL started up, before attempting writes. I didn't see that in the quick skim I did, but it might be there.

It's good that you are waiting milliseconds where you need to, but I'm not sure substituting milliseconds for nanoseconds will always be wise. For one thing, any noise or disturbance on the control signals will start a new access or close the current one. For another thing, running so slowly won't have been anticipated by the chip designers.

As ever, good electrical connections, solid power supply, and local decoupling caps will be a help.

The one thing you mentioned here is doing a bunch of reads first, which I didn't even think about, I used to be doing 500 reads at startup when I was having the weird bit loss problem, but I cut that out after I fixed it, let me add that back in, let's call it 10k reads, just to be sure, I'll move my delays for writing down to about 1ms tops too (will try for a couple hundred microseconds)

THAT DID IT! THANK YOU SO MUCH!

I never would've thought of this on my own, drop 10k reads in before I do any writes and BAM! It works!

I really cannot thank you enough BigEd, this has been absolutely killing me, I've probably lost more hair than a cancer patient at this point.

Well that's unexpected, but a good result!