solve this and get a medal!

[Brietech]

Okay, this is one of the weirdest electrical problems i've ever experienced. When writing to an i2c FRAM chip (FM32256 from Ramtron), on a number of random locations (4,20,68,84,100,116,132,148,164,196,212,228,244 - in the first 255 locations), the 5th bit (2^5=32) is stuck at 0. I noticed it when I kept writing ascii letters to it, and random letters kept coming back capitalized (it took me a long time to figure out what the heck was happening)!

It's fairly consistently the same locations (occasionally they will read/write properly, maybe 1 in 20 times). Is the chip just brain-damaged? It's driving me crazy so far!

 

[demonicpicaxeguy]

ok... question time,
what power supply?
what chip type and settings (freq)?
is it on a bread board or pcb and soldered in?
do you hae any other fram chips you can replicate it on?
do you have anyother picaxe's you can replicate this problem on
have you checked for any dodgy connections?

 

[BeanieBots]

Are you 100% sure the fault is with the FRAM read?
How are you 'displaying' what has been read?
I've seen a similar thing in the past which turned out to be a serial comms timing issue. The data was in fact correct, only the displayed result consistently showed a bit error.

Also worth dropping down to I2C slow and see if it has any effect.
Double check power connections to make sure both PICAXE and FRAM are correctly powerd and not being powered via their inputs.
Correct value resistors on the I2C lines?
Decoupling caps on BOTH chips.

What about the history of the chip. Ever had a static zap?
Have you tried another PICAXE and/or FRAM?
If yes, does the problem follow one chip, always happens or problem goes?

 

[Brietech]

I always forget to include the basics:
-5V power supply coming directly off of my computer PSU
-happens with both i2c_fast and i2c_slow
-the FRAM chip is on a board with 4 other 24FC512 chips and 1 more FM32256 chip. The FRAM chips are soldered to SOIC-to-dip breakout boards, and then soldered onto a "strip-board" type pcb (you get them at radio shack, and they have copper lines you can solder to). The 24FC512 chips are in DIP sockets that have been soldered down. A 4-pin header has been soldered to the board, which plugs into a 4-pin socket on the "processor" board
-The chip accessing it is a 28X-1 chip running at 16 mhz (i fried my other 28x1 somehow, so it's the only one i have for now).
-the other FRAM chip and the 4 EEPROM chips on the board all work correctly up to 1 Mhz
-No static zaps that I can think of, although each FRAM chip probably saw more heat than it should have when soldering it all together.
-I'm using 4.7K pull-ups that appear to work fine
-no decoupling caps at all in the system

 

[demonicpicaxeguy]

assuming you don't have an scope, i'm putting my money on some kind of capacitance problem, de coupling caps are advised, also because there is more than the two devices on the bus i'd have a little play around with the pull up resistors try some 10k's


how long is all the wiring between the picaxe and the i2c chip

 

[BeanieBots]

From your description of all that soldering, I assume it would not be a simple task to swap FRAM chips over to see if the problem follows the chip?

I'm not familiar with the internal construction of FRAM but if we assume similar to other technolgies then excessive heat could be responsible.
When a semiconductor is formed, there will always be a level of impurities in the substrate. Anything big will be found and rejected during burn-in test. Anything which is very small is the "long term" killer. Over time (in the region of 10 to 30 years) the impurity diffuses out and can eventually kill an individual cell. When the chip is subjected to excessive heat, that diffusion process is dramatically speeded up. That's why devices that run hot fail prematurely as appossed to the failure of running so hot that they melt. All chips will fail eventually due to diffusion. Just like all windows will fall out of their frames eventually because glass is a liquid!

In addition to that, memory devices are the ones which require decoupling more than any other device type with the possible exclusion of processors. The smallest amount of resistance/inductance between supply and chip can cause a volt drop when the element changes state. As a first priority you should fit them. Have a look at the boards in your computer and count how many are fitted. Just think how much cheaper they could be made without them. In this day and age of cost cutting anything that is not absolutley essential would not be fitted. They ARE essential.

It could be a line capacitance problem. Strip board is particularly bad but slowing everything down should have made a difference is was the culprit. Increasing the pull-ups to 10k would make it worse. Worth checking that the resistors fitted actually are 4k7.

If you have a selection of components try this to confirm/disprove capacitance issues:-
Halve the pull-ups by adding another 4k7 in parallel. (should improve)
Add about 47pF ~ 100pF between I2C lines and 0v. (should get worse).

Let us know how you get on.

 

[Technical]

What happens when you replace the FRAM with a conventional eeprom (should be possible if it is on a DIL adapter)? If the eeprom then works the fault is obviously in the FRAM, if not elsewhere!

 

[lbenson]

For what it's worth, the locations you cite are not random, but (after the first one) are multiples of 16 plus the "4" that you started off with. That's probably a clue to something, but what would be a mystery to me.

 

[papaof2]

For what it's worth, the locations you cite are not random, but (after the first one) are multiples of 16 plus the "4" that you started off with. That's probably a clue to something, but what would be a mystery to me.

Maybe something related to block/bank addressing? I've never used the chip in question, so don't know whether this might apply.

John

 

[Brietech]

It is happening whenever the lower 4 bits of the address = 0100 in binary, for what its worth