MSP430FR5739: FRAM reliability

Alwin,

I split your post into a different thread as it is a new request. Are the MSP430FR5739 devices exposed to any high temperatures? Data retention on FR57xx devices cannot be ensured when the specified maximum storage temperature (Tstg = 95°C) is exceeded, please refer to Section 2.2.2 of the MSP430 FRAM Quality and Reliability App Report (SLAA526) for more information. What percentage of devices display this issue, and is the error always in the exact same location of memory? Providing exact locations along with the firmware's memory map would be appreciated. How was the memory loss discovered in the first place?

Regards,
Ryan

Hi Ryan,

No high temperatures are involved for this device. However I will try to give a little bit more context as to the use of the devices because it seems relevant.

The MSP MC is being used in a device that controls another high-voltage device. I think this is an important aspect. So the device communicates via low-voltage (modulated 3V) with another device that a.o. generates 7kV high-voltage. Now I cannot guarantee that micro-discharges occur on the common GND back to the controlling device. But the controlling device in which the FRAM processor is used does have high-speed ESD protection diodes to protect it from micro-discharges and we have tested with induced high-voltage discharges on the common ground to check FRAM processor reliability w.r.t. high-voltage discharges. In these tests no memory loss occurred as far as we noticed.

I don't have large statistics yet, because there are only a few (approx 15) of these controlling devices in use. But two of them already showed memory loss in the sense that some bits have been erased and they had to be reprogrammed again to function correctly. From the first occurrence I don't have exact information as to which specific address because at that point I did not expect memory loss issues.However, the fault behavior of the first device was different from the second device so I expect different memory bytes to be involved. We created the device with a full hardware sub-circuits self-test that all passed successful so the only option left for me to try was uploading the firmware again (via internal bootloader) and then miraculously the device functioned properly after that. Unfortunately (because I was not expecting memory loss) I did not  make a memory dump before uploading new firmware.

When this issue occurs again I will make another memory dump before uploading new firmware to check if there are any consistent factors.

Regards,

Alwin

Hi Ryan,

The fail state is likely not easily reproducible as we don't know what triggers it.

Your remark about the decoupling capacitor made me double check these in our schematics. For a reason unknown to me the two 10uF caps are specified as 1uF in our schematic. And indeed the FR5739 datasheet shows that they should be 10uF. So we will start to make a new revision to replace these caps with the correct value.

The main operating frequency is 16MHz based on Xtal oscillator (XT1DRIVE_2 drive level is used).

The stepping of Vcore is left as default. I did not make special arrangements in the code for this.

Regards,

Alwin

Alwin,

Please do change the decoupling capacitors, the design is likely violating the CVCC/CVCORE capacitor minimum ratio of 10. Ignore my Vcore level comments as I forgot that this is not required for this FRAM device.

Regards,
Ryan

I just received the same device that was updated with new firmware and again it has two bytes in the code segment erased. I can now confirm that it is not the same memory location although it is the same segment (code segment starting at 0xC200). Again it is only two bytes that got erased to 0x00.

The 1uF capacitors in this specific device will be replaced by 10uF caps to see if the problem manifests itself again. Will do before and after oscilloscope measurements of Vcc and Vcore as well.