AT25SL128A went into protected sector state

Hello,

I have a design based on AT25SL128A. I started with the standardflash.c and tests for it from the Adesto github website and all tests pass. So I assume my SPI integration is fine on my MCU.

I then set it running for a longer test so that it would keep writing/reading back data and then wrap around to the start of memory. Then I erase the 4K sector to reclaim it for writing.

However when I read back data after the wrap followed by 4K erase, I found I was always reading all 0s. Further check revealed that Status Register 1 value was 0xFC which means all the protect bits were set to 1.

Q1: This was not done by me, so I am wondering if you have any suggestions on whether the flash might go into this state on its own due to any trigger?
Q2: Or can it only happen if the MCU wrote this value to it?

Note1: I was able to recover back to working state by writing a new value to Status Register 1 but I want to check how to avoid this in the future.

Note2: Status Register 2 was 0x00, which is the default value. It did not change.

Thanks!

- Arun

 

 

Parents
  • Former Member
    0 Former Member

    I have experienced the same or very similar behavior using the AT25SF128A. I was using my own code (not the code from GitHub), which had been working on our first prototype for weeks. During testing on the final product, one of the flash devices got wrote protected somehow (Status Register 1 value was 0xFC). My code did not include any "Write Status Register" command, and I'm completely unaware of what triggered the write protection. After clearing the Status Register it was possible to write to the flash again, but I still don't understand why this was necessary.

Reply
  • Former Member
    0 Former Member

    I have experienced the same or very similar behavior using the AT25SF128A. I was using my own code (not the code from GitHub), which had been working on our first prototype for weeks. During testing on the final product, one of the flash devices got wrote protected somehow (Status Register 1 value was 0xFC). My code did not include any "Write Status Register" command, and I'm completely unaware of what triggered the write protection. After clearing the Status Register it was possible to write to the flash again, but I still don't understand why this was necessary.

Children
No Data