A few days ago I successfully tested erasing the NORFlash as entire chip erase, block erase, and sector erase. I also was able to write a string to Flash and read the string back out of Flash into a buffer. After working on other development I came back and tested the QSPI again and now I cannot erase or write but can still read out of Flash the test string that was written several days ago. I'm using the exact same code as the first test, trying to just erase and read and get the same string so proved it's not erasing also try to write a different test string and still get the old string when I read. Also during the initial test it would take a little time for a full chip erase and now it just goes through quickly also indicating an erase is not happening. I do have MPU setup for the the 0x90000000 Flash address as well for MPU_PRIVELEDGED_DEFAULT but have access set for ALL_ACCESS so thought this was ok.
Solved! Go to Solution.
I'd recommend clearing the sCommand structure on all occasions, you've got it on most but not all. This will limit odd/unpredictable operation.
Watch also the Status 2 Write, not all generations of Winbond parts support this, and it's hard to determine which you're talking too. Might need to unpack the SFDP (0x5A)
The BPx block protect bits are set in some way, the wrong sequences for Micron, Macronix or Winbond can lock other manufacturer's parts. You'd have to undo that.
Start by dumping out the Status Register(s)
Different Winbond chips support different write status register commands, the older expect SR1 and SR2 to be written as a PAIR, as SR2 can't be written by itself.
Or you've got the chips in the wrong mode, written values in to NON-VOLATILE settings which they subsequently REMEMBER.
I did try to put the device in memory mapped mode intentionally and then stepped through the erase chip function and see that hqspi->State is HAL_QSPI_STATE_BUSY_MEM_MAPPED, however when I do not put the device in memory mapped mode (removed that code) then the hqspi->State is HAL_QSPI_STATE_READY (this is within HAL_QSPI_Command())... this made me believe that memory mapped had nothing to do with it.
from the STM32H743ZI I have the following QSPI pin assignments...
PA1 - QUADSPI_BK1_IO3
PB2 - QUADSPI_CLK
PB6 - QUADSPI_BK1_NCS
PD11 - QUADSPI_BK1_IO1
PE2 - QUADSPI_BK1_IO2
PF9 - QUADSPI_BK1_IO1
Thanks so much for your advice on this!