EEprom Faliure

crgwbr

In the industrial project I'm doing (I'm sure you've heard about it from other posts), I need to store 6 bytes of information in EEprom. To do this I am using Mike's Minimal I2C object. The EEprom (24LC256) is on I/O line 0 and 1. What's happening, is the EEprom seems to be losing it's memory after several hours or days. For example, at 9:00 AM this morning, it read the values perfectly, 11:00AM, they all read 0. I've tried numerous things to try to correct this, including the routine Mike wrote that pulses the clock line for up to 9 times. None of these had any effect. I also don't believe that the eeprom is defective, I tried putting the values on the boot-up eeprom, same thing happened. I've been attempting to fix this problem for over a week now, and still don't have the slightest clue as to what is going on. Because of this trouble, my boss is now convinced that the propeller is not a good product, and is threatening to outsource the project to Siemens (In other words, I get fired). Please, if anyone has an Idea of what could be happening, post it. At this point, anything would help.

Thank you,
Craig

Post Edit: Code is now uploaded

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.

Microsoft: "You've got questions. We've got dancing paper clips."

Post Edited (crgwbr) : 4/9/2007 4:08:39 PM GMT

QuattroRS4

can you post your code ? I'd bet its there but being overwritten - or there is an issue with your read structure..

Regards,
Quattro

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'

crgwbr

I'll post my code as soon as I can get to it. It's on a work computer, and I'm in my home office. I already request that it be emailed to me.

Thanks, Craig

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.

Microsoft: "You've got questions. We've got dancing paper clips."

Leon

Is its supply decoupled properly? Have you tried hardware write protect? Is the Propeller chip properly decoupled? Do you have noise on the supply?

Leon

QuattroRS4

Sample read:

Pub GetVal(Gval)
·repeat 9
· ·outa[noparse][[/noparse]28] := 0
·· outa[noparse][[/noparse]28] := 1
·eeprom.i2cReadPage(28, $A0, $7FFC, @Gval, 2)


Sample Write:
pub write(value)
·outa[noparse][[/noparse]28] := 1
·dira[noparse][[/noparse]28] := 1
·dira[noparse][[/noparse]29] := 0
·eeprom.i2cWritepage(28,$A0,$7FFC,@value,2)
·waitcnt(clkfreq / 200 + cnt)

are you sure - the 'number of bytes' is correct ?

the following is from Mikes object -
PUB i2cReadPage(i2cSCL, i2cAddr, addrReg, dataPtr, count) : ackbit
' Read in a block of i2c data. Device address is i2cAddr. Device starting
' address is addrReg. Data address is at dataPtr. Number of bytes is count.
' The device address is modified using the upper 3 bits of the 19 bit addrReg.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'

crgwbr

There are many capacitors in the design, also, if that was the problem, I think the program would be messed up to. As far as write protect, I wasn't aware that it had that feature, therefore, no I haven't tried it. The supply should be clean, it's just a 12v 1A wall wort, routed through a 5v reg and a 3.3v reg. There's about 300 uF or capacitance right there, about tripple tap throughout the design.

Post Edit: Code is now uploaded

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.

Microsoft: "You've got questions. We've got dancing paper clips."

Post Edited (crgwbr) : 4/9/2007 4:08:56 PM GMT

QuattroRS4

So this a custom design ... are your pullups present and what size ?

Regards,
Quattro

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'

Mike Green

Craig,
Somehow you're writing zeroes to the EEPROM. It would be a very very unusual hardware failure that would result in zeros being written. If this were my program, I'd look at what variables are adjacent to the 6 bytes in the VARS section to see if an array subscript could be out of range. I would look at the call structure of the program to make sure there wasn't a stack overflow occurring somewhere. If there are multiple cogs being used (other than standard I/O drivers), I'd look at their stack areas and shared variables. I'd look at all the places where the I2C routines are being called to make sure that the parameters are correct. If I couldn't find anything, I'd set up a spare PC serial port on a spare I/O pin and use the Simple_Serial I/O driver to display the parameters to the I2C routines, particularly whenever these locations are accessed for reading or writing to try to catch the problem when it happens.

crgwbr

There is a 10K pullup on SDA, not on SCL though. I just went by the eeprom circuit on the demo board.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.

Microsoft: "You've got questions. We've got dancing paper clips."

QuattroRS4

I have used 4.7K on both SDA & SCL without issue .... Mike just gave out a few good pointers there . I am pretty sure it prog. related.. when you get the code stick it up .. I am sure Mike will have his finger on it straight away ..

Regards,
Quattro

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'

crgwbr

Mike Green said...
Craig,
Somehow you're writing zeroes to the EEPROM. It would be a very very unusual hardware failure that would result in zeros being written. If this were my program, I'd look at what variables are adjacent to the 6 bytes in the VARS section to see if an array subscript could be out of range. I would look at the call structure of the program to make sure there wasn't a stack overflow occurring somewhere. If there are multiple cogs being used (other than standard I/O drivers), I'd look at their stack areas and shared variables. I'd look at all the places where the I2C routines are being called to make sure that the parameters are correct. If I couldn't find anything, I'd set up a spare PC serial port on a spare I/O pin and use the Simple_Serial I/O driver to display the parameters to the I2C routines, particularly whenever these locations are accessed for reading or writing to try to catch the problem when it happens.

I agree, I don't see how it could be a hardware failure. The only objects I'm using, are Extended_FDSerial, Minimal I2C Driver, and RotaryEncoder. Of, those, the only one that isn't an I/O driver is the Rotary encoder object. However, that is an input only object, therfore, I'm not sure how it could write 0's to the eeprom.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.

Microsoft: "You've got questions. We've got dancing paper clips."

crgwbr

QuattroRS4 said...
I have used 4.7K on both SDA & SCL without issue .... Mike just gave out a few good pointers there . I am pretty sure it prog. related.. when you get the code stick it up .. I am sure Mike will have his finger on it straight away ..

Regards,
Quattro

I already posted it. Look at the first post.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.

Microsoft: "You've got questions. We've got dancing paper clips."

Mike Green

There are lots of ways I'd simplify your use of EEPROM like using one ReadPage and WritePage to read/write all the data in one operation. I don't see why you have to rewrite the data back to the EEPROM after reading it, but neither should affect what's happening.

I suspect that your repeat loop at the end of Load is being activated and that you're getting FutureDn values that are all zero and that these are being written to the eeprom. You should see this on your serial port since you're displaying them when they're received.

I'm not sure this repeat loop is what you want. If it sees an "o", it echos "k", but then it goes on to always receive the 6 values.

crgwbr

I rewrote the values back to the eeprom because I thought it could fix the problem (one of the first things I tried). Never got around to removing it, I figured it couldn't hurt anything. I agree, that the loading loop could be getting zeros and writing them to eeprom, though I'm not sure how this could be happening because the serial object communicates with a FT232R that's bus powered. Most of the time, the usb cable is unplugged, the the FT232R would not have power, and therefore should'nt be able to communicate with the prop.

Thanks,
Craig

P.S.- The O and K are part of the communications protocall I designed for the computer app. It must recieve the 6 values, because the computer will always send 6 values.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.

Microsoft: "You've got questions. We've got dancing paper clips."

Post Edited (crgwbr) : 4/9/2007 4:37:24 PM GMT

Bean

Craig,
I have a EEPROM I2C object in my video overlay module.
You can download it here http://forums.parallax.com/attachment.php?attachmentid=0
It is based on the code posted by Beau.
I don't know if it will help, but it's worth a try. I haven't had any problems with it.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Educate your children to self-control, to the habit of holding passion and prejudice and evil tendencies subject to an upright and reasoning will, and you have done much to abolish misery from their future and crimes from society"

Benjamin Franklin
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
www.hittconsulting.com
·

crgwbr

Thanks Bean, I'll try it as soon as I can get into work. Do I need to call I2CStart and I2CStop, or will the WriteLocation and ReadLocation calls do that automatically?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.

Microsoft: "You've got questions. We've got dancing paper clips."

Post Edited (crgwbr) : 4/9/2007 4:42:36 PM GMT

Mike Green

Ah, that's your problem. If the USB cable is unplugged, the signal to the Propeller is at a ground level. The serial I/O routines see this as a valid start bit followed by 8 zero bits and an invalid stop bit (which they don't check for). The serial input routine sees a constant stream of zero bytes which the Extended Serial I/O routines may interpret as a delimiter (I haven't checked) and return a zero value from the decimal input call. You need to power the FT232R from your device.

Alternatively, you could check for power to the FT232R in your code (by connecting it to an I/O pin through a 10K resistor) and ignore the serial input (and flush the receive buffer) if it's absent.

Post Edited (Mike Green) : 4/9/2007 4:45:41 PM GMT

crgwbr

This sounds very logical to me. It would also explain why it works the on the first boot up, but not the second. When I power the FT232R using board power, how will the FT232R stop the prop from reading 0s? Just Currious.

Thank You,
Craig

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.

Microsoft: "You've got questions. We've got dancing paper clips."

Mike Green

Craig,
Any serial line should idle at logic true (high in this case). If the FT232R is powered, but not receiving any USB input, it should have a +3.3V output (try it). The serial routines will ignore this. The start bit of a character begins at the first high to low transition.

crgwbr

Now I understand.

Thanks Again,
Craig

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.

Microsoft: "You've got questions. We've got dancing paper clips."

crgwbr

4:30PM- I tested Mikes Idea, I wasn't able to power the FT232R directly, but I was able to filter out a series of 6 values. I works fine now.

Thanks,
Craig

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.

Microsoft: "You've got questions. We've got dancing paper clips."

QuattroRS4

Craig,
So the prop will get the 'Green' light for the industrial app. ? (couldn't help but add that pun Mike !)

Regards,
Quattro

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'

crgwbr

lol. It will be in testing for the next 1.5 weeks; if still works after that, it will have the 'Green' light. I'll Post some pictures as soon as I can. In a nutshell, it watches how deep a drill bit/chamfer/tap/stud is going into a hole, then reverses the tool when it gets to a preset depth. It is accurate to about 5 thousands.

Craig

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.

Microsoft: "You've got questions. We've got dancing paper clips."