FM25W256 address problem

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

cross mob
CaBr_4498111
Level 1
Level 1

We have been using the FM25W256 for a while and we recently noticed that on some boards some of the memory addresses cannot be accessed properly.

We are using SPI mode 0 at 5MHz clock.

For example if I try to read or write address 0x00A4 I ended up reading or writing address 0x00A0, we noticed that happening also with other addresses like 0x00B4 and 0x00B0, it seems to be like the IC is always disregarding the last three bits of the address (I did scope the SPI and our device is requesting the proper address location)

We suspect something with the hardware as this code has been working for a while now. This is the circuit:

pastedImage_0.png

where all the signals go to our microprocessor. Is there something wrong for the resistors or capacitors that we are missing?

Thanks for the help

0 Likes
6 Replies
PradiptaB_11
Moderator
Moderator
Moderator
500 replies posted 250 solutions authored 250 replies posted

Hi Carlo,

1) Can you let us know the value of the status register. Want to check for WPEN bit and Block protection bits. Is it a requirement of the application to keep WP low

2) How many devices are showing this behavior.

3) Are you following the datasheet recommended power cycle specs such as tPD, tPU, tVF and tVR.

4) Can you let us know what is mode (0 or 3 being used) for SPI and value of CPOL.

5) if the device is ignoring last three bits then 0x00A4,0x00A3, 0x00A2 should read the same value. Is it happening in your case.

6) Are the SPI lines being shared with other devices.

7) Can you help provide wave forms/scope shots for the failed read/write operation.

Thanks,

Pradipta.

0 Likes

Pradipta,

Please see answers below,

1) Status register is set to is set to zero so WPEN and block protection bits are set to zero. We control WP from our micro controller

2) We have seen a few probably 6 or so

3) We periodically save data on our device, we have enough time from the power up to first operation see picture below

powerOnToFiestWrite.png

we do not have control over the last operation to power down as our user can power down at any moment by removing power to device.

It also looks like we are out of spec on the power up and power down rates, see pictures below

POwerDown.pngPOwerUp.png

4) Mode is 0 CPOL is 0

5 and 7) Yes that is happening, in the next pictures I show how I write the value 0x32 on address 0xA0, then read back address 0xA0 and I read 0x32. Then I write on address 0xA4 the value 0x64, I read back 0xA4 and read back 0x64. But then if I read address 0xA0 I have value 0x64 instead of 0x32, so the second write attempt to address 0xA4 overwrote the value on address 0xA0. See pictures below:

Write 0xA0 and read 0xA0

WriteA0_ReadA0.png

Write 0xA4 read 0xA4

WriteA4_ReadA4.png

Read 0xA0

ReadA0.png

6) The spi is dedicated.

Thanks for your help

Carlo

0 Likes

Hi Carlo,

The F-RAM device VDD ramp rate is traditionally specified as us/V to give a system level perspective of the minimum time requirement for the device power supply (VDD in case of FRAM) to ramp up and ramp down.  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. Please note Cypress does not guarantee the proper operation of F-RAMs if the power up/down ramp rate exceeds the datasheet limits. This may be leading the FRAM to operate incorrectly.We recommend you to get the power supply ramp rates under datasheet specifications. Also refer to the article on this very topic which explains the ramp rates.

Voltage Ramp Rate Required for F-RAM™ Devices - KBA204270

Thanks,

Pradipta.

0 Likes

Pradipta,

Thanks for your feedback. I checked some of the board that do not have the problem and the power up signal look the same as the board that do show the problem. Any other suggestion?

Thanks,

Carlo

0 Likes
GirijaC
Moderator
Moderator
Moderator
50 sign-ins 25 sign-ins 10 solutions authored

Hi Carlo,

I have two suggestions to debug the issue as below,

1. Is it possible to read the data from host (micro-controller/ASIC) instead of probing on the Saleae Logic and check if you can read the data correctly in the code.

2. Please reduce the Saleae logic speed (sampling rate) to 25MS/s or lesser and check if you can read the correct value. We have seen this behavior in saleae  if sampling rate is HIGH, it reads wrong data because of false clock glitches.

Also capture the tVR and tVF waveform on the Oscilloscope instead of Saleae, which will be more accurate to see if any glitches.

Thanks,

Girija

0 Likes

Girija,

See answers below,

1) Yes we see the exact same data from the micro-controller, this is how we first realized we had a problem

2)We saw the same signal form on oscilloscope.

Thanks for your suggestions.

Carlo

0 Likes