CY15B104Q-SXI Data Corruption Sources and Root Causes

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
tacq
Level 1
Level 1
5 sign-ins First reply posted First question asked

Hello, I have found one of my devices to show data correction on a very large scale and we are wondering if environmental exposure of some type could have caused the large corruption of data. We see at the very least a 4kB block of corrupted data.

So, could I expect the following environmental sources as the cause of my data corruption:

  • Excess dwell and excees reflow temperature  : I have the reflow profile available  to us but are these devices more vulnerable than others to excess heat or dwell during reflow and does this cause data corruption ?
  • ESD exposure : I would expect that ESD environments would cause I/O to stop working first and that has not occured. The device functions properly but develops data corruption
  • Voltage supply rail ramp up or ramp down : could the speed of ramp up or down of the 3.3V rail cause the device to have corrupted data.
  • Could parasitic powering via I/O pins prior to 3.3V rail cause the device to lose have corrupted data ?
  • Radiated EMC susceptability : Do these devices (FRAM technology) have more vulnerabilities to EMC radiated suscepatbility than other technologies ?

I am running with SCLK at 25MHz (device max is 40MHz) and I am using a single write command stream to write the entire device. This has been show to work fine over numerous device write and read testings of numerous power cycles. We have been using this configuration for over two years and have seen this occur on only one (1) board (1 device / board) so far. 

The FPGA write controller code has the device fully unlocked and does all of the normal write operations prior to the Write action. We can re-write the device but the corruption seems to re-appear after a time period. We do not know all of the environmental exposure sources this unit is seeing at this time. 

Can you offer any assistance about what could be causing this corruption of data in this CY15B104Q-SXI  device?

Also, I have checked the 3.3V power rail and it ramps up monotonically from 0 to 3.3V in 1.5 millisec. Nice and clean. The FRAM SPI interface is connected to a Xilinx FPGA which has its pins tristated (high Z) during and after power up of the 3.3V rail and while the device is being configured for which takes about 300 milliseconds. So there is a huge delay between when the power monotonically comes up and the device is first accessed during which the time the SPI pins are high Z.

  • We have a pullup to 3.3V on the CS_n, Hold_n, and WP_n lines (10k) 
  • The 3.3V power rail is very clean with less than 10mV rms noise
  • The tPU spec is easily met since the device pins are in High Z while the power is ramped (in 1.5msec) monotonically and then is static for the next 300msec while the device running the CY15B104Q-SXI's SPI interface is being configured.

 

Thanks, Tom

0 Likes
2 Replies
Ritwick_S
Moderator
Moderator
Moderator
100 solutions authored 25 likes received 250 sign-ins

Hi @tacq,

 

 

> Could you please let us know if the same data is getting corrupted or if it is a random behaviour?

> Could you elaborate on "corruption seems to re-appear after a time period"? Did you mean that if you read immediately after writing, you can read the data correctly, and if you wait for some time and then read, then you find the corruption?

> Did this board work fine for the past two years, and recently, you observed this corruption?

> Could you please share the schematic with us?

> Could you please share the power ramp-up and ramp-down waveforms?

> Are you able to read the device ID correctly?

> Could you please let us know your operating temperature?



Thanks,
Ritwick

0 Likes
lock attach
Attachments are accessible only for community members.
tacq
Level 1
Level 1
5 sign-ins First reply posted First question asked

 

> Could you please let us know if the same data is getting corrupted or if it is a random behaviour?

It looks to be the address range from 0x0 up to 0xAFF9 so far with regarding random corruption. Alternatively, we have seen valid contents overwritten to 0x00 over the entire address space (the memory was completely empty). In either case, the contents cannot be read properly using the fast-read mode when there is corruption in the lower address range.

> Could you elaborate on "corruption seems to re-appear after a time period"? Did you mean that if you read immediately after writing, you can read the data correctly, and if you wait for some time and then read, then you find the corruption?

Yes, if we preform a write followed by a read, we do not see any issues (even if there is a power cycle in between). Eventually, we will power up the board and it will not function. Reading the memory contents reveals the device is empty (0x00 in all locations), has a block of corruption in the lower address range as described above, or a combination of the two.

> Did this board work fine for the past two years, and recently, you observed this corruption?
This board has been know working for a few months now. The board is being used in another environment rather than bench test and the data retention problems are now being observed and they were never seen in bench checkout.

> Could you please share the schematic with us?
We cannot send snip but we can redraw the portion. I have added this ckt dwg to this thread.

 

> Could you please share the power ramp-up and ramp-down waveforms? Yes, we will append those to this thread 

> Are you able to read the device ID correctly?
We have not tried. We can read the imprinted device lot code information from the top of the part. Would that help answer this question? I am going to get the firmware read RDID bits.

Can you tell me what important info we will get if we read the Device ID? is there a lot code, for example that is valuable to us?

> Could you please let us know your operating temperature?

25C

0 Likes