There is no known issues with the memory. We will need to debug this issue to find the cause of failure. Can you please help us with the below information
1) Can you confirm that the power cycle timing specs are being followed correctly as shown in the datasheet. The tPD, tPU, tVF and tVR specs need be met for proper operation of the FRAM.
2) Is there any issues with the power supply or GND connection
3) Can you tell us the steps you follow on power up or reset, how much time you wait, what is procedure for read and write.
4) Can you share the schematics of the FRAM part
5) Since you are not able to reproduce the issue is it possible for a read write scope shot for the failing parts. Do you have any logs or records
Thanks for your response, I will try to answer your questions with my best effort:
1) tPD is hard not to fulfill, tPU is at least 200ms because of reset circuitry used, tVR has been measured to about 268µs/V and tVF to 13ms/V.
2) FRAM is placed close together with MCU on a galvanic isolated part of the PCB, supplied from isolated DC/DC converters from Gaia.
3) Upon power up and reset, in bootloader all pins are initialized as inputs except CS which is output set to high, when application starts the other SPI pins are initialized for the SPI peripheral in the MCU.
First communication happens about 20ms after MCU starts.
A write is performed by taking CS low, sending write enable command, then CS is taken high for at least 1us and then a write command followed by start address and data in 16 bit chunks, when all data sent CS is taken high.
Read is performed in the same manner except the write enable command is never sent.
Notice that no interrupts are used in the MCU.
Diagram of SPI read
C1: SCK C2: MOSI C3: MISO C4: CS
4) I cannot share that information but the FRAM is the only device on the SPI bus (CS, SCK, MOSI, MISO).
We have however just discovered that there are no pull-up on CS which is not mentioned as required in datasheet, briefly mentioned in "Document No. 001-87196 Rev. *E" (https://www.cypress.com/file/46161/download ) but described in more detailed in now obsolete "Document No. 001-87072 Rev. *E" (https://www.cypress.com/file/46141/download ). How come it was so importatn with pull-up before but no longer? What behavior is expected without pull-up on CS?
5) I don't understand which logs and errors your referring to but we are using the FRAM for logging of errors, which are useless due to the data loss.
You need not use any pull up on the CS signal.The device will operate as per the datasheet specifications only, no effect in performance.
Since the issue cannot be reproduced at hand it is going to be difficult to debug the issue.
The possible cause for such issues can be
1) Power Cycle timing mismatch ( the specs we talked about previously)
2) The SPI signals are getting some disturbance or not matching some timing requirements. May be the converters used are causing some abnormalities. Without having a look at schematics it is difficult to say. Can you share the schematics with us privately.
Also can you tell us that after the failure when you perform a power cycle or reset does the device till give corrupt data or is it giving correct data.
I've managed to capture the power up and power down. After power up there is a 200ms delay until CS goes high and then >50ms until first access of FRAM.
Once the intentionally written data has been corrupted, the FRAM retains the same corrupted data for multiple power cycles (until intentionally overwritten).
Most integrated circuits set a minimum finite time for its power supply to rise to its min operating voltage so that device can correctly set its internal band gap, logic and peripheral circuits and configuration for a successful boot up. In most cases (including FRAMs) power up ramp should be monotonic. I can see some glitches in the supply during power up.It is not monotonic. Please note Cypress does not guarantee the proper operation of F-RAMs if the power supply is not monotonic. This may be leading the FRAM to operate incorrectly.We recommend you to get the power supply more clean and regulated.
Thanks and Regards,
Please let us know if you are following the below sequence to write/read the F-RAM.
1. Power-up the device
2. wait for 250 ms with CS LOW
3. wait for >50 ms with CS HIGH
4. Write the Memory with known data ex. 0x00
5. Read back the memory to verify if read data matches with written data
6. Power cycle the device
7. wait for 250 ms with CS LOW
8. wait for >50 ms with CS HIGH
9. Read the Memory. the data should be 0x00 but you read some random value.
the value read in step 9 (corrupted data) is retained for subsequent power cycles.
You mentioned that if you overwrite the corrupted value with known new data ex. 0xAA, the memory will have the new data 0xAA.
Question is , is this new data 0xAA written is retained for the next subsequent power cycles or at some point this also get corrupted?
or Are you reading the factory programmed default values at power-up and seeing the issue? If So, we always recommend you to write the known data at first power up and test for data integrity.
We believe we have recreated the issue by making the supply voltage ramp up even more unstable, resulting in random corruption in the FRAM.