The other downside to FRAM...

[alank2]

So I've been using FRAM in a project and it has been working fine, but the idea that reading is destructive and requires a built in rewrite has finally reared its ugly head.

The one project I've been using it in is 5V and it says it is good 4.5V-5.5V, and I have not had any trouble (that I know of).

I then tried it in another project and sometimes the voltage drops below 4.5V and this is when the problem happens.  If the voltage is too low, when it tries to read the memory, it fails, and at the same time destroys the contents of the memory, I am presuming because it is unable to rewrite it.

Now unexpected because I was mistakenly operating it outside of its voltage range, but this is an issue if there is a low voltage condition that data loss might occur.  In my second project where voltage can be lower I am switching to EEPROM instead, but for my first project which is a 5V only project, I still plan to use it.

I have BOD set to 4.3V on this project and while it does seem to prevent the issue from happening, I wonder if it would be wise to also implement a software solution to prevent data loss.  I could have a dummy byte on the device and attempt to write/read/write/read a 0xAA then 0x55 value to see if it worked before accessing other memory.

I like that FRAM has no waiting, you can write it as fast as the i2c runs, but I don't like its price, and the data loss risk is an issue I will think more strongly about in the future.

Any other thoughts?

[danadak]

You could always use a large C to hold up supply rail when you do
a R/W operation in FRAM. Couple that with V detection so that you
can predict if there is enough time to complete the operation.


This can all be determined from Q = C x V, I - C dV/dT, solve for C,
then use that in code to determine dT when you want to do the FRAM
access/operations. You would measure V, then plug into eqn. to determine
if dT is large enough to R/W.


Regards, Dana.

[PChi]

EEPROM isn't free of problems. If the voltage falls during a write cycle the contents can be corrupted.

[Ian.M]

Read the datasheet diligently - some EEPROMs use a page write mode and if you brownout during a write a block of typically 32 adjacent locations can get trashed!

I did a bit of googling and it looks like I2C FRAMs with a supply voltage range from 2.7V to 5.5V are available.  Maybe you should better match your FRAM supply voltage range to your BOR voltage?  IMHO expecting a 4.3V BOR to prevent data corruption of memory only specced down to 4.5V is pissing upwind . . . .

[amyk]

Destructive readout means it's like the old core memory...

4.3 BOR plus a suitably sized cap and diode on the supply rail might be OK.

[Fsck]

what capacity is it?

you probably could have used an sttmram.

[alank2]

Destructive readout means it's like the old core memory...
4.3 BOR plus a suitably sized cap and diode on the supply rail might be OK.

Yep - one of the things I liked about it - I think core memory is pretty cool.

what capacity is it?
you probably could have used an sttmram.

2KB - I'll have to see what sttmram is...

[coppice]

Which FRAM chip are you using that requires a minimum of 4.5V? All the FRAMs that emulate I2C EEPROMs I've seen work down to 2.7V. Below that they have anti-tearing logic to ensure a write will either succeed or not be initiated.

[alank2]

FM24C16B-G

Below 4.1 it does not do well....

[alank2]

I was using a round robin sort of method of wear leveling where I would divide the memory into slots and each slot has a crc16 for integrity and a version.  This has worked pretty well for me, but one downside is that you have to read all memory at startup to determine which slot has the latest version of the data structure.

I've never liked the time it takes to read all slots and find out which one is the newest, and with fram and low voltage, it just results in clearing all of them when I try to read all of them.

I had an other idea though which will involve using a pointer to the correct slot, but that would do you no good if you are constantly rewriting that pointer because that would wear out before you can utilize all the memory to its fullest endurance.  Then I had a new thought, use a pointer in addition to a write counter in the slot itself.  That way the pointer only changes to the next slot every 64K writes.  So each slot get written 64K times and then the pointer is updated to the next slot and it gets 64K times.  This would repeat and roll over until all slots had their 1M or 4M and the pointer still would be way below that.  It would also be faster as there would be no point in reading them all.  This combined with a raid 1 style mirroring where the first half of the eeprom space is the master and the second half is the backup and I might have something pretty tolerant of long term writes.

[Ian.M]

Your problems are self inflicted!  FM24C16B datasheet:
"High-endurance 100 trillion (1014) read/writes"
"Voltage operation: VDD = 4.5 V to 5.5 V"

"Note that the FM24C16B contains no power management circuits other than a simple internal power-on reset. It is the user’s responsibility to ensure that VDD is within data sheet tolerances to prevent incorrect operation."

"Regardless, FRAM read and write endurance is effectively unlimited at the 1MHz I2C
speed. Even at 3000 accesses per second to the same row, 10
years time will elapse before 1 trillion endurance cycles occur."

So there's absolutely no need for wear levelling and just because you've got one on your bench that doesn't fail till Vdd drops to 4.1V, is no reason to rely on a 4.3V BOR threshold 0.2V lower than the specified minimum Vdd.

It uses eight byte rows (pages), so after scrapping your wear levelling, store critical data  three times in separate blocks that are a multiple of eight bytes long, with a strong checksum for each block, and implement an effective lockout against accessing it with Vdd<4.5V.

[alank2]

Your problems are self inflicted!

I realize that the FRAM has no endurance issues...  I had a library developed for eeprom already and ended up using it.

[sarepairman2]

how did you design your power rails? It sounds like you did a bad job laying out your circuit. 10% dip during normal operation sounds like some severe budget restrictions.

It sounds like you need to scatter some storage capacitors around your circuit.

Also chips have two specs, a line voltage range spec and a tolerance spec. Just because it says down to 3 does not mean you can necessarily allow your power rail to vary by big percentages.

 If you run the system at 4.5V it might work fine, however if you run it at 5 and it dips it might fail because of internal capacitance changes. A gradual dip from 5 to 4.5 might not hurt but a sudden power loss surge might cause problems.

This is probobly not specified because designers expect you to run a chip on a well regulated line (10% is not well regulated and it just means your being really really stingy with capacitors).


as a hunch i suspect that digital IC designers consider 5% to be acceptable regulation and 1% to be ideal.... unless you get into FPGAs and shit.

[Kjelt]

Indeed your uc should be able to detect power loss and still have at least one second after to clean up its bookkeeping (write buffer to permanent storage, set everything to a safe mode of operation and then wait indefinitely till the power comes up. So add some extra capac itors

[coppice]

"Note that the FM24C16B contains no power management circuits other than a simple internal power-on reset. It is the user’s responsibility to ensure that VDD is within data sheet tolerances to prevent incorrect operation."

Wow, that's nasty. I didn't realise anyone built FRAM parts without full anti-tearing hardware on board. It really really hard to do rock solid anti-tearing on the outside, especially under EMI/ESD attacks.

[mikerj]

Your problems are self inflicted!

The OP already stated this in his first post.

[Ian.M]

Your problems are self inflicted!

The OP already stated this in his first post.

Yes, but why in %DEITY%'s name is the O.P. trying to use a 4.3V BOR to protect against a minimum specified FM24C16B operating voltage of 4.5V? 
Is it an exercise in designing off  the datasheet, requiring select on test as  every single FM24C16B will need to be qualified down to 4.2V over the full temperature range required?
IMHO that's insane.   
5V I2C FRAMs that work down to 2.7V or 3V are available so why not use one?

[xygor]

Is the problem being caused by the brown-out reset?

[alank2]

The one project I've got released has a AVR BOD set at 4.3, but the datasheet says it can actually be 4.1-4.5V.  I have about 100 of them out there and no complaints except for 1 unit.  That one I don't know for sure is this issue, but it might be, user is going to send it back so I can take a look at it.  So, nothing critical here, but if I can make it better with a software mod for future versions, that would be worth doing.  Unfortunately I just bought 194 pieces or I would have just chosen a different FRAM part of redesigned with EEPROM.  I suppose I could attempt to sell them, but with a record of 99 out of 100 working and possibly 100 out of 100, I may just add some software safeguards and go with it.  My two ideas are (1) use the ADC to read the internal 1.1V against VCC and to make sure the voltage is higher than the BOD is set for, (2) have a test area on the FRAM and write 0xAA to it, read it, write 0x55 to it, read it, and make sure it functions before using it, (3) shutdown a high consuming item like the lcd backlight to enhance what the cap can do in case there is a brownout, hopefully the amount of time would be so fast the user might not notice it at all.

The second project needs to go down to 2.5V and I had just overlooked the voltage limitation on the FRAM, that failure was very obvious.  At 4.1 V if you try to read, it will corrupt.  This one is easy, just switch to EEPROM.

I appreciate the help and advice everyone!

[Ian.M]

(1) Is the internal 1.1V reference close enough tolerance to let you reliably set a threshold between the nominal Vdd and the datasheet minimum of 4.5V for the FRAM?  If not you'd have to add a calibration step after flashing the AVR, that wrote the ADC result for Vdd=4.5V to the AVR's internal EEPROM, which would be a PITA.

(2) doesn't help much.  How do you know your test location is a good 'canary' for undervoltage detection?  If some locations rewrite successfully at a lower voltage than others, the test will be useless except against gross brownout which would already be caught by the AVR BOR.

(3) doesn't buy you much - its not like EEPROM where you have to hold Vdd up for the next 4ms or so for the write cycle to complete.   It *may* get you a bit more margin if your Vdd rail is droopy.

If you want to use the rest of the FM24C16B chips without a method of keeping Vdd in spec during operation, you'll have to decide what a 'bounce' costs you - I suspect you'd do better to try to resell them.  You've only got about $320 tied up in parts - unless you paid over the odds for them. 

[alank2]

You make some good points Ian, thank you.

[T3sl4co1l]

Also regarding BOD in general, this is a good reason to use a switching supply, even if you don't really need it: as the input drops, you can detect that via comparator/power monitor or ADC input, meanwhile the output remains perfectly regulated until the switching regulator hits its dropout voltage.

This isn't much help for a buck converter (where you get almost the same hold-up versus Vin excess, for a given input cap, as with an LDO), but a SEPIC or boost can go well below the output voltage, giving lots of time to figure out shutdown.

Application examples might be:
- 12 or 24V (industrial DC?) down to 5V: buck preferred, LDO tolerable if low power (just because of power dissipation)
- 7 to 12V (universal input?) down to 5V: buck preferred; LDO would require too much hold-up capacitance at the lowest nominal input voltage
- 5V from a power adapter, down to 3.3V logic: use SEPIC instead of buck
- 3-4V from Li Ion, to 3.3V logic: use SEPIC
- 1.2 to 3V (say, one or two alkaline cells, watch battery, solar, etc.), up to 3.3 or 5V logic: boost (SEPIC optional)

Tim