Trying to get TommyPROM working?

[JohnDavidGay]

I've breadboarded TommyPROM, but I am having issues getting it working and don't understand enough to find the fault myself. I've downloaded the firmware to my Boarduino, and I can read the contents of EEPROM's but attempts to write fail. Is there a way I can contact someone to help me?

Cheers,

 John Gay

[TomNisbet]

I haven't built this with a boarduino, but it should work as long as you connect the same pins and get the right board defined in configure.h. In that file, be sure to comment out all of the #define ARDUINOIS lines so that the code uses the generic data bus code instead of the faster board-specific code.

Which chip are you trying to program? The datasheet says that 28C256 chips are shipped with write protect disabled, but I got a batch of them that were write protected. The Unlock command should fix this.

If you can explain the failure you are seeing I should be able to walk you through it. Also, there is a define for ENABLE_DEBUG_COMMANDS in configure.h that can be used to add some additional command line tools that may help. The ZAP command will program a small pattern into the chip and then read it back. This is a nice way to verify write functionality without having to transfer files.

Tom

[JohnDavidGay]

Thanks for the reply. I don't remember what ARDUINOIS line I left in the last time, but I did try each one because I wan't sure what the Boarduino should be. I'll try commenting all all of them and see how that works. I'll also enable the ENABLE_DEBUG_COMMANDS so I get more details. I've got 28C256's and 28C64's I also have some UVEPROMs that I've been able to read data from, but since they are from a 68,000 board, the data is split between to two chips. I was just checking to be sure I could read actual data. I've been trying to use the fill command to write the data and it just errors out. The set-up is my home Laptop and I can try after work or during the weekend. I'll let you know what I get. Is there a more direct way to chat? I didn't want to open an issue on your Github.

Cheers,

 John Gay

[TomNisbet]

John,

It sounds like you are on the right track. If you are reading known good data from a chip and not just random bytes, then you’ve already verified almost all of the hardware. This is exactly how I checked out the initial design with some old EPROMS.

Verify that the connection to the WR pin of the rom is going to the pin on the arduino that is defined in the software. Also verify the both the read and write pins are high when you aren’t doing any operation. If you have a logic analyzer or storage scope, you can also verify that the WR pin is pulsing low during a write operation.

Another check is to see if you are making any change to the chip at all when you try to write. In other words, try a fill command to write 00 or FF to the first byte if the rom and then do a read to see if it’s value changed at all.

I think the default code uses a block write algorithm and this can be changed to do a simpler write-then-read instead, but I don’t have the code in front of me now to look.

Finally, don’t forget the Unlock command. My first batch of 28c256s were write protected and I spent a long time debugging that.

Let me know how it goes. I’m sure we’ll be able to get you up and running.

Tom Sent from my iPhone

On Jun 3, 2019, at 11:31 AM, JohnDavidGay notifications@github.com wrote:

Thanks for the reply. I don't remember what ARDUINOIS line I left in the last time, but I did try each one because I wan't sure what the Boarduino should be. I'll try commenting all all of them and see how that works. I'll also enable the ENABLE_DEBUG_COMMANDS so I get more details. I've got 28C256's and 28C64's I also have some UVEPROMs that I've been able to read data from, but since they are from a 68,000 board, the data is split between to two chips. I was just checking to be sure I could read actual data. I've been trying to use the fill command to write the data and it just errors out. The set-up is my home Laptop and I can try after work or during the weekend. I'll let you know what I get. Is there a more direct way to chat? I didn't want to open an issue on your Github.

Cheers,

John Gay — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[JohnDavidGay]

I rushed home last night excited to try this out when I realised I had re-installed my Laptop recently and didn't have the Arduino IDE or your code on it. PLUS, I recently changed Internet providers and am currently un-connected at home until Friday. So I've snuck my Laptop to work to "borrow" bandwidth to get the code and IDE over my lunch break. What I don't have are any tools other than a multi-meter, so checking Voltage levels is possible, but not pulses. I'm not certain the data from the UVEPROM is valid, but it doesn't seem completely random. What I have are two 8-bit EPROM's that were used as upper and lower bytes for a 16-bit board. I've tried the UNLOCK command a few times and it completes without complaint. I've tried using the fill command to write aa to the first 8 bytes, but the command errors out and when I dump the data it's still all ff's. I am currently using cutecom on Linux to talk to the TommyPROM. I just lack the programming skills to try poking the EEPROM directly with the Arduino to see if I can at least change the memory. Thanks for all your help. I've got a Z-80 Single board computer I'm looking to play with, as soon as I can get an EEPROM programmed. I also have a MC68000 I want to poke at as well. Just reliving the days when I wished I had the money to play with those processors the first time around.

Cheers,

 John Gay

[JohnDavidGay]

I've commented out all 3 ARDUINO_IS lines and ENABLE_DEBUG_COMMANDS is not commented out. f0000 000f aa gives: ERROR: Write failed And f0000 00ff shows all 16 bytes are ff. I was able to install the arduino app and your code to my laptop. The next step is to carefully verify every wire is correct. Especially the write enable line. Thanks again for all your help. I'm sure the problem is all my doing.

[JohnDavidGay]

I've checked the wiring and everything looks good. WE == A0 == Pin27 CE == A1 == Pin 20 OE == A2 == Pin 22 I've checked that all 3 are high and they are pulled up with resistors. But I've only got a Fluke 77 Multimeter for checking.

When I run d0000 00ff Both CE and OE seem to drop their voltage momentarily. But when I run f0000 000f aa WE does not seem to change. CE and OE both seem to drop, but WE stays a solid voltage. I have checked at both the EEPROM pin and on A0 on my Boarduino. Using Cutecom on my Linux Laptop, I have upped the Char Delay setting to 200ms to see if that makes a difference. So I'm not sure, but it doesn't look like WE is being pulled down during the fill command? Or maybe A0 isn't working on my Boarduino?

[TomNisbet]

The WE line is going to pulse quickly, so you are unlikely to see any change on your meter. You could try moving it to a different pin to see if that has any effect. Just change the definition in PromDevice28C.cpp to match the new pin.

I'm starting to suspect that the problem is still with device locking if you are not seeing any change to the chip after a write operation. The Unlock command sends a sequence of bytes to the chip, so if there is a problem with the data or addressing then it won't successfully unlock. Are you confident that the D command is reading accurate data when you test with other chips? My original build used long jumper wires for the data lines and may have had problems with crosstalk.

Also, I just looked at the schematic for a boarduino and it looks like D2..D9 are mapped to the same ports as the UNO, so you should be able to uncomment ARDUINO_IS_UNO in Configure.h.

[TomNisbet]

Now that you have enabled DEBUG, try the Scan command to verify reading the chip. It won't be interesting on an erased chip, but one of your other ROMs can give you more confidence that the reads are working. Note that this will only verify read consistency. It wouldn't verify that you has two data wire swapped and were reading the wrong value out every time.

[JohnDavidGay]

I have no way of knowing what was on the PROMs I have. I just know that they were on a 68000 board and were set-up as odd and even bytes. I checked the Boarduino schematics, and there are only A0-A5 available, and they are all used. the Scan command passes with the UV EEPROM, but of course that doesn't prove the data or addresses are correct. But even if I have the data or address lines swapped, I would expect that it should still write data. It would just put it in the wrong address or possibly shuffle the bits if the data lines are crossed. Maybe if I had a simple sketch that only tried to write data I could troubleshoot my problem and then get back to loading TommyPROM later. I'm really interested in spinning a TommyPROM board as a soldering exercise for my local makerspace.

[TomNisbet]

Can you send me a message to tommyprom@mailinator.com so I can get your email address? It might be easier to correspond directly so we can send attachments,

I think the problem is that the chip is write protected. If the data and address lines have a problem then the unlock command isn't going to work. That's why I'm interested in verifying the read commands.

If you want to force some lines to the chip, it might be easier to just modify this code than to build a new standalone module. For example, you could add code to toggle the write and enable bits at the end of PromDevice28C::begin(). Or you could even wire up a 28C without the arduino. Tie the address lines to Vcc or ground to get a pattern you like, tie OE high, CE low, and then pulse WE with a button or jumper. The datasheet doesn't show a max pulse width for WE, so it shouldn't hurt anything.

As I said before though, I'm guessing the problem is the write protection, so the above tests aren't going to produce anything.

[JohnDavidGay]

I've buzzed out all the lines again, making sure that I've got the right '164 connected to the right 8 bits of the address bus. I changed the WE to LOW and that worked, so I know it's not that. If the chip is write-locked, that can only be fixed programmatically which means getting this going. The only point not entirely clear in your schematics that I had to guess is D2 goes to D0 on the chip and D9 goes to D7. The way you drew the bus is ambiguous.

[JohnDavidGay]

After some direct contact and troubleshooting, Tom fixed this issue and updated this project. Great support!

[TomNisbet]

Issue was related to the timing of the Unlock command for the Software Data Protection(SDP). Xicor parts that I used were much more forgiving than the Atmel parts John used. Optimized the code so that the Unlock and page writes are now well within the timing specifications on the datasheet. Also added a 28C readme with more information. Created a new, standalone hardware debug utility that should help with troubleshooting in the future.

[JohnDavidGay]

Since I was scared of KiCAD, I've installed Fritzing instead. In the plus side, it's designed for building Arduino shields. So hopefully maybe I can get a TommyPROM shield going.

Cheers,

 John Gay

On Mon, Jun 24, 2019, 4:33 PM Tom Nisbet notifications@github.com wrote:

Issue was related to the timing of the Unlock command for the Software Data Protection(SDP). Xicor parts that I used were much more forgiving than the Atmel parts John used. Optimized the code so that the Unlock and page writes are now well within the timing specifications on the datasheet. Also added a 28C readme with more information. Created a new, standalone hardware debug utility that should help with troubleshooting in the future.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/TomNisbet/TommyPROM/issues/3?email_source=notifications&email_token=AMGL2WYKKQB6SFJXRBEYQG3P4EVQJA5CNFSM4HQNO5O2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYOEMEY#issuecomment-505169427, or mute the thread https://github.com/notifications/unsubscribe-auth/AMGL2W4FPTP52ZBSPGIA5PLP4EVQJANCNFSM4HQNO5OQ .