Propeller 32123 EEPROM issues
MorrisMorris
Posts: 16
in Propeller 1
Hi all, I am developing a one-off design for a client and I'm using a 32123 Propeller 1 in the design, for convenience. Yesterday I was able to write to RAM or EEPROM, but today I came in to finish up my code and I get an EEPROM verify error anytime I try to write the code. Basically changed overnight.
I have tried both the Propeller Tool and Propeller IDE. I have rebooted several times (which seems to solve a lot of issues with Prop Tool) to no avail. I have also tried writing with both the 5v applied in the full design and writing with only the USB power. Checked all connections and multiple USB ports.
Anyone have a clue what might be going on here? I'm only on day two here and surprised to be having these issues already.
Comments
PS, I have also uninstalled all related software and reinstalled the Prop Tool. No Change.
Did you end up with a piece of debris on the EEPROM? Pull the FLiP and brush the component side with a chip brush or use a can of compressed air.
I have a FLiP on a breadboard with a working circuit and when I plugged it in and tried to communicate with it Propeller Tool complained -- the port had been excluded (and I don't know why). I had to use the Edit Ports feature to remove all port rules and then I was able to communicate with it.
I ran the attached program that shows the EEPROM identifying itself on the bus.
You may have bad flip module. Are any pins shorted. Does F7 ID prop work?
First, run Jon's program from RAM to make sure the EEPROM identifies. If it does, enter a short program that, say, turns on the LED attached to P26. (Make sure to end it with a repeat so the LED stays on. Try loading it into EEPROM. If you get an error, reset the Prop, and see if the LED comes on anyway. If it does, that will tell you that the EEPROM at least partially works.
Beyond that, you can always dump EEPROM from a RAM program and compare it with an .eeprom file saved from the same program. I've got a dump program that I wrote years ago. If it comes to that, I'll see if I can find it.
-Phil
Just remembered: a program in EEPROM probably won't start if the Prop detects a checksum error.
I'll try this later today and post the results. The chip is still holding the code I flashed the evening before and when reset, operates as normal, I just can't write to it any more. All pins I'm using work correctly and don't appear shorted.
The fact that an old program still runs but can't be overwritten indicates that the EEPROM is still functional for reading but not writing. Perhaps its write-protect pin (#7) has somehow gotten disconnected from Vss (due to a bad solder joint?) and is floating. I don't suggest trying to probe the pin, since the pin spacings on the EEPROM are microscopic.
This may be a case for Parallax to evaluate in-house. In any event, this is a good time to stock up on FLiP modules, since they're on sale at 20% off through 2 January.
-Phil
Update: The EEPROM datasheet is pretty vague about the chip's behavior when WP is asserted, except to say the writes are ignored. That being the case, it might be possible to test this pin by attempting a write to the chip and polling ACK/NAK right away. If the chip is beginning a write, it will poll NAK until the write is complete. If it polls ACK right away, chances are that WP is being asserted with writes just being ignored.
I don't have my microscope with me on this trip, could you post a link to the EEPROM datasheet for me?
Here's the link:
https://www.digikey.com/htmldatasheets/production/768290/0/0/1/M24512-x.pdf
In this chip, WP is called /WC. The function is the same. This datasheet also explains how the chip responds with /WC pulled high (see figure 8). Basically, it will not ACK a data byte being written, which would be an easy thing to check for.
-Phil