FM25L04B sporadic invalid status register content read via SPI.

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

cross mob
glhic_4216051
Level 1
Level 1

We're using a PIC32MX family MCU and communicating with the F-RAM via SPI.  We can successfully perform hundreds of writes to the F-RAM before we see the device return seemingly invalid content from a RDSR command to check for write-enabled.  Values of 0xC7, 0xC5, 0xC3, 0xC2 and 0xB7 have been observed, and after 250 retries of the RDSR command (performed at 1 msec. intervals), the application times-out and considers the condition fatal.  The data-sheet indicates bits #0 and #4-#7 are "don't care" and will return 0, but that does not appear to always be the case in our situation.  We do not configure any write-protection.

Any ideas on what could cause these sporadic RDSR values?

0 Likes
1 Solution
PradiptaB_11
Moderator
Moderator
Moderator
500 replies posted 250 solutions authored 250 replies posted

Hi Glenn,

1) Is the power supply stable at all times during the operation. Is there any brownout ? Are there any glitches on the VCC pin ?

2) Can you also provide us the wave forms for the RDSR command with respect to VCC for a successful write and when you read these inconsistent values.

3) After the failures can you once do a power down and then after power up do a WRSR command followed by RDSR command and check the status. You can write 0 to all BP bits.

4) How many devices are showing these behavior ?

Thanks,

Pradipta.

View solution in original post

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

Hi Glenn,

1) Is the power supply stable at all times during the operation. Is there any brownout ? Are there any glitches on the VCC pin ?

2) Can you also provide us the wave forms for the RDSR command with respect to VCC for a successful write and when you read these inconsistent values.

3) After the failures can you once do a power down and then after power up do a WRSR command followed by RDSR command and check the status. You can write 0 to all BP bits.

4) How many devices are showing these behavior ?

Thanks,

Pradipta.

0 Likes

Thanks for your reply, Pradipta.  I will respond to your questions individually below:

1.)  Yes - the power supply is stable, no brown-outs are detected and the VCC pin is consistent as best we can determine.

2.) We're working to capture a wave form but it would be virtually impossible to do that for the failure case, since that occurs unpredictably.  For the success cases, our EE has confirmed the wave form appears correct.

3.) We can add the firmware updates to perform a WRSR/RDSR sequence upon power-up, but a power-cycle of the board always clears the problem, that is until the next unpredictable recurrence (we have no way to only power-cycle the F-RAM device itself, if that is what you meant).  We don't use block-protection and didn't see the need to explicitly clear BP0 and BP1 (since 0 is their factory defaults).

4.) We've observed this behavior on at least 3 of our boards to-date.

In an effort to mitigate this condition, we've updated our firmware such that, in our write-ready check loop, we re-send the WREN command to the F-RAM before re-sending the RDSR command (as opposed to sending the WREN only once).  There is a very short (two NOPs) delay between the WREN command completion and the RDSR.  The loop executes up to 250 retries.  So far, this seems to have eliminated the issue, but with it being very random, I'll be more confident with much more test run-time.

0 Likes

Hi Glenn,

The configuration registers in the FRAM are not getting configured properly. This is the reason why you see these inconsistent values. Also a power cycle clears the error meaning the registers are configured properly after the power cycle.The most likely reason for this are glitches in the power supply, or the ramp rate specs as specified in the datasheet not being met. Do you have any further updates for us ?

Thanks and Regards,

Pradipta.

0 Likes

Pradipta,

Thanks again for your insight - I've forwarded your latest reply to our EE to research.  The problem with the F-RAM has not re-appeared since the firmware change I described earlier.  However, we are seeing something similar with an on-board FLASH device (not Cypress) that is very random; similar in the sense that the device sometimes indicates it is not write-enabled.  In that condition even a reset command will not restore proper FLASH function.  Your hypothesis regarding the power supply glitch may be supported by the FLASH behavior.

Our EE has provided the following, additional information:

-  Ramp rate is 4000us/V.  Time before first falling edge is many milliseconds

-  Power Architecture:  24V -> 5V (SW) -> 3.3V LDO

   >  The FRAM is located almost directly below the LDO

   >  LDO is rated for 1A, and delivering about 200mA.  There is an appropriate amount of bulk capacitance.

   >  The FRAM is decoupled appropriately with 0.1uF capactior

   >  Noise on 3.3V supply is minimal.  We have see no evidence of glitches on this linear supply.

If we only saw this failure in EMC testing I could accept the power glitch as a cause.  However, we have seen it in our offices just running on our desks.

0 Likes

Hi Glenn,

Are you facing any issues now ?

Thanks,

Pradipta.

0 Likes

Nothing has changed in terms of the F-RAM I/O - the firmware mitigation described in my May 4 post appears to have eliminated the issue.

0 Likes