6 Replies Latest reply on May 23, 2019 5:12 AM by glenn_highland_4216051

    FM25L04B sporadic invalid status register content read via SPI.

    glenn_highland_4216051

      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?

        • 1. Re: FM25L04B sporadic invalid status register content read via SPI.
          PradiptaB_11

          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.

          • 2. Re: FM25L04B sporadic invalid status register content read via SPI.
            glenn_highland_4216051

            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.

            • 3. Re: FM25L04B sporadic invalid status register content read via SPI.
              PradiptaB_11

              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.

              • 4. Re: FM25L04B sporadic invalid status register content read via SPI.
                glenn_highland_4216051

                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.

                • 5. Re: FM25L04B sporadic invalid status register content read via SPI.
                  PradiptaB_11

                  Hi Glenn,

                   

                  Are you facing any issues now ?

                   

                  Thanks,

                  Pradipta.

                  • 6. Re: FM25L04B sporadic invalid status register content read via SPI.
                    glenn_highland_4216051

                    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.