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.
I have not used the drivers from GitHub myself but have worked with the AT25SL128A and it should NOT protect itself. Are you able to break your test down to see when the STATUS reg 1 is being changed? I will also ask some of our SW engineers if they have seen any issues with the drivers.
The github drivers and tests themselves seem perfectly fine.
The odd part is that this happened only on wrap back to the first sector, which is why I thought I'd ask the question i.e. if an already-written sector needs to be unprotected before erase or write or read.
This did seem unlikely but this is the first time I am using this flash part, so I though I'd ask.
I have not been able to repeat this yet but it happened on two units, and both on wrap around.
I will try to get more info if this situation repeats.
Thanks for your reply!
Would you give me a more in depth description of the 'wrap around' condition?
By "wrap-around" I mean that I write data (and read lags behind data) till the end of the flash memory and then I wrap back to the start of the flash. So as I have already written data there before I have to erase that 4K sector (4K sector number 0), before I can write to it again.
Just speaking with one of our SW team. These drivers were written by an intern to help us demo our flash parts and were tested on NXP and ST controllers. Note that these drivers use a 'bit banging' method where IO pins are used to simulate SPI hardware. This makes them slightly slower and does not make best use of available SPI bus hardware. That said, they should work on any controller and should NOT protect the Flash without the host program requesting this.
Would you let us know which processor you are using as well as more info on when this 'wrap around' occurs?
I am not using the bit-banging technique from the driver, I replaced that with SPI code from the MCU I am using (SiLabs EFR32BG22). In general this works fine, not really found any issues except this one case. Sorry, I forgot to mention this before, I am using standardflash.c unchanged, interfaced to MCU SPI code.
The wrap-around is the case when writing to the end of flash (16MByte limit) and then going back to address 0 or 4K sector number 0. The readback of data failed i.e. only 0s were read back and not the real data. I cannot say if the write failed and wrote 0s or the read failed and read 0s.
Thanks for confirming that this is not expected on the flash without the host program actually commanding this, regardless of the driver used. This is really what I wanted from your side.
Thanks for the feedback. I will leave this parked for the moment but feel free to open this thread again if there are more issues.
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.