Replies: 6 comments 1 reply
-
|
That chip has a 16 byte buffer for block writes. Did you change that at the top of TommyPROM.ino where the chip is declared? Your device declaration line should look like this: |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for addressing this so quickly :) Block writes have been disabled from the beginning, declaration line Also tried going back and forth between 0 and 16 bytes a couple of times to verify the error wasn't caused by something else. No write failures with block size reset to 0, nothing changed otherwise. So, lets try slowing the code down, if you don't have anything else you want me to try before :) |
Beta Was this translation helpful? Give feedback.
-
|
That is confusing. With a block size of zero, the code will be writing a single byte and then reading it back to verify. The fill command should have failed above at 1c0f and printed a message. Can you try using the zap command and posting the result? I'd like to see what happens when the data between each byte is different. Also, there is an Info "I" command that will print some additional debug information after a failure. I looked at the data sheet and the shortest times between the signals are 450ns. The current code is delaying for 1000ns between the signals, so that shouldn't be the problem. If you want to increase the delays, look at burnByte and waitForWriteCycleEnd in the PromDevice28C.cpp file. You can change the delays and add new ones. Try adding a delay after setAddress() in burnByte. |
Beta Was this translation helpful? Give feedback.
-
|
Okay, so the programmer verifies written data byte by byte. Yes, very confusing then. If we're assuming the code is doing what it's supposed to, the only reasonable explanation would be that some memory cells loses charge or something, and the data changes between writing/verifying and me dumping the memory contents to console. I thought those old EEPROMs were more or less immortal, but might have to change my opinion on that then. Tried filling the chip with 00, then filling it with FF, and started checksumming it periodically immediately afterwards. The data looks stable enough within that timeframe at least: There's of course no way for me to check what happens the micro- or milliseconds directly after writing to the cells though... The zap command fails at 0xF, consistent with how it looks after a fill. Block writes disabled if that matters somehow. It's always byte E or F in each row that's bad. With zap, it errors out as expected. Are the zap and fill verification routines perhaps different? Enabled 16 byte block writes, tried the fill command, and printed debug info: I'm very much a newbie when it comes to programming, but I'll try figuring out how to manipulate the delays, and revert with the results in a separate post. I'm also thinking it might be worth trying with longer programming pulses aswell, if you can help me with that too. Big thanks for your help so far in any case 😄 |
Beta Was this translation helpful? Give feedback.
-
|
Raised all 1 μs delays found in burnByte and waitForWriteCycleEnd - five of them in total - to 2 μs, and believe it or not, it works perfectly now 😄 Tried filling with different byte patterns, erasing, and zapping a few randomly chosen address spaces. No errors at all anymore. Also found the burnBlock function. Tried raising the delays in it to 2 μs aswell, and enable 16 byte block writing, but that still throws me "ERROR: Write failed". I'm happy without block writes, but if you want to try figuring it out, I'm of course at your service with testing. Also, it's really strange that it passed the byte by byte verification before, please tell me if I can help you with any further testing of that too. If it's possible to ship from Sweden to where you are in a regular letter, avoiding customs declaration and associated fees/administration, etc, I could also send you a chip to experiment with if you want. |
Beta Was this translation helpful? Give feedback.
-
|
It would be interesting to see the results of a zap command to address 1 or 2 instead of zero. Will the problem byte move or will it stay at the 16 byte boundary? If you have a spare chip to send to the US, I would like to try programming it while watching the signals on the logic analyzer. Please send a DM to nib85 on reddit if that is something you are willing to do. In any case, I'm glad the code is working for you. What sort of project are you doing with those chips? |
Beta Was this translation helpful? Give feedback.
-
|
Filled the chip with 00, reverted the delays to 1 μs, then filled it with FF. The first 128 bytes after that: Did some zapping with different offsets: Before, zapping would fail at adress 1F iirc, but if it is a timing issue and we're close to the limit, I guess some randomness is to be expected. Both times it fails, it's on the 16 byte boundary. I'm not at Reddit, but improvised and created a private repository here with my mail address in the description and invited you to it instead. Please mail me your details, and I'll send you a chip :) Github should really add a PM feature btw... Salvaged the chips from a decommissioned 80's marine automation system (ABB Selma), planning to use at least some of them for custom cartridges and other C64 stuff :) |
Beta Was this translation helpful? Give feedback.
-
Trying to erase a few Xicor X2864AP-45 EEPROMs by filling them with FF, without success. Some bytes will not erase properly. There's a certain pattern to it, if relevant somehow:
(Only dumped the last 512 bytes to keep the screenshot reasonably small, but it looks more or less the same everywhere)
The programmer works perfectly with other 64kbit 28 series EEPROMs.
Those chips might be ancient, but they tend to be more or less immortal. They haven't been stored under conditions outside what's specified in the datasheet. With other words I don't believe there's anything wrong with the chips either.
The X2864AP-45 is however a 450 ns chip. Can't even remember seeing any 28 series chip that slow before. Could it perhaps be some kind of timing issue, that the programmer is designed with faster chips in mind, and simply goes too fast?
Had a look at the code, but couldn't see any obvious ways to tweak the timing. Just wondering how to go about it?
Also, as a suggestion for future releases, would be nice to be able to tweak the timing from configure.h or something :)
Beta Was this translation helpful? Give feedback.
All reactions