One of the possible reasons could be power loss during write register operation when you boot up.
Please refer to the KB article from the link given below which explains about the recovery if incorrect write register operation has been performed.
thank you for the answer.
We are not issuing WRR in our code, but I found "XQSPIPS_FLASH_OPCODE_WRSR 0x01 /* Write status register */" in the Xilinx qspi driver used by the first-stage bootloader. So perhapse the QUAD bit is indeed set during boot, as mentioned in the KBA.
Power-cycling during boot is something that could have happened to the system.
So w.r.t. my acute problem:
As far as I understand I won't be able to reset the OTP Bit for BPNV to zero. Hence BP0-2 will default to 1, leaving the flash locked after power on.
But if I could reset SRWD to zero (don't know about the WP# state), there could at least be the chance to reset the volatile bits?
Hello Max and Krishna,
I'm facing the same issue. I'm also working with a Zynq SoC device and faced some problems reading the partition header within my FSBL. After adding QSPI-support the problem was gone, but I found another problem which currently lead to bricked devices.
The datasheet says for Quad Ouptut Read: "The QUAD bit of Configuration Register must be set (CR Bit1=1) to enable the Quad mode capability." That is why I added the WRR command to enable the QSPI-bit mode which is basically working and solved my mentioned problem. But now I have another much more critical problem!
After a power loss during startup the S25FL512S device got in to an undefined state. The status register values are similiar to the values Max already posted (SR1: 0x9C, CR1: 0xEA). After executing the WRR command again the flash I wasn't even able to read out the device id.
After removing the WRR command in my FSBL and testing with another hardware I got the same issue caused by u-boot. I found the function spi_flash_set_qeb() is also performing a WRR command. The linux kernel may also perform a WRR command.
Until now I'm not able to get my broken flash devices working again. The best practice recommendation to maintain a stable power supply condition cannot be guaranteed in my application.
So my question is: Is there any chance to get the flash device back to a working state?